Re: Debugging of optimized code

Charles Fiterman <cef@geodesic.com> writes:
> 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 is a superb reason, but far from the only one. Maybe the code
won't fit on the machine unoptimized (say, in an embedded application).
Maybe it won't run fast enough (many scientific codes run for hours
days, or weeks, optimized, and simply too long unoptimized).
Maybe the unoptimized code is irrelevant (say, in a real-time system,
where the performance difference translates immediately to a behavioral
difference). These are all special case situations, but the most common
situation is when the production code is optimized. To run an unoptimized
version is to run different code than the customer is running, and often
means creating a special version, which can be an unbelievable time sink
for a programmer. I think "why isn't it supported" is a much better question.


It's very true that optimizing a buggy program with a correct compiler can
change the program's behavior. I'm glad Mr. Fiterman gave his simple
example, because it is a common misconception. Unlike him, seeing such a
behavioral change I would not give odds that the compiler is to blame.
Optimization probably would cause program behavior to change about as
often as running code under the debugger, since the same kinds of things
cause the behavioral changes in both cases. We see the changes less
frequently because we don't usually run a program optimized and
unoptimized.




Max Copperman
--

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