[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: Michael Veksler
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: Sun, 31 Dec 2006 11:31:24 +0200
User-agent: Thunderbird (X11/20061105)

Robert Dewar wrote:
Andrew Pinski wrote:


Again, please don't this the default for Fortran as integer
overflow has been undefined since at least 1977 so I don't think
it is a good idea for GCC in general anyways as evidence of Fortran.

-- Pinski

Well the question is whether the optimization buys anything
in practice for other than the loop bound case, I am guessing
it does not, and if that is the case there is an argument
for uniformity.

I don't understand why Fortran would make integer overflows undefined,
other than in a do loop (equivalent to for). C has the primal sin of no
proper for loops. In C "for" is simply syntactic sugar of a "while" loop.
When in Fortran you write

   do i = 0, 10


   end do

the compiler can know that "i" is the loop variable. It would have been
possible to mandate that "i" can't be modified in the body of the loop.
On the other hand, C does not have a way to tell the compiler:

   "this is my loop variable, it must not be modified inside the loop"

neither you can say:

   "this is the upper bound of the loop, it must not be modified"


Any special treatment of "i" in

   for (i=0 ; i <= x ; ++i)

is problematic, because "i" might not be a real induction variable. Also
what about code like:

   for (i=0 ; i <= x ; ++i) {

       if (i<0) error();


Should the call to error() be eliminated?
What about code like:

   for (i=0 ; i <= x ; ++i) {

       if (foo) {

           i++; // HERE
           return i;



Should gcc assume that since "i" is a loop induction variable, then it is
not wrapping? Not even at the line marked with "HERE" ? Or is gcc
is going to assume that no wrapping can happen in the "for (...;...;...)"
section, but wrapping can happen in the body?

I think that the best compromise between performance and reliability
would be to define (forget me for not using the terms defined in the

   Signed integer overflows are unspecified. The implementations
   may choose to treat overflows as trapping, wrapping or

   in the context of "for (A;B;C) D " , "while(B) D" or
   "do D while (B)":
   It is unspecified if B is evaluated to *false* some time after the
   execution of C or D results in signed integer overflow of
   variables that B uses. this is regardless of the behavior of
   overflows in other contexts.

This wording allows reasonable treating of

   for (i=0 ; i<=x && i>= 0 ; ++i) {.....}

The compiler will not be allowed to eliminate the "i>=0" check since
i<=x   might return true when "i<=x && i>=0" would return false.

This wording also allows

   for (i=0 ; i<=x  ; ++i) {}

to be optimized to


since is ok to assume that i<=x  returns *false* for i=MAX_INT+1.

Michael Veksler

reply via email to

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