This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Merging calls to `abort'


On Mon, 2005-03-14 at 03:00, Richard Stallman wrote:
>       This is a difficult choice to make, but at 
>     -O2, I'd prefer that we optimize, and suggest other debugging techniques 
>     intead of relying on the line numbers of abort calls.
> 
> The sole purpose of optimization is to satisfy users more.  If the
> result of this optimization in this particular case is that users are
> dissatisfied, GCC should adapt to the users, not vice versa.
> To say to the users, "GCC doesn't do what you want if you write X,
> so write Y instead", is distinctly inferior to changing GCC so it
> does what you want if you write X.

I disagree with the conclusions you reach from this statement. 
Optimization is really about minimizing some cost metric.  If a user has
asked for gcc to use 'smallest code size' (-Os), for example, then they
aren't going to be satisfied if GCC has not done this on the grounds
that debugging might become a little harder.  The same principle applies
equally to other trade-offs when it comes to -O2 and debugging.  There
are times when an optimization can make debugging so difficult that we
only enable it at -O3, but in the end the user still has control.  Your
suggestion would remove that control.

As things currently stand in GCC, if you really want accurate debugging
you pretty much have to compile -O0.  This is unfortunate, because gcc's
-O0 code is really very poor quality.  I personally think it would be
very nice if gcc had a -Og type option which gave reasonable code with
minimal loss of debugging accuracy.  For example, it would do as much
optimization as possible (cse, combine etc), within a statement, but
would not optimize across statement boundaries.  With such a mode, the
machine state at the end of each statement would exactly represent the
abstract model described by the program at that point.

R.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]