Tangent: there are lots of points to debate about how code should be commented, but this is the kind of code that must always, always be commented explicitly.
The OP is a great story where the coder had the time (well, was forced to have the time!) and insight to actually find an underlying hardware issue behind the bug -- and could also contact the hardware developers directly, present the details, and get it fixed.
Most of the time these kinds of bugs are never narrowed down to the hardware, compiler, VM, scripting engine, whatever... they're attacked with the "change things until it works" approach, and then the developer moves on.
It can work, though of course it's fragile because it's based on ignorance... but for practical reasons it's probably going to stay the most common approach for mysterious bugs.
The most important thing is documentation -- because the fix is fragile (maybe a tiny change in timing elsewhere will bring back the bug), and it's likely some other dev will need to dig deeper to provide a better fix. If you've documented exactly what you found so far, what worked and what didn't, etc., you can save a lot of wasted time and frustration.
If it was an embedded system, some of the widely-used compilers are apparently rather lacking in functionality compared to the desktop ones, so it might not be able to.
