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

[Paul Eggert]

Ian Lance Taylor <address@hidden> writes:

> I'm not entirely happy with what I take to be stampeding it by
> introducing what I believe would be a completely inappropriate patch
> to autoconf, rather than, say, opening a gcc bugzilla problem report
> for the cases you feel gcc should handle differently.

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.

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

Whichever way it's done, the idea is to give a convenient way to
enable/disable the more-controversial optimization strategies that
cause problems with many real-world programs that don't conform
strictly to the C standard.

> You are asserting that most programmers assume -fwrapv, but, except
> for your initial example, you are presenting examples which gcc
> already does not change.

That's true, but so far the only position that the GCC developers have
taken that users can rely on, is that all these examples rely on
undefined behavior, and that unless you specify -fwrapv GCC is
entitled to break them in the future if it doesn't already break them.
For many C applications, that is not a tenable situation: right or
wrong, there are simply too many places where the code assumes wrapv
semantics.

In the long run, there has to be a better way.  In the short run, all
we have now is -fwrapv, so we can use that.

> I already took the time to go through all the cases for which gcc
> relies on signed overflow being undefined.  I also sent a very
> preliminary patch providing warnings for those cases.  I believe that
> we will get the best results along those lines, not by introducing an
> autoconf patch.

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.