This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: "Daniel Berlin" <dberlin at dberlin dot org>
- To: "Richard Guenther" <richard dot guenther at gmail dot com>
- Cc: "Paul Eggert" <eggert at cs dot ucla dot edu>, autoconf-patches at gnu dot org, bug-gnulib at gnu dot org, gcc at gcc dot gnu dot org
- Date: Sun, 31 Dec 2006 19:13:04 -0500
- Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- References: <200612300047.kBU0lFwk014817@localhost.localdomain> <email@example.com> <10612302258.AA24598@vlsi1.ultra.nyu.edu> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org>
On 12/31/06, Richard Guenther <email@example.com> wrote:
On 12/31/06, Daniel Berlin <firstname.lastname@example.org> wrote:
> On 12/31/06, Paul Eggert <email@example.com> wrote:
> > "Steven Bosscher" <firstname.lastname@example.org> writes:
> > > On 12/31/06, Paul Eggert <email@example.com> 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.
> The burden ought to be (and IMHO is) on those who propose we change
> optimizer behavior in order to support something non-standard.
> Why do you believe otherwise?
> > 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).
> These are not performance needing applications.
> I'll happily grant you that adding -fwrapv will make no difference at
> all on any application that does not demand performance in integer or
> floating point calculations.
I added -fwrapv to the Dec30 run of SPEC at
Note the distinct drop in performance across almost all the benchmarks
on Dec 30, including popular programs like bzip2 and gzip.