This is the mail archive of the
mailing list for the GCC project.
Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
- From: Bruce Korb <bkorb at gnu dot org>
- To: Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc at gcc dot gnu dot org, autoconf-patches at gnu dot org, bug-gnulib at gnu dot org
- Date: Sun, 31 Dec 2006 21:01:23 -0800
- 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> <email@example.com>
- Reply-to: bkorb at gnu dot org
Daniel Berlin wrote:
> I generally have no problem with turning on -fwrapv at O2, but i'm
> curious where this ends.
> After all, strict aliasing makes it hard to write a bunch of styles of
> code people really want to write, and breaks real world programs and
> GNU software.
> Yet we decided to keep it on at O2, and off at O1.
That was a mistake. I have seen a lot of commercial software using
GCC, optimizing at -O2 and ignoring the type punning warnings.
Yes, you can say, "they get what they deserve" and all that, but
it really was a change to the semantics of the language and it was
a mistake to make that change the way it was done. The warnings
needed to have been put in place years ahead of any such change.
They weren't. I seem to recall having to fight hard to get any
warnings at all, in fact. *AFTER* the change had been made.
"People should know better" seemed to be the basic attitude.
Trouble is that most folks cannot afford the time to follow long-
winded, arcane argumentation that one finds in standards committee
> We assume array accesses outside the defined length of an array are
> invalid, but hey, maybe you really know something we don't there too.
I know that zero and one element arrays are used _a_lot_ in commercial
software and that if that were ever really invalidated, the compiler
would get dumped immediately.
> Anyway, if you include "gzip" and "bzip2" in the applications that
> demand performance in integer calculations, then you don't want it off
> at O2. The spec scores show it makes both about 10% slower (at least).
My expectation is that the maintainers of the relatively few packages
such as compression software and number crunchers would be more likely
to be aware of various performance issues and fiddle their options
appropriately. That may be a larger number than 0.1% of software,
but I am reasonably confident that it wouldn't crack 1%, leastwise
in terms of percent of total lines of code compiled by GCC.
> You can distinguish the above cases all you want, but the idea that we
> should trade performance for doing things we've told people for
> *years* not to do, and finally made good on it, doesn't sit well with
> me at all.
"we've told people for *years* not to do"?? You've told practically nobody.
Announcements by standards committees do not constitute "we've told people",
nor even the more widely read list "firstname.lastname@example.org". Very, very few
programmers have the copious free time required to follow such lists.
If you want to tell people that they are about to get whacked the upside of
their head, then you have to start emitting warnings for several years then
hit 'em. It was done backwards for strict aliasing. Shouldn't be done
that way for this.