[EMAIL PROTECTED] (Richard Kenner) writes: > > 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 > > I just thought of something interesting about this case. We have a loop > looking like: > > for (j = 1; 0 < j; j *= 2) > > in this case, the compiler is quite capable of arguing "this end condition > won't terminate the loop except in the case of overflow, so obviously the > programmer must be relying on wrapping semantics. So let's use those here"
Sure, but it's not the loop optimizer which is causing this code to fail. > > Here is a bit more discussion: > > > > http://gcc.gnu.org/ml/gcc/2006-12/msg00607.html > > Indeed that message hinted at exactly that point. Note that if you do > argue along those lines, you can convert this to a loop with a new IV > that increments up to 31 (or is it 32?). That is in fact precisely what happens if you compile with -fno-tree-vrp. Ian
