[Top][All Lists]

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

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

From: Brooks Moses
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sat, 24 Mar 2007 01:40:27 -0700
User-agent: Thunderbird (Windows/20070221)

Robert Dewar wrote:
Ian Lance Taylor wrote:
The new option -fstrict-overflow tells gcc that it can assume the
strict signed overflow semantics prescribed by the language standard.
This option is enabled by default at -O2 and higher.  Using
-fno-strict-overflow will tell gcc that it can not assume that signed
overflow is undefined behaviour.  The general effect of using this
option will be that signed overflow will become implementation
defined.  This will disable a number of generally harmless
optimizations, but will not have the same effect as -fwrapv.

Can you share the implementation definition (implementation defined
generally means that the implementation must define what it does).
This seems awfully vague.

I believe that what Ian means here is that the effect of a signed overflow will be to produce some arbitrary but well-defined result, with "well-defined" here meaning that the program will behave in a manner that's consistent with every subsequent access of it in the source code seeing the same value (until it's redefined, of course). The actual value that is seen should, however, be considered entirely arbitrary.

This is distinguished from the -fstrict-overflow, which can produce results that are inconsistent, such as cases where "n" is negative but the"n>0" path of an "if" statement is taken.

An example of that is "if (m>0) {n=m+1; if (n>0) {...}}". If the -fstrict-overflow option is specified, then the compiler can act as if m+1 never overflows, and optimize away the second check even if the addition is actually implemented with wrap in the case of overflow. Supply m=0xEFFFFFFF to the resulting program, and the "..." gets executed with a negative n.

All that -fno-strict-overflow does is prevent that sort of optimization; it doesn't make any guarantees whatsoever about what value n will actually have in the resulting code, just that program is guaranteed to act as if the "n>0" and the "..." both see the same value.

- Brooks

reply via email to

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