This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Paul Eggert" <eggert at cs dot ucla dot edu>
- Cc: autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org, "Mark Mitchell" <mark at codesourcery dot com>, "Ian Lance Taylor" <iant at google dot com>
- Date: Mon, 1 Jan 2007 20:00:09 -0500
- Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- References: <firstname.lastname@example.org> <20061220123349.GE7947@iam.uni-bonn.de> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com>
On 1/1/07, Paul Eggert <firstname.lastname@example.org> wrote:
Mark Mitchell <email@example.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
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
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
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.