2 ms·
Agreed. Many times I've seen a bug disappear when I've added printfs or turned on -g, but I've never, ever seen an optimization bug in a C/C++ compiler. The on
by cpncrunch 13y ago
Agreed. Many times I've seen a bug disappear when I've added printfs or turned on -g, but I've never, ever seen an optimization bug in a C/C++ compiler.
The only time I've seen optimization bugs is in the emscripten compiler, but I'm sure those will be ironed out eventually (and the current version seems pretty stable).
- infogulch 13y agoThat has happened to me as well. There's a bug until I add a printf or enable debugging, or (paradoxically) go from -O0 to -O2. What's going on here? Is there some specific class of UB that I'm invoking to get this infuriating bug?
- cpncrunch 13y agoI think it's usually just accessing out of bounds memory / uninitialized read, and -g/-O just happens to change the memory layout enough to cause/prevent the crash.
- userbinator 13y agoIn nearly 2 decades I have seen only one compiler bug, in MSVC6, which was related to large switch statements. The most successful way of finding what's causing these "heisenbugs" is to NOT change the binary, but just load it in the debugger as-is, make a guess at where it's failing, and set a few breakpoints/watchpoints. Either the compiler is not generating the code that you expect, or your expectations of the language were wrong, and both cases are fairly clear from looking at the generated code.