Once in a while C++ code will not work when compiled with some level of optimization. It may be compiler doing optimization that breaks the code or it may be code containing undefined behavior which allows the compiler to do whatever it feels.
Suppose I have some piece of code that breaks when compiled with higher optimizations level only. How do i know if it's the code or the compiler and what do I do if it's the compiler?
I would say it is a safe bet that, in the vast majority of the cases, it is your code, not the compiler, that is broken. And even in the extraordinary case when it is the compiler, you are probably using some obscure language feature in an unusual way, for which the specific compiler is not prepared; in other words, you could most likely change your code to be more idiomatic and avoid the weak spot of the compiler.
At any rate, if you can prove that you found a compiler bug (based on the language spec), report it the compiler developers, so that they may get it fixed some time.
Just as usual, as with any other bugs: perform a controlled experiment. Narrow down the suspicious area, turn off the optimisations for everything else and start varying the optimisations applied to that chunk of code. Once you get a 100% reproducibility, start varying your code, introducing things that might break certain optimisations (e.g., introduce possible pointer aliasing, insert external calls with potential side effects, etc.). Looking at the assembly code in a debugger might help as well.
Examine the assembly code that resulted and see if it does what your source is calling for. Remember that the odds are very high that it's really your code at fault in some non-obvious fashion.
In over 30 years of programming, the number of genuine compiler (code generation) bugs I've found is still only ~ 10. The number of my own (and other people's) bugs I've found and fixed in the same period is probably > 10,000. My "rule of thumb" then is that the probability of any given bug being due to the compiler is < 0.001.
int + int to overflow exactly as if it compiled down to a hardware ADD instruction. It worked just fine when compiled with an older version of GCC, but not when compiled with the newer compiler. Apparently the nice people at GCC decided that since the result of an integer overflow is undefined, their optimizer could operate under the assumption that it never happens. It optimized an important branch right out of the code. I would argue that it is your code that is broken. In the unlikely event that you've discovered a bug in the compiler - you should report it to the compiler developers, but that's where the difference ends.
The solution is to identify the offending construct, and refactor it so that it would do the same logic differently. That would most likely solve the issue, whether the bug is on your side or in the compiler.
If you want to know whether it is your code or the compiler, you have to perfectly know the specification of C++.
If doubt persists, you have to perfectly know x86 assembly.
If you are not in the mood of learning both to the perfection, then it is almost certainly an undefined behaviour that your compiler resolves differently depending on optimization level.
Getting a compile error on standard code or an internal compile error is more likely than optimizers being wrong. But i have heard of compilers optimizing loops incorrectly forgetting some side effects a method cause.
I have no suggestions on how to know if its you or the compiler. You may try another compiler.
One day i was wondering if it was my code or not and someone suggested valgrind to me. I spent the 5 or 10mins to run my program with it (i think valgrind --leak-check=yes myprog arg1 arg2 did it but i played with other options) and it immediately showed me ONE line that is ran under one specific case which was the problem. Then my app ran smoothly ever since with no weird crashes, errors or strange behavior. valgrind or another tool like it is a good way to know if its your code.
Side note: I once wondered why the performance of my app sucked. It turned out all of my performance problems was in one line as well. I wrote for(int i=0; i<strlen(sz); ++i) {. The sz was a few mb. For some reason the compiler ran strlen every time even after optimization. One line can be a big deal. From performances to crashes
An increasingly common situation is that compilers break code written for dialects of C that supported behaviors not mandated by the Standard, and allowed code targeting those dialects to be more efficient than strictly-conforming code could be. In such a case, it would be unfair to describe as "broken" code which would be 100% reliable on compilers that implemented the target dialect, or to describe as "broken" the compiler which processes a dialect that does not support the required semantics. Instead, the problems stem simply from the fact that the language processed by modern compilers with optimizations enabled is diverging from dialects which used to be popular (and are still processed by many compilers with optimizations disabled, or by some even with optimizations enabled).
For example, a lot of code is written for dialects that recognize as legitimate a number of pointer aliasing patterns not mandated by gcc's interpretation of the Standard, and makes use of such patterns to allow a straightforward translation of the code to be more readable and efficient than would be possible under gcc's interpretation of the C Standard. Such code may not be compatible with gcc, but that doesn't imply that it's broken. It simply relies upon extensions that gcc only supports with optimizations disabled.
Most likely your code has some undefined behavior (as others explained, you are much more likely to have bugs in your code than in the compiler, even if C++ compilers are so complex that they do have bugs; even the C++ specification has design bugs). And UB can be here even if the compiled executable happens to work (by bad luck).
So you should read Lattner' blog What Every C Programmer should know about undefined behavior (most of it applies for C++11 too).
The valgrind tool, and recent -fsanitize= instrumentation options to GCC (or Clang/LLVM), should also be helpful. And of course, enable all warnings: g++ -Wall -Wextra
Isolate the problematic spot and compare the observed behavior to what should happen according to the language spec. Definitely not easy, but that's what you have to do to know (and not just assume).
I probably wouldn't be that meticulous. Rather, I would ask the compiler maker's support forum / mailing list. If it's really a bug in the compiler, then they might fix it. Probably it would be my code anyway. For example, language specs regarding memory visibility in threading can be quite counterintuitive, and they could become apparent only when using some specific optimization flags, on some specific hardware (!). Some behaviour could be undefined by the spec, so it could work with some compiler / some flags, and not work with some other, etc.
In the end, your compiled code is not working as you want. It is very unlikely that you can fix bugs in the compiler, so you need to change your source code until you have compiled code that works the way you want.
In a situation where you have obviously correct code that doesn’t work and non-obvious code that works, please add a strongly worded comment. Otherwise the next programmer says “this code is stupid and clumsy, I’ll fix it” and recreates the code that is compiled incorrectly.
Now is the compiler at fault? 99% of the time it isn’t. Most important, check for “undefined behaviour”. The behaviour of your code is undefined if the C or C++ Standard says so. “Undefined behaviour” means anything can happen not just things that you would find reasonable. With undefined behaviour, anything the compiler does is correct by definition. Then there is “unspecified behaviour”. There are multiple defined behaviours but the compiler doesn’t tell you which one it uses. What it uses may be unexpected to you but is valid. And there is “implementation defined behaviour”, where every C or C++ compiler must define the behaviour. If you switch compilers, “implementation defined” behaviour can change.
To find if a problem is the compiler’s fault, you need to examine your code very carefully to see if it is correct. If you are 100% sure your code is correct then you can blame the compiler. What do you do then? Find out who maintains the compiler. Try to find the simplest code possible that demonstrates the compiler bug. Then send a bug report to the maintainer of the compiler and hope they fix the problem.
