Re: Debugging of optimized code

The first question about debugging optimized code is "Why does the user
want to do it?" The answer may be "Because the bug doesn't show up with
the optimizer turned off."


This means various forms of turning off optimization or hideing its
effects are useless or worse. What the user needs is an explanation of
what the optimizer has done to the code.


This means if intermediate variables are introduced they must be
explained, code motion must be described.


This suggests a language that works by source transformation. The user
can freeze the transformation at various stages and test the code. Various
transformations can be excluded.


Remember optimization only promises to transform correct code in an
invariant manner. Incorrect code can change in a wierd manner. The
following is an C example.


bogus() {
int i; /* unused */
int j; /* unitialized */


if (j) doStuff();
}


j is unitialized and contains some garbage on the stack. i is unused. If
the optimizer removes i it changes the position of j and changes the
behavior of the program.


Thus the fact that optimization turns a bug on or off doesn't mean the
optimizer is broken, but in my experience its a good way to bet. I haven't
actually seen real world situations where that symptom didn't point to a
broken compiler. The examples that would show otherwise all produce lots
of warnings.
--

Return to the comp.compilers page.
Search the comp.compilers archives again.