On 12/31/06, Bruce Korb <[EMAIL PROTECTED]> wrote:
Daniel Berlin wrote:
>> 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.
It seems then that this pretty-much ought to settle it:
If the only folks that would really care are those that do performance
critical work, then 99.9% of folks not doing that kind of work should
not bear the risk of having their code break. The long standing
presumption, standardized or not, is that of wrapv semantics.
Changing that presumption without multiple years of -Wall warnings
is a Really, Really, Really Bad Idea.
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.
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.
Nothing but apps that actually do real work (and not just large
amounts of I/O) will notice these things.
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).
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.
