Thinking Parallel

A Blog on Parallel Programming and Concurrency by Michael Suess

Sometimes, it IS the compilers fault!

I am writing this quick note, because today I wasted at least an hour looking for a bug in my code, when it was really a bug in the compiler. And when I like something even less than bugs, its wasted time :x. Therefore, I will repeat my simple advice to myself here, to make sure I remember the next time: Sometimes, it IS the compilers fault!

Huh, that felt good :). Perhaps a little more explanation about my background and why this is not self-evident for me is in order: When I started programming (yes, I still remember that time 8)) and something did not work out as expected, I was very quick to blame the compiler (the joys of youth :D). I see my students doing this today as well. There is one thing to keep in mind, though: I started programming in C (actually, I did Pascal before that, but that’s not the point) in about 1994. By that time, the language and its compilers were quite old and well-tested already. Therefore, most of the time, the compiler was right, and the real error-source was sitting in front of the keyboard. I do not remember finding a single real bug in a compiler at that time, especially since I kept away from the more advanced language features, because after all I was a beginner back then. At that time, I learned this simple lesson: the compiler is always right.

The times have obviously changed. Since I am doing OpenMP-development with C++ now, I find bugs in the compilers from time to time. In all of them (I usually test my stuff on at least the Intel Compiler, the Sun Compiler, the Portland Group Compiler and sometimes on the IBM and old KAI-Compiler – and will try GCC with OpenMP-support as soon as it is officially stable). If I stick to C, I am usually pretty safe. Bring in C++, and there are bugs. Of course, I report them and the vendors are usually very responsive and fix them in a very reasonable time. And of course, I have the luxury to be able to make sure it actually is a bug in the compiler just by trying out a couple of them. If the code only breaks on one of them, I have usually found a bug. Many programmers do not have this luxury, e.g. when their employer only uses one compiler (which is a bad idea, for exactly this reason and for the wise saying of an ancient programmer: More compilers find more bugs! :P)

But still, there are times like today, when I wish I could just turn back the time to the beginning of my life as a programmer, when all the segmentation faults, stack overflows and triggered assertions of my programs could be blamed on a single point of failure: Me!

Comments are closed