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: Ian Lance Taylor
Subject: Re: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
Date: 31 Dec 2006 18:48:10 -0800
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4

Paul Eggert <address@hidden> writes:

> Robert Dewar <address@hidden> writes:
> 
> > We have not seen ONE imaginary example, let
> > alone a real example, where the optimziation of loop invariants
> > (by far the most important optimization in the class we are
> > discussing) would break existing code.
> 
> But didn't this thread get started by a real program that was broken
> by an optimization of loop invariants?  Certainly I got a real bug
> report of a real problem, which you can see here:
> 
> http://lists.gnu.org/archive/html/bug-gnulib/2006-12/msg00084.html
> 
> Here is a bit more discussion:
> 
> http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html
> 
> If this doesn't count as "optimization of loop invariants"
> then what would count?

No.  As I already explained in some detail, that was an example of a
VRP (Value Range Propagation) optimization.  VRP is not a loop based
optimization.  This is not an example of the kinds of loop
optimizations gcc makes by assuming that signed overflow is undefined.
The loop optimizer is not going to turn an apparently bounded loop
into an infinite loop by relying on signed overflow, because that is a
pointless optimization.

For example, when not using -fwrapv, the loop optimizer can assume
that this loop (on signed i):
    for (i = 0; i <= n; i++)
will execute the same number of times as this loop:
    for (i = 0; i < n + 1; i++)
and in particular that both loops will terminate.  With -fwrapv the
first loop will not terminate if n == INT_MAX.

Ian




reply via email to

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