I found a bug in the .NET compiler back when I worked at Microsoft, and at first no one wanted to believe me :)
It manifested when you had a single static member of a specific generic type in a class. The program crashed complaining about invalid CLR instructions. If you added a second static member of the same type to the class, or changed the type of the generic parameter, it didn't reproduce.
Turns out it was related to how the compiler used AVX intrinsics on CPUs that supported those instructions.
Pretty fun but took some convincing for people to believe it was a compiler bug.
I don't know why people think compilers are so infallible, or are more likely to be better written than your application. If people write bugs in applications guess what the same people write similar bugs in compilers too.
Probably because everyone still has the numerous starting experiences in the back of their head where they thought their code must be correct and it couldn't possibly your fault only to realize the next day that it was absolutely your fault.
It definitely took me a while to realize that VS was just always executing the default statement of a switch (instead of an applying case) if the default was at the top of the switch instead of the bottom, and only when the switch was being executed at compile time in a constexpr context.
> I don't know why people think compilers are so infallible, or are more likely to be better written than your application.
Since they are rare and written by relatively small and knowledgeable people, most of the users (incl. me) think that they're meticulously tested and developed with utmost care.
I just remembered that one of my applications were hanging in a hot code path if I didn't write a small debug directive in the middle of it. I always thought the problem was with me but, it can be anywhere between me and the silicon. When you're in the middle of the development heat, you always blame your code or the libraries you use. Compiler and the lower levels are not put in the suspect list until bug becomes fairly stubborn to persist.
I maintain compilers for a living for a safety-critical embedded OS. I've found dozens of bugs in the compiler, dozens of bugs in the OS kernel, and dozens of bugs in the third-party validation test suites we use to qualify the compiler.
I also live in a log cabin in the back woods and can go off-grid. I've seen shit you people would not believe. It's just a matter of time now. Dominoes.
There was code in IE 5 that used the original SSE instructions if the chip had them, and regular code as a fallback
We found a stepping of a 486 chip where this code crashed about 25% of the time
Since it was only that stepping, and we already had a fallback path, we just skipped the optimization for that chip version and didn’t investigate exactly what was broken though
Having a lot of customers with various CPU versions helped to track this down pretty quickly
Probably not 486 - this was 1999-2000 timeframe, so some sort of Pentium thing.
It was definitely the new instructions though, so whatever Intel chip had the new features had this 1 stepping that had this bug (and it wasn’t the first version of the chip either)
It manifested when you had a single static member of a specific generic type in a class. The program crashed complaining about invalid CLR instructions. If you added a second static member of the same type to the class, or changed the type of the generic parameter, it didn't reproduce.
Turns out it was related to how the compiler used AVX intrinsics on CPUs that supported those instructions.
Pretty fun but took some convincing for people to believe it was a compiler bug.