"Steven Bosscher" <[EMAIL PROTECTED]> writes: > On 12/31/06, Paul Eggert <[EMAIL PROTECTED]> 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).
