Don’t Blame the Compiler

Don’t Blame the Compiler

The biggest temptation when faced with an error you do not understand is to blame the compiler. However, although compiler bugs are not as uncommon as one would hope, there is probably a 99% or more chance that it is your mistake, especially if you are just learning the C++ language.

There is an even larger temptation to place the blame on the compiler if the code suddenly fails when optimization is invoked. Because of the complexity of optimization technology, there have been many well-known errors in optimizers over the years. However, there are a large number of coding errors that may not cause failures when compiled in one way, but may cause failures with other compiler or optimizer settings. A compiler or optimizer bug is a very convenient excuse, but also an unlikely excuse. More likely is that you have a memory error or some other undefined behavior that was only working by fluke in the non-optimized version.

I remember well the first time that I demonstrated this form of human frailty while learning the C language. A program wasn’t working, and after some debugging effort, the problem was traced to a for loop that was executing only once instead of many times. An experienced programmer can probably diagnose the error from the single statement in the previous sentence, but the program’s behavior seemed very strange to me. Although I don’t remember the exact code, the loop was similar to:

    for (i = 0; i < n; i++);
    {
        /* do something */
    }

Instead of repeating n times, the loop body was executed only once. Can you spot the bug?

The error is, of course, the semicolon immediately after the for loop header, which does not cause a syntax error, but makes the for loop body an empty statement (i.e. a single semicolon) and this mistake causes the intended loop body to be executed only once, after i has been incremented in a do-nothing loop from 0 to n.

Finding this error took me a great deal of time and effort. I spent a lot of time trying to determine the problem with debugging output statements, but with no success. Then, beginning to suspect a compiler bug, I created assembly output using the “cc -S” command. Sure enough, the assembly code showed the compiler generating instructions where control prematurely returned to the top of the loop. The compiler was “erroneously” placing the branch instruction before the first statement of the loop body, which I considered to be “proof” that there was a bug in the compiler. Finally, I demonstrated my “compiler bug” to a friend, who immediately pointed out the extra semicolon. A little knowledge is a dangerous thing.

• Next: • Up: Table of Contents • Buy: Generative AI in C++: Coding Transformers and LLMs

The new AI programming book by Aussie AI co-founders: AI coding in C++ Transformer engine speedups LLM models Phone and desktop AI Code examples Research citations Get your copy from Amazon: Generative AI in C++