Re: Debugging of optimized code

Charles Fiterman <cef@geodesic.com>
Wed, 25 Jan 1995 15:03:30 GMT

          From comp.compilers

Related articles
[8 earlier articles]
Re: Debugging of optimized code baynes@ukpsshp1.serigate.philips.nl (1995-01-26)
Re: Debugging of optimized code sam@ccnet.com (1995-01-27)
Debugging of optimized code ssimmons@convex.convex.com (1995-01-27)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
Re: Debugging of optimized code urs@engineering.ucsb.edu (1995-01-27)
Re: Debugging of optimized code miker@metaware.com (1995-01-24)
Re: Debugging of optimized code cef@geodesic.com (Charles Fiterman) (1995-01-25)
Re: Debugging of optimized code danhicks@aol.com (1995-01-27)
Re: Debugging of optimized code danhicks@aol.com (1995-01-29)
Re: Debugging of optimized code monnier@di.epfl.ch (Stefan Monnier) (1995-01-27)
Re: Debugging of optimized code jqb@netcom.com (1995-02-02)
Debugging of optimized code ssimmons@convex.convex.com (1995-02-02)
Re: Debugging of optimized code copperma@grenoble.rxrc.xerox.com (1995-01-30)
[7 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers
From: Charles Fiterman <cef@geodesic.com>
Keywords: debug, optimize
Organization: Geodesic Systems
References: 95-01-036 95-01-067
Date: Wed, 25 Jan 1995 15:03:30 GMT

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.
--


Post a followup to this message

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