Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."

[Ian Lance Taylor]

Paul Eggert <address@hidden> writes:

> Ralf Wildenhues suggested bugzilla originally, but Andrew Pinski
> responded <http://gcc.gnu.org/ml/gcc/2006-12/msg00460.html> that the
> problem "has been observed many, many times and talked about a lot of
> time on this list" and implied strongly that the issue was settled and
> was not going to change.  And bugzilla entries complaining about the
> issue (e.g., 18700, 26358, 26566, 27257, 28777) have been closed with
> resolution INVALID and workaround "use -fwrapv".  So it seemed to me
> like it would have been a waste of everybody's time to open another
> bugzilla entry; the recommended solution, apparently, was to use
> -fwrapv.  Hence the "Subject:" line of this thread.

Well, Andrew does not speak for the gcc community as a whole (and
neither do I).  Looking through your list of bugs:

18700: I believe this is correct default behaviour.
26358: I think this is questionable default behaviour.
26566: I think this is questionable default behaviour.
27257: I think this is correct default behaviour.
28777: I think this is questionable default behaviour.

The common theme of these five cases is that I think that gcc should
not by default use the fact that signed overflow is undefined to
completely remove a loop termination test.  At least, not without a
warning.


> > Historically we've turned on -fstrict-aliasing at -O2.  I think it
> > would take a very strong argument to handle signed overflow
> > differently from strict aliasing.
> 
> I take your point that it might be cleaner to establish a new GCC
> option rather than overload -O2.  That would be OK with me.  So, for
> example, we might add an option to GCC, "-failsafe" say, to disable
> "unsafe" optimizations that may well cause trouble with
> traditional/mainstream applications.  We can then change Autoconf to
> default to -O2 -failsafe.
> 
> However, in thinking about it more, I suspect most application
> developers would prefer the safer optimizations to be the default, and
> would prefer enabling the riskier ones only with extra -f options.
> Thus, perhaps it would be better to add an option "-frisky" to enable
> these sorts of optimizations.

I don't agree with this point.  There is a substantial number of
application developers who would prefer -failsafe.  There is a
substantial number who would prefer -frisky.  We don't know which set
is larger.  We get a lot of bug reports about missed optimizations.

Also, it does not make sense to me to lump together all potentially
troublesome optimizations under a single name.  They are not all the
same.


> I think in the long run the best results will come from a series of
> changes, some to GCC, some to Autoconf, some to Gnulib, and some no
> doubt elsewhere.  I welcome adding warnings to GCC so that programmers
> are made aware of the problems.  If the warnings are reliable and do
> not have too many false alarms, they will go a long way towards fixing
> the problem.  However, I doubt whether they will solve the problem all
> by themselves.
> 
> I have not installed the Autoconf patch (much less published a new
> version of Autoconf with the patch) because I too would prefer a
> better solution.  But the bottom line is that many, many C
> applications need a solution that errs on the side of reliability, not
> one that errs on the side of speed.  As far as I can tell the Autoconf
> patch is so far the only proposal on the table with this essential
> property.

I don't really see how you move from the needs of "many, many C
applications" to the autoconf patch.  Many, many C applications do not
use autoconf at all.

I think I've already put another proposal on the table, but maybe I
haven't described it properly:

1) Add an option like -Warnv to issue warnings about cases where gcc
   implements an optimization which relies on the fact that signed
   overflow is undefined.

2) Add an option like -fstrict-signed-overflow which controls those
   cases which appear to be risky.  Turn on that option at -O2.

It's important to realize that -Warnv will only issue a warning for an
optimization which actually transforms the code.  Every case where
-Warnv will issue a warning is a case where -fwrapv will inhibit an
optimization.  Whether this will issue too many false positives is
difficult to tell at this point.  A false positive will take the form
"this optimization is OK because I know that the values in question
can not overflow".

Ian