gcc -c -Wall -O2 -g -fbreak-my-code main.c

You know what’s fun? When you think you have a nice big chunk of code in a state that could reasonably be considered “working” (as far as pre-alpha software goes, at least), and then you turn on optimization, and then suddenly everything falls apart.

One particularly cute way this can happen is if you tell the compiler a particular function’s return value is constant. gcc assumes that the function also doesn’t have any side effects, and will happily optimize away calls to it if you don’t use the returned value. This is a problem if the function not only has side effects, but you were calling the function precisely to carry those side effects out.

OK, technically it’s my fault for misinforming the compiler and not realizing it until the -O2 flag called me on it. But still. Besides, I still blame the optimizer for somehow finding a way into new and exciting code paths that make test cases stop working.

Apparently it’s going to take a little longer still before the next update on Wallace, since now I’ve got to go through and see what other fun little bugs the optimizer flushes out of my code. Grumble.

5 Responses

  1. sounds like you’re upset that the optimizer is optimizing…

  2. The optimizer’s supposed to make my code do the same thing, but faster. Doing a different thing faster is much less useful.

  3. Simple mistake: you forgot the poorly documented -dwim switch.

  4. Sounds like your optimizer’s fitness function needs work :P

  5. OK, to be fair, some of the bugs might’ve been ones I introduced shortly before switching on the optimizer. Stupid integer overflows.

Comments are closed.