4 ms·
> 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,
by 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 agoTBH, 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 agoStandard compliant programs would be fine, but otherwise "ok" undefined behavior could become breaking. Harsh, but fair.
- einpoklum 4y agoAh, but that's not a compiler bug, that's again an issue with our code... I was only talking about proper bugs.
- eschneider 4y agoA 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 agoOne 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 agoI 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 agoThere 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 agoI 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.