bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Paul Eggert
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Mon, 01 Jan 2007 15:22:44 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Mark Mitchell <address@hidden> 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.

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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]