Switching off the compiler optimizer may just "hide" the bug because memory accesses are reordered in a way that makes the bug (for instance a memory corruption or some allocation problem) less likely to trigger a segmentation fault.<p>To think that every time you have a bug that is suppressed switching off the optimizer you found a compiler bug is not a good idea. 99.99999% of the times the problem is in your code.<p>Experienced programmers usually will continue to think the bug is in their own code unless they can <i>prove</i> otherwise.
My experience goes in a different direction: when you see different behavior when compiled with and without optimization, suspect a memory allocation error or overrun. While compiler optimization bugs do exist, I've more often found that the problem is real.<p>If you are working with your own code and care if it works:<p><pre><code> 1) Turn on all compiler warnings
2) Change your code so it compiles clean
3) Run under Valgrind (or equivalent).
4) Address all reported errors, specifically
whitelisting them if necessary.
5) If you find a bug, don't stop until you've found
the cause. You're done when you understand what
caused the bug to appear, not when the symptoms go away.
6) Use open source tools, since otherwise you'll be
tempted to blame some unspecified 'bug in the compiler'.
(not that ESR would be using any other)
7) If it is a compiler bug, report it, along with
the smallest test case you can generate.</code></pre>
It's seems strange me to instantly suspect that your compiler's optimizer is at fault. Which is more likely: you've found a bug in a compiler used the world over, or you've screwed up memory access?<p>Since C makes it easy to overrun memory, it's pretty easy to make horrible mistakes and have those have seemingly random consequences.<p>The fact that the bug changes when you change optimizer settings, add trace statements, or add debug code would make me suspect memory corruption first.<p>In fact, I think it's a good assumption to always begin suspecting your own code.
I have an example of a bug I found that looked like an optimization bug but was really a user bug. Someone had the bright idea of sprintf-ing to a string and using the string itself as one of the format arguments to the sprintf call. When compiled with gcc the code would still run fine, but when compiling with -O1 the string would end up garbled. The problem (and advantage, performance-wise) of C is that most of the time you do something wrong, the behavior is undefined, whereas most higher-level languages will spend the CPU cycles to protect you from yourself.<p>Another example I can't remember the details of, but it was related to the fact that gcc adds code to zero-initialize your stack on first access unless optimizations are turned on. Code that checked for null pointers worked fine until optimizations were turned on, at which point it was discovered that a variable was being used uninitialized.
Except multi-thread programming, I didn't find any compiler's optimizer related bugs. The truth is, most heisenbugs I found are somewhat related to memory access. It is just too risky to assume it is a compiler bug. I always think in the other way: unless you can prove (by generating assembly code and a possible scenario), the bug is in your code.
It's not quite the same as the 'heisenbug' but I've seen a couple of cases over the years where a mysterious problem was resolved by moving to the latest update of the C/C++ runtime. It's weird how many enterprises are fine with running years behind on maintenance on that.
I found an optimizer bug once. I can't remember the exact circumstances, but it had to do with some fancy inline incrementing I was doing. The very concept that I'd found a bug in <i>somebody else's code</i> floored me.<p>I was young.
I didn't expect a kind of Spanish inquisition...<p>The terminally curious may download a file containing the assembler output, and the C source, of the offending file from <a href="http://www.hercules-390.org/esamebug.zip" rel="nofollow">http://www.hercules-390.org/esamebug.zip</a> . This corresponds to revision 5627 of the Hercules emulator as found in the Subversion repository at svn://svn.hercules-390.org/hercules/trunk . The emulator itself is at <a href="http://www.hercules-390.org" rel="nofollow">http://www.hercules-390.org</a> .<p>The routine is in the generated assembler as z900_load_multiple_long.
I found the bug (I think).. It's not "really" an optimizer bug per-se (although it is CLEARLY triggered by the optimizer).<p>Always treat __asm with caution !<p>--Ivan