[Top][All Lists]

[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: Fri, 29 Dec 2006 17:09:40 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

address@hidden (Richard Kenner) writes:

> (1) What is the maximum performance loss that can be shown using a real
> program (e.g,. one in SPEC) and some compiler (not necessarily GCC) when
> one assumes wrapping semantics?
> (2) In the current SPEC, how many programs benefit from undefined overflow
> semantics and how much does each benefit?

Those questions are more for the opponents of -fwrapv, so
I'll let them answer them.  But why are they relevant?
Having -fwrapv on by default shouldn't affect your SPEC
score, since you can always compile with -fnowrapv if the
application doesn't assume wraparound.

The SPEC CPU2006 run and reporting rules for peak and base builds
are directly on point here:

   Because the SPEC CPU benchmarks are drawn from the
   compute intensive portion of real applications, some of
   them use popular practices that compilers must commonly
   cater for, even if those practices are nonstandard. In
   particular, some of the programs (and, therefore, all of
   base) may have to be compiled with settings that do not
   exploit all optimization possibilities that would be
   possible for programs with perfect standards compliance.

If the only goal is to get a high SPEC score, it's pretty
clear: disable -fwrapv, and if the SPEC program passes its
benchmark tests, you're happy.  But people who are building
reliable software (as opposed to running benchmarks) cannot
be so blase about latent bugs due to wrapv assumptions being

> (3) How many programs are known to rely on wrap semantics?  For each:
>   (a) How hard was it to determine there was a problem with that assumption?

I'm not sure what you're asking for here.

For example, GCC assumes wrapv internally.  No doubt there
is a problem with this assumption if you go out of your way
to make it a problem (bootstrap GCC with -ftrapv, for
example).  Is this "a problem" in the sense that you

Or do you mean, "how hard is it to determine whether some
real-world compiler, used by a real-world builder of GCC,
won't build GCC correctly due to this problem"?  If that's
the question, then all I can say is that I think it's verrry
hard.  There are a lot of compilers out there, and they're
used in a lot of ways.

>   (b) How much work was it to modify the program to not
>   rely on such semantics?

Nobody knows the answer to that question either.  I could
throw out an estimate for GCC (three person-months, say?
six?) these are just wild guesses.  And that's just one

Part of the problem is that there's no easy way to determine
whether a program relies on these semantics.

reply via email to

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