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

[Paul Eggert <eggert at CS dot UCLA dot EDU>]

"Steven Bosscher" <stevenb.gcc@gmail.com> writes:

> On 12/31/06, Paul Eggert <eggert@cs.ucla.edu> wrote:
>> Also, as I understand it this change shouldn't affect gcc's
>> SPEC benchmark scores, since they're typically done with -O3
>> or better.
>
> It's not all about benchmark scores.

But so far, benchmark scores are the only scores given by the people
who oppose having -O2 imply -fwrapv.  If the benchmarks use -O3 they
wouldn't be affected by such a change -- and if so, we have zero hard
evidence of any real harm being caused by having -O2 imply -fwrapv.

> I think most users compile at -O2

Yes, which is why there's so much argument about what -O2 should do....

> You say you doubt it affects performance.  Based on what?  Facts
> please, not guesses and hand-waiving...

The burden of proof ought to be on the guys proposing -O2
optimizations that break longstanding code, not on the skeptics.

That being said, I just compiled GNU coreutils CVS on a Debian stable
x86 (2.4 GHz Pentium 4) using GCC 4.1.1.  With -O0, "sha512sum" on the
coreutils tar.gz file took 0.94 user CPU seconds (measured by "time
src/sha512sum coreutils-6.7-dirty.tar.gz").  With -O2 -fwrapv, 0.87
seconds.  With plain -O2, 0.86 seconds.

I also tried gzip 1.3.10, compressing its own tar file with a -9
compression option.  With -O0, 0.30 user CPU seconds.  With -O2
-fwrapv, 0.24 seconds.  With -O2, 0.24 seconds.

In all these cases I've averaged several results.  The difference
between -O2 and -O2 -fwrapv is pretty much in the noise here.

Admittedly it's only two small tests, and it's with 4.1.1.  But that's
two more tests than the -fwrapv naysayers have done, on
bread-and-butter applications like coreutils or gzip or Emacs (or GCC
itself, for that matter).