This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: Paul Eggert <eggert at CS dot UCLA dot EDU>
- To: autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org
- Cc: Mark Mitchell <mark at codesourcery dot com>
- Date: Mon, 01 Jan 2007 15:22:44 -0800
- 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>
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.
> 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