I have been the first to trigger two CPU bugs and came across a third a few days after it was discovered, before it was published. Once errata are published, software workarounds are usually put in place quickly, and tripping over them is rare.
Compiler bugs are another story entirely. I have found dozens of them (confirmed), and I can find more whenever I feel like it.
Out of curiosity, if someone paid you to find compiler bugs for a day, how would you go about it?
(I've found several missed-optimization bugs in gcc, but I found them while working on a project where I examine assembly frequently; I have no idea how I'd go about looking for a compiler bug).
One way of actively looking for compiler bugs is using a tool like Csmith[1]. Another is to compile some known-difficult code (e.g. Libav[2]) with various combinations of (optimisation) flags until the test suite fails. Most of the bugs I've found were during routine testing of Libav.
While I don't consider missed optimisations bugs as such, they are easy to find. Simply compile some non-trivial function and look at the output. There's usually something that could be done better, especially if some exotic instruction can be used.
> While I don't consider missed optimisations bugs as such, they are easy to find. Simply compile some non-trivial function and look at the output.
Perhaps you'll give me a little credit :) if I mention that I found missed optimization bugs in extremely trivial functions. One of them involved gcc generating several completely useless stores even at -O3: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44194
Compiler bugs are another story entirely. I have found dozens of them (confirmed), and I can find more whenever I feel like it.