4 ms·
In my experience, if I've eliminated every other possibility, it's worth actually reading the assembly generated by the compiler. Most compilers are pretty good
by ekidd 12y ago
In my experience, if I've eliminated every other possibility, it's worth actually reading the assembly generated by the compiler. Most compilers are pretty good, but they do contain bugs, and if I completely rule out the possibility that the compiler is generating bad code, I can waste days searching for the problem. Some examples:
1. When compiling certain highly-optimized routines in Quake II, Microsoft Visual C++ generated tail calls that popped the current stack frame before recursing, even though a pointer to a stack variable had already escaped into a global variable. Now, I'm sure there's some technical reason why a C compiler is allowed to generate garbage code here (there usually is—Google "nasal demons"), but it's still easier to debug if you assume the compiler is untrustworthy.
2. The Rubinius FFI had problems passing doubles to external functions: https://github.com/rubinius/rubinius/commit/1122c1c26b81c9691049c8355c809b132b8c8f9c https://github.com/rubinius/rubinius/commit/1122c1c26b81c969...
3. I've broken quite a few in-house and experimental compilers. My favorite error message came from a Lisp compiler: "Lost value of variable 't' in anonymous lambda in anonymous lambda in top-level form."
Now, this sort of thing is rare. If you're using a mature production compiler in CS class, you can assume with near-100% certainty that any problems are your fault. But if you're maintaining a 250K-line program, you upgrade your compiler, and you see some mysterious new backtraces showing up in the crash reporter, then it's entirely possible your compiler is buggy.
As a handy rule of thumb, if you've been staring at a function in a debugger for more than an hour, and you know it's correct, and something weird is still happening, it's time to choose "Show Assembly" and see what's actually going on. It may still be your fault, but it's time to stop trusting the abstractions provided by the compiler and debug your real program—the one the computer actually runs.
- munin 12y ago> you upgrade your compiler, and you see some mysterious new backtraces showing up in the crash reporter, then it's entirely possible your compiler is buggy. IME, there are two more likely causes of this, that are kind of rooted in the same cause: 1. Your code depended on a compiler bug to function, the bug is fixed, and now your code is broken 2. Your code depended on an undefined part of the language semantics, the compiler changed from doing one undefined thing to another, and now your code is broken
- huhtenberg 12y ago> you upgrade your compiler, and you see some mysterious new backtraces showing up in the crash reporter, then it's entirely possible your compiler is buggy. Or it's not a compiler, but a linker now sticking 64bit code above 0x100000000 for shit and giggles. Fun times, ask me how I know :)