"Steven Bosscher" <address@hidden> writes:
> On 12/31/06, Paul Eggert <address@hidden> 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).