3 ms·

> As a programmer, you learn to blame your code first, second, and third... and somewhere around 10,000th you blame the compiler. Well down the list after that,

> As a programmer, you learn to blame your code first, second, and third... and somewhere around 10,000th you blame the compiler. Well down the list after that, you blame the hardware. So, first - in many settings, the hardware is more likely to be the source of the problem than your compiler; the question is what has more churn - the compiler code or the chip you run on. But regardless - the compiler is much higher than the 10,000'th item on the blame list. Even mature, popular compilers have bugs! Hell, they have many known, open bugs! The subtle ones, which don't manifest easily, can stay open for quite a long time. See: https://gcc.gnu.org/bugzilla/ https://gcc.gnu.org/bugzilla/ and: https://bugs.llvm.org/ https://bugs.llvm.org/ I personally have encountered and even filed several of them, and it's not like I was trying. Some of these were even the result of "Why does my code not work?" questions on StackOverflow. One tip, though: Play one compiler against another when you begin suspecting your compiler, or the hardware. The buggy behavior will often be different. And of course run multiple times to check for variation in behavior, like the author had.

AshamedCaptain 4y ago
> But regardless - the compiler is much higher than the 10,000'th item on the blame list. Even mature, popular compilers have bugs! Hell, they have many known, open bugs! I don't even understand when compilers started being thought as these perfect, bug-free programs. It's been some kind of gradual change over the decades. A lot of people seem surprised when I mention that around 15 years ago -O3 in gcc was practically unusable. I don't mean "it would actually degrade performance", I mean "it would break your program".
- einpoklum 4y ago
  TBH, I'm surprised by that. I would have though compiler authors would not have released optimization options in this state - when such breakage is encountered by testers of nightlies or beta releases.
  - eschneider 4y ago
    Standard compliant programs would be fine, but otherwise "ok" undefined behavior could become breaking. Harsh, but fair.
    - einpoklum 4y ago
      Ah, but that's not a compiler bug, that's again an issue with our code... I was only talking about proper bugs.
      - eschneider 4y ago
        A good chunk of what people (used to) term "optimization bugs" fell under that umbrella. Program works w/ optimization off, but fails w/ optimization on. Or optimization would "fail" because of program bugs like uninitialize memory that "works" w/ optimization off. Even with old compilers, if you turned optimization on and saw problems, it was almost always an issue with the code being compiled, not the compiler. But that's often not how the blame was laid.
- AlotOfReading 4y ago
  One of the GCC 3.3.x releases (possibly 6?) was completely broken if you attempted to build from source because they applied some last minute patches that didn't compile on most systems and never tested it. That said, the reputation in those days was that the compiler was essentially perfect circa GCC 2.7, and the rewrite to support C99 created innumerable bugs that would never be fixed, especially if you used that sketchy -O2 option. -O0 for correctness and -O1 for ahem, "speed". It took awhile to get back there, but mainstream compilers are probably the most correct and reliable software in common use today, often exceeding large parts of the OS they're running on. It's only with weird, obscure targets and new features that you tend to run into the rough edges that are actually broken.
  - unnah 4y ago
    I would bet that a substantial fraction of the rumoured GCC 3 bugs were originally caused by undefined behaviour in the compiled source, as new advanced compiler optimizations were being introduced in the GCC 3 series. (On the other hand, those newly introduced optimizations likely did have many bugs to begin with...) At the time of GCC 2.7, no one really expected pointer access through the wrong type or signed integer overflow to cause anything weird. The CPU would just read whatever was in memory at the pointed address, and integers would wrap around just like in assembly.
- jamesfinlayson 4y ago
  There are comments in studiomdl (Valve Software's model compiling program) that say stack fixups in Visual Studio 2002 or 2003 broke Release builds so optimisations are turned off for that project.
- mnw21cam 4y ago
  I certainly remember a reasonable stretch of time where the advice was that the Linux kernel would not compile correctly with the latest gcc with optimisations on, and you should use the known good version of gcc instead.
Karellen 4y ago
After the 10,000th bug in your program that turned out to be a bug in your code, not the compiler, the compiler ends up a long way down the list. Even if compilers do have bugs, the code you write (OK, the code I write) has a lot more bugs than the compiler does. "It's never the compiler" is like "It's never lupus". Sure, sometimes it is actually the compiler, or lupus. But 9,999 times out of 10,000, no, it's not. You want to think it is, because a bug in someone else's code is much easier on the ego than yet another bug in your code. But reality and experience is a harsh teacher, and cares not for your ego. If you've found several compiler bugs without even trying, and often enough compared to the number of bugs your write yourself that the compiler is a likely culprit when you come across something hinky, well, by my reckoning that puts you in pretty rarefied company. Congrats on being a 100x developer, or whatever. For the rest of us mortals, it's never the compiler.
- dataflow 4y ago
  It really depends what sorts of compiler bugs you're referring to. I think you're thinking of codegen bugs, which are indeed rare. But on the front-end/parsing side for something like C++, it's really not uncommon to encounter buggy compiler behavior. This isn't an indictment of their developers though - the spec is just super complicated and confusing with weird corner cases and ambiguities.
  - jesse__ 4y ago
    Can confirm that I routinely run into situations where I think the C++ compiler should be able to _nearly_ trivially infer the types code I'm writing, but for some reason or another, it can't. I have no idea if these situations are due to the spec, bugs, or a mixture of both, but they do happen, and pretty frequently at that.
- hyperman1 4y ago
  That depends a lot on your programming environment Today, for major compilers like gcc, I'd agree. But I've worked with a lesser known compiler in the '90s, that would miscompile things on a monthly basis. Sometimes just renaming a local variable would 'fix' it. Another world is embedded, where you might work with a compiler provided by the hardware vendor. These tend to be focused on hardware, with software like compilers as an afterthought. I've heard plenty of stories of decades-old vendor-patched gcc compilers or even some half-tested monstrosity from the vendor itself. Stumbling upon compiler bugs is distressingly easy over there. Same goes for hardware. Any x86 based desktop/laptop/server is ridiculously stable, even considering overclocking and ram bit flips. But embedded hardware is a whole different can of worms. I've stabilized crashing software by adding a capacitor to a hardware board. None of this means I'm a 100x dev, just that different parts of IT have different experience.

AshamedCaptain 4y ago

> But regardless - the compiler is much higher than the 10,000'th item on the blame list. Even mature, popular compilers have bugs! Hell, they have many known, open bugs! I don't even understand when compilers started being thought as these perfect, bug-free programs. It's been some kind of gradual change over the decades. A lot of people seem surprised when I mention that around 15 years ago -O3 in gcc was practically unusable. I don't mean "it would actually degrade performance", I mean "it would break your program".

einpoklum 4y ago
TBH, I'm surprised by that. I would have though compiler authors would not have released optimization options in this state - when such breakage is encountered by testers of nightlies or beta releases.
- eschneider 4y ago
  Standard compliant programs would be fine, but otherwise "ok" undefined behavior could become breaking. Harsh, but fair.
  - einpoklum 4y ago
    Ah, but that's not a compiler bug, that's again an issue with our code... I was only talking about proper bugs.
    - eschneider 4y ago
      A good chunk of what people (used to) term "optimization bugs" fell under that umbrella. Program works w/ optimization off, but fails w/ optimization on. Or optimization would "fail" because of program bugs like uninitialize memory that "works" w/ optimization off. Even with old compilers, if you turned optimization on and saw problems, it was almost always an issue with the code being compiled, not the compiler. But that's often not how the blame was laid.
AlotOfReading 4y ago
One of the GCC 3.3.x releases (possibly 6?) was completely broken if you attempted to build from source because they applied some last minute patches that didn't compile on most systems and never tested it. That said, the reputation in those days was that the compiler was essentially perfect circa GCC 2.7, and the rewrite to support C99 created innumerable bugs that would never be fixed, especially if you used that sketchy -O2 option. -O0 for correctness and -O1 for ahem, "speed". It took awhile to get back there, but mainstream compilers are probably the most correct and reliable software in common use today, often exceeding large parts of the OS they're running on. It's only with weird, obscure targets and new features that you tend to run into the rough edges that are actually broken.
- unnah 4y ago
  I would bet that a substantial fraction of the rumoured GCC 3 bugs were originally caused by undefined behaviour in the compiled source, as new advanced compiler optimizations were being introduced in the GCC 3 series. (On the other hand, those newly introduced optimizations likely did have many bugs to begin with...) At the time of GCC 2.7, no one really expected pointer access through the wrong type or signed integer overflow to cause anything weird. The CPU would just read whatever was in memory at the pointed address, and integers would wrap around just like in assembly.
jamesfinlayson 4y ago
There are comments in studiomdl (Valve Software's model compiling program) that say stack fixups in Visual Studio 2002 or 2003 broke Release builds so optimisations are turned off for that project.
mnw21cam 4y ago
I certainly remember a reasonable stretch of time where the advice was that the Linux kernel would not compile correctly with the latest gcc with optimisations on, and you should use the known good version of gcc instead.

Karellen 4y ago

After the 10,000th bug in your program that turned out to be a bug in your code, not the compiler, the compiler ends up a long way down the list. Even if compilers do have bugs, the code you write (OK, the code I write) has a lot more bugs than the compiler does. "It's never the compiler" is like "It's never lupus". Sure, sometimes it is actually the compiler, or lupus. But 9,999 times out of 10,000, no, it's not. You want to think it is, because a bug in someone else's code is much easier on the ego than yet another bug in your code. But reality and experience is a harsh teacher, and cares not for your ego. If you've found several compiler bugs without even trying, and often enough compared to the number of bugs your write yourself that the compiler is a likely culprit when you come across something hinky, well, by my reckoning that puts you in pretty rarefied company. Congrats on being a 100x developer, or whatever. For the rest of us mortals, it's never the compiler.

dataflow 4y ago
It really depends what sorts of compiler bugs you're referring to. I think you're thinking of codegen bugs, which are indeed rare. But on the front-end/parsing side for something like C++, it's really not uncommon to encounter buggy compiler behavior. This isn't an indictment of their developers though - the spec is just super complicated and confusing with weird corner cases and ambiguities.
- jesse__ 4y ago
  Can confirm that I routinely run into situations where I think the C++ compiler should be able to _nearly_ trivially infer the types code I'm writing, but for some reason or another, it can't. I have no idea if these situations are due to the spec, bugs, or a mixture of both, but they do happen, and pretty frequently at that.
hyperman1 4y ago
That depends a lot on your programming environment Today, for major compilers like gcc, I'd agree. But I've worked with a lesser known compiler in the '90s, that would miscompile things on a monthly basis. Sometimes just renaming a local variable would 'fix' it. Another world is embedded, where you might work with a compiler provided by the hardware vendor. These tend to be focused on hardware, with software like compilers as an afterthought. I've heard plenty of stories of decades-old vendor-patched gcc compilers or even some half-tested monstrosity from the vendor itself. Stumbling upon compiler bugs is distressingly easy over there. Same goes for hardware. Any x86 based desktop/laptop/server is ridiculously stable, even considering overclocking and ram bit flips. But embedded hardware is a whole different can of worms. I've stabilized crashing software by adding a capacitor to a hardware board. None of this means I'm a 100x dev, just that different parts of IT have different experience.