autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."


From: Paul Eggert
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Thu, 21 Dec 2006 12:04:05 -0800
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Paolo Bonzini <address@hidden> writes:

>> But the code here
>> is not broken -- it merely assumes C99 + wrapping LIA-1,
>> which is a perfectly reasonable assumption
>
> You said that when loops are involved, it's not.

I don't insist on -fwrapv everywhere.  But I do want
applications to work when they are attempting to detect
integer overflow, whether these attempts are in loops or
not.  If -fwrapv is the only way to get it (assuming -O2),
then -fwrapv will have to do.

> That hunk was added in 1992 and it was not disabled by -fwrapv until
> 2003.  Nobody noticed in the middle.

Then that particular hunk might be OK.  Not all plain -O2
optimizations (withoug -fwrapv) are harmful.  (I haven't
looked into the details.)

However, other optimizations added in 1992 _did_ cause
problems, and _were_ reverted.  It is those sorts of
optimizations that I am worried about.

> What is a commonly used host with padding bits?

None, but C99 allows them, I assume for a good reason.  If
the argument against -fwrapv is that one must write code to
the minimal C99 standard, then why shouldn't I also be
worried about padding bits?

Also, there are compilers with the other problem I mentioned
(complaints about overflow in 1<<31).  Furthermore, you
didn't address the more-important point, which is that the
patch you proposed didn't fix the actual bug.

>> For most GNU programs, I'd guess the performance changes for
>> -fwrapv (whether positive or negative) are unmeasurable, or
>> nearly so.  But -fwrapv's reliability advantages are
>> undeniably positive.  So the default seems like a easy call.
>
> Not so much to me.

The argument against -fwrapv would be more persuasive if it
were backed by performance measurements on commonly-used GNU
programs.  I'm sure omitting -fwrapv helps in some cases and
hurts in others, but the main thing is how much does it help
(or hurt) in the typical case?  The few little measurements
I've done suggest the answer is "not much".

I'm not using a bleeding-edge GCC so my tests are not fair
ones and I don't plan to publish the results.  On the other
hand, if the performance case against -fwrapv were _that_
strong I'd sort of have expected to see some realistic
numbers by now.

In contrast, the argument for -fwrapv is compelling already,
at least to those of us who are trying to maintain reliable
code.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]