3 ms·

And the punchline: the heisenbug in question was in the code being compiled, not the compiler (http://esr.ibiblio.org/?p=1705&cpage=1#comment-248245 http://esr

• jessaustin 13y ago
  Indeed, one wonders whether that revelation might have been the entire reason for this belated post to HN. I don't particularly feel sorry for him, but ESR does get a hard time around here.
• to3m 13y ago
  I think if the code changes due to adding or removing -g, that's definitely a bug in the compiler! If the generated code does things that can't be represented in the debug info, there are plenty of better solutions, with generating useless debug info being an obvious one. Useless debug info is annoying, but far from the end of the world, not least because just about any experienced programmer will be used to it by now...
  • GFK_of_xmaspast 13y ago
    The only "compiler bugs" I have ever seen in 20+ years of coding have all, with the exception of the times the compiler itself crashed, all been user error, and most of those errors are things like using uninitialized values (-g, at least on some compilers, sets memory to 0, instead of 'whatever's on the stack at the moment') or stack corruption that corrupted different parts of the stack at different optimization levels.
    • to3m 13y ago
      -g should really be controlling the emission of debug info, and nothing else, I would have thought? This is independent of the amount of optimization being performed. In fact the code part of the result should be identical in both cases, and ideally at runtime it should be impossible to tell the difference between -g and not (since presumably the loader won't load/map the debug info even if it's embedded).