by misonic on 2/20/25, 7:58 AM with 93 comments
by jake_morrison on 2/24/25, 3:28 AM
Years ago, we were building an embedded vehicle tracker for commercial vehicles. The hardware used an ARM7 CPU, GPS, and GPRS modem, running uClinux.
We ran into a tricky bug in the initial application startup process. The program that read from the GPS and sent location updates to the network was failing. When it did, the console stopped working, so we could not see what was happening. Writing to a log file gave the same results.
For regular programmers, if your machine won't boot up, you are having a bad day. For embedded developers, that's just a typical Tuesday, and your only debugging option may be staring at the code and thinking hard.
This board had no Ethernet and only two serial ports, one for the console and one hard-wired for the GPS. The ROM was almost full (it had a whopping 2 MB of flash, 1 MB for the Linux kernel, 750 KB for apps, and 250 KB for storage). The lack of MMU meant no shared libraries, so every binary was statically linked and huge. We couldn't install much else to help us.
A colleague came up with the idea of running gdb (the text mode debugger) over the cellular network. It took multiple tries due to packet loss and high latency, but suddenly, we got a stack backtrace. It turned out `printf()` was failing when it tried to print the latitude and longitude from the GPS, a floating point number.
A few hours of debugging and scouring five-year-old mailing list posts turned up a patch to GCC (never applied), which fixed a bug on the ARM7 that affected uclibc.
This made me think of how the folks who make the space probes debug their problems. If you can't be an astronaut, at least you can be a programmer, right? :-)
by subharmonicon on 2/24/25, 1:57 AM
They have bugs. Lots of them.
With that in mind, the article is correct that the vast majority of issues people think might be a compiler bug are in fact user errors and misunderstanding.
My experience actually working with users has been somewhat humorous in the past, including multiple instances of people completely freaking out when they report something that turns out to be a miscompile. I’ve seen people completely freaking out, to the point that they no longer felt that any code could be trusted since it could have been miscompiled in some way.
by CrossVR on 2/24/25, 4:08 AM
We eventually traced it down to a small for loop that added 0.5 to double members in an anonymous struct. For some reason these three factors: an anonymous struct, double datatypes and a for loop caused those member variables to become uninitialized.
We extracted this code into a small code sample to make it easily reproducible and reported it to Microsoft. Their compiler team called it one of the most helpful reports they'd gotten and confirmed it was a bug in their for-loop vectorization code. The compiler appeared to have messed up the SIMD instructions to write the results of the addition back to memory.
by LiamPowell on 2/24/25, 1:40 AM
I think it's just common for people to assume they're wrong and change things blindly rather than carefully checking the standard for their language (assuming their language even has a standard to check). It doesn't help that before AddressSanitizer and co. existed compilers would just do all sorts of nonsense when they detected possibly undefined code in C and C++.
by vessenes on 2/24/25, 2:58 AM
by procaryote on 2/24/25, 9:00 AM
The thing I disliked most about later learning PHP or Javascript was that my previously usually wrong reaction of "the compiler is insane" suddenly turned out to be commonly true. Even when it wasn't an actual bug PHP and javascript were often so poorly designed that intended behaviour wasn't much better than one.
by kevingadd on 2/24/25, 1:44 AM
It's funny how sometimes a really glaring bug can hide in a stdlib for months or years just because by luck the stars never align to trigger it where somebody can notice it. In my case, the dictionary bug was causing recoverable errors, and I only noticed because I dug in instead of going "Mono's just broken".
by est31 on 2/24/25, 1:56 AM
by dataflow on 2/24/25, 5:21 AM
It's not particularly hard (for someone who knows the language rules, which are difficult for a language like C++) to make a widely-used compiler be erroneous in its acceptance or rejection of code.
What's much more difficult ("never" happens) is to make the compiler accept valid code and then generate an incorrect executable. It's possible (and I run into this maybe once a year doing unusual things) but it's really rare. If you think that's what's going on, it's very unlikely to be the case.
by CGamesPlay on 2/24/25, 4:06 PM
by tomcam on 2/24/25, 1:17 AM
by pfdietz on 2/24/25, 1:47 AM
by pjmlp on 2/24/25, 6:45 AM
function BrokenResult: Integer;
var
BrokenResult: Integer; (* This should not happen *)
begin
BrokenResult := 42 (* Local variable will be assigned, function result is whatever the compiler comes up with*)
end;by dehrmann on 2/24/25, 2:55 AM
Not the right lesson to learn for a first job.
by dredmorbius on 2/24/25, 5:51 PM
But in 30+ years of professional experience, I've also found two compiler-like bugs (I tend to use scripting / interpreted languages, so "compiler" isn't entirely accurate). One was in a commercial software package in which the documentation and implementation of a feature were reversed (what resolved as "true" should have been "false" and vice versa). That resulted in a code fix.
And another was a bug (specifics of which I've since forgotten) in GNU Awk, and not, I painstakingly verified, in my own code. That was also submitted and fixed.
Every other time, though, my own damned fault ;-)
by dang on 2/24/25, 6:43 AM
“It is never a compiler error” - https://news.ycombinator.com/item?id=15699675 - Nov 2017 (272 comments)
by nayuki on 2/24/25, 8:18 AM
I'm not sure why the page is no longer publicly available: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-818... (JDK-8181921)
by okaleniuk on 2/24/25, 6:33 AM
by maginx on 2/24/25, 5:44 PM
I've also found 3-4 JavaScript JIT compiler errors in major browsers, all confirmed. I was a developer on what was for its time a quite complicated JavaScript solution, so we tended to encounter obscure JavaScript errors before others.
by AnimalMuppet on 2/24/25, 1:55 AM
by jcelerier on 2/24/25, 3:27 AM
by lambdaone on 2/24/25, 12:24 PM
by ShroudedNight on 2/24/25, 3:43 AM
by o11c on 2/24/25, 5:27 AM
Thankfully I don't think I ever had any miscompilations - that would require the code actually compile across several compiler versions in the first place.
by groos on 2/24/25, 4:40 PM
by gavinhoward on 2/24/25, 3:48 PM
On the other hand, I have a confirmed bug in Clang [1] and a non-rejected bug in GCC [2], so it does happen.
by iKlsR on 2/24/25, 5:36 PM
by nsoonhui on 2/24/25, 5:44 AM
No, not always true. Even in modern compilers -- as matured and as modern as VS 2022-- you would still get bug.
I found one[0]. In my case it's easy to tell it's a compiler bug because the program just can't compile properly. But it's also not easy to reproduce, which just proves how well tested compilers usually are.
by flerchin on 2/24/25, 3:07 PM
by bitwize on 2/24/25, 2:11 AM
The problem disappeared in Java 1.0.3.
by timpark on 2/24/25, 2:39 AM
by tbrownaw on 2/24/25, 2:00 AM
One was caught by internal checks somewhere, something about struct member offsets that I think was an alignment / padding issue and didn't seem to actually break anything. The other made it segfault during compilation, and I had to just tweak my code blindly until it decided to go away.
by don_neufeld on 2/24/25, 5:37 AM
MSVC did not do a good job of maintaining the FPU stack in those days…
by hasley on 2/24/25, 5:55 AM
My rescue was that I had a more experienced friend who knew that IIRC the compiler would choose the data type of the left operand of a comparison also for the right operand leading to potential sign switches.
by carterschonwald on 2/24/25, 6:22 AM
Miscompilation bugs are definitely nasty though. Especially if it’s a self boot strapping compiler. Save your old build artifacts! :)
by KolmogorovComp on 2/24/25, 9:07 AM
by bmenrigh on 2/24/25, 4:27 AM
When I reflect on the ~25 years I’ve been programming C, all of the times I thought I’d found a compiler bug were in the first ~8 years. Dunning-Kruger hard at work :-/
by rurban on 2/24/25, 3:42 PM
e.g. https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__...
It's massive, and several gcc versions have to be blacklisted. The clang restrict bug is still not fixed, it never worked. rustc was never memory-, type- nor concurrency-safe.
by colonial on 2/24/25, 3:40 AM
by tgma on 2/24/25, 8:22 AM
If you specifically look for them you might find quite a bit: https://web.cs.ucdavis.edu/~su/publications/emi.pdf [disclosure: an author]