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

["Daniel Berlin" <dberlin at dberlin dot org>]

On 1/1/07, Paul Eggert <eggert@cs.ucla.edu> wrote:
> Mark Mitchell <mark@codesourcery.com> writes:
>
> > * Dan Berlin says that xlc assumes signed overflow never occurs, gets
> > much better performance as a result, and that nobody has complained.
>
> Most likely xlc and icc have been used to compile the gnulib
> mktime-checking code many times without incident (though I can't
> prove this, as I don't use xlc and icc myself).  If so, icc and
> xlc do not optimize away the overflow-checking test in question
> even though C99 entitles them to do so; this might help explain
> why they get fewer complaints about this sort of thing.
>
> > I haven't yet seen that anyone has actually tried the obvious: run SPEC
> > with and without -fwrapv.
>
> Richard Guenther added -fwrapv to the December 30 run of SPEC at
> <http://www.suse.de/~gcctest/SPEC/CFP/sb-vangelis-head-64/recent.html>
> and
> <http://www.suse.de/~gcctest/SPEC/CINT/sb-vangelis-head-64/recent.html>.
> Daniel Berlin and Geert Bosch disagreed about how to interpret
> these results; see <http://gcc.gnu.org/ml/gcc/2007-01/msg00034.html>.
> Also, the benchmarks results use -O3 and so aren't directly
> applicable to the original proposal, which was to enable -fwrapv
> for -O2 and less.

No offense, but all enabling wrapv at O2 or less would do is cause
more bug reports about
1. Getting different program behavior between O2 and O3
2. Missed optimizations at O2
It also doesn't fit with what we have chosen to differentiate
optimization levels based on.

IMHO, it's just not the right solution to this problem.

> > Also, of the free software that's assuming signed overflow wraps, can we
> > qualify how/where it's doing that?  Is it in explicit overflow tests?
> > In loop bounds?
>
> We don't have an exhaustive survey, but of the few samples I've
> sent in most of code is in explicit overflow tests.  However, this
> could be an artifact of the way I searched for wrapv-dependence
> (basically, I grep for "overflow" in the source code).  The
> remaining code depended on -INT_MIN evaluating to INT_MIN.  The
> troublesome case that started this thread was an explicit overflow
> test that also acted as a loop bound (which is partly what caused
> the problem).

If your real goal is to be able to just write explicit bounds
checking, and you don't want wrapping semantics for signed integers in
general (which i don't think most people do, but as with every single
person on this discussion, it seems we all believe we are in the 99%
of programmers who want something), then we should just disable this
newly added ability for VRP to optimize signed overflow and call it a
day.
VRP's optimizations are not generally useful in determining loop
bounds (we have other code that does all the bound determination) or
doing data dependence, so you would essentially lose no performance
except in very weird cases.

Of course, you will still be able to come up with cases where signed
overflow fails to wrap.  But IMHO, we have to draw the line somewhere,
and i'm fine with "if you want to test overflow, do it like this and
we will guarantee it will work".

We do the same thing with type punning through unions (guarantee that
reading a different member than you write will work) , even though the
standard says we don't have to.

All the arguments about what most people are going to want are
generally flawed on all sides.  Where there are reasonable positions
on both sides, nobody ever accurately predicts what the majority of a
hugely diverse population of language users is going to want, and
almost everyone believes they are in that majority.

--Dan