Embarrassing story time: I was this guy at one point. I had the vast misfortune of finding a compiler bug early in my career. It was in a somewhat obscure variant of gcc cross-compiling for a slightly obscure architecture (PowerPC). I still remember learning PowerPC, reading through the code, and determining that it was indeed the dcc compiler at fault. It was, frankly, an awesome feeling. Especially because this bug took two weeks to track down.

My coworkers naturally doubted that I had found a compiler bug. Correspondence with the compiler's developer confirmed my initial finding. I was vindicated, and could prove I had caught one of the most reclusive bugs of them all.

Fast forward two years, and my coworker is having trouble with MSVC 6 (an old compiler, even at the time). The behaviour seems odd, and my mind jumps back to that one bug I found previously. We isolate it down to one line, and I state with confidence that the compiler generated incorrect code.

My coworker agreed at the time. But the next day, after re-reading the code, he pointed out that I had read it incorrectly. The compiler was doing exactly the right thing. To further my embarrassment, it wasn't even some obscure feature of C (like trigraphs). I made a common mistake and misunderstood basic pointer arithmetic. I still feel an urge to slam my head into my desk right now.

Morale of the story: compiler errors are rare. Really rare. I essentially caught bigfoot on my first hunting trip. Now I have to reassure myself I'm not seeing him again every time I'm confronted with a difficult debugging problem.

Or in technical terms, only declare you have found a compiler error if you have:

(1) read the generated assembly

(2) re-read the code several times alongside the relevant language specification

(3) developed a reproducible example

(4) formulated a plausible theory of what went wrong in the compiler, and contacted the vendor who has confirmed your suspicion