No idea, but I do know there was a gcc port to NCR UNIX bootstrapping off their own compiler that stalled for a while until one of the developers worked out that it unrolled switch statements to if+goto ... and used the label 'dflt:' for the default case of the switch.
Sucked to be you if you decided to name one of your own labels that.
Honestly, I'm not sure. In hindsight, I think that there must have been a race condition somewhere else in my code (school project) that this was somehow exposing. Removing the comment reliably resulted in an executable that always did the wrong behavior, and leaving the comment in, the program always worked.
printf() is an old-school fuzzer, so to speak. It may be just a line, but underneath, the call to it brings in a ton of branching and memory alloc and access.
So quite often any latent memory leaks or code issues could lead to such odd behavior. Sometimes it's the opposite - "works" with printf(), but segfaults in some odd place or infiniloops without it.
At times like this, -Wall, valgrind, and critical thinking are the ways to "cherchez le 'bug'"... Multithreaded it is? Good luck!
You don't know what the compiler is doing behind the scenes before it figures out that is a comment. For instance, it might parse the entire function body for printf() and if it finds it then loads some library, only then getting around to actually parsing the function line by line. Think of Javascript hoisting - only dumber.
There was a case, which I cannot find now, where the compiler decided whether the function is small enough to inline based on its source code size, including comments.
