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.
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.
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.
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.
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.