Why is the IAR compiler stuck?

Question

In my embedded project, using the IAR EWARM dev tools (v7.10.3), I have the following code snippet:

/* 1 */ uint32_t packet_sync = 0; /* 2 */ uint32_t synced = 0; /* 3 */ uint32_t gpio = 0; /* 4 */ while (1) { /* 5 */ if ((packet_sync != 0) && ((packet_sync = gpio) == 0)) { /* 6 */ if (synced < 2) { /* 7 */ synced++; /* 8 */ } /* 9 */ } /* 10 */ }; 

For some reason, when I compile the code, the compiler gets stuck in the middle of the compilation. I tried playing around with various constructs, and it seems that any minor changes I make fixes the problem (but may also make the code incorrect). For example, adding NOP to # 6a and the code will compile successfully:

 /* 6 */ if (synced < 2) { /* 6a */ __NOP(); /* 7 */ synced++; /* 8 */ } 

Other examples of successful changes are deleting line # 7 or changing line # 5 as:

 /* 5 */ if ((packet_sync != 0) && ((gpio) == 0)) { 

and a few more options.

I don't see a rule C violation in the problematic code, and it compiles fine in Visual Studio 2013. Am I missing something? Why is this code not compiling?

^{* Note: the code presented is an extraction of the actual code and is logically meaningless.}

---

Update: Code compiled with optimization level "High" / "Balanced". At lower levels of optimization, compilation ends just fine.

It also gets stuck when using the "High" level, but removes the optimization options in the "Enabled conversions:" field. Also stuck for the “Speed” and “Size” options.

Answer 1

Optimization is the hardest part of any compiler, and therefore the most likely place for compiler errors — especially for a “narrow market” compiler with a small development team and fewer if users use a desktop compiler.

Using optimization has two consequences, which you should be careful about; The compiler itself may be a mistake (it seems, in this case), and any area of ​​behavior "undefined" in your own code can change the behavior during optimization. If you need optimization, you need to be prepared to test widely - the generated code is not necessarily equivalent to a debugging / development assembly.

In this case, you should definitely inform the supplier about this, ideally, with a really drawn up example and project configuration. In order to solve the immediate problem of a reasonable use of a volatile keyword can solve this problem - the optimizer will work on eliminating the variables that appear, have no effect otherwise - if you can avoid the optimizer take the same path, you can avoid errors. If you do not use volatile correctly, your code may show errors in any case during optimization. In your example, some variables should certainly be declared unstable, but since the example is not "real" but "illustrative", you cannot recommend it.

Another option as a workaround is to selectively turn off optimizations for this section of code or the source file. Do you really need optimization to make your code work at all? If not, I would advise avoiding this anyway - without using optimization, it avoids changes in the behavior between debugging and released code and simplifies debugging in the first case. I would suggest using optimization as a solution to a problem with code size or performance issues when and if they arise, and not for granted.

Answer 2

If the compiler literally gets stuck, that is, it hangs, so you need to kill the process, and then, of course, a compiler error.

Finding out why a piece of code (= compiler) we did not see gaps for a particular input is very difficult.

If, on the other hand, you mean that the compiler stops because it reports an error in your code, then, of course, it would be useful to know this and what it says.

Answer 3

I suspect this is a compiler error. Consider submitting an error with the compiler provider and make sure that you plug in the failed source code so that they can reproduce the compiler error. You were unlucky. Try to get around this error now.