This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
- From: "rakdver at kam dot mff dot cuni dot cz" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 15 May 2009 15:44:49 -0000
- Subject: [Bug tree-optimization/40087] [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
- References: <bug-40087-17694@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #8 from rakdver at kam dot mff dot cuni dot cz 2009-05-15 15:44 -------
Subject: Re: [4.3/4.4/4.5 Regression] Number of iterations analysis wrong
> > > It is number of iteration analysis that gets it wrong (I suppose it might get
> > > confused by the two exits of the loop?).
> >
> > Sort of; # of iterations analysis assumes that pointers never wrap, and uses
> > this assumption to derive a wrong number of iterations for the first exit
> > (which is not taken). We had a similar problem before (PR 25985), but I
> > somehow persuaded myself that this cannot happen with pointers.
>
> Ah - it indeed cannot happen, but you need to assume that the offsets
> in POINTER_PLUS_EXPRs are signed (even though they are unsigned as
> they are of type sizetype).
that is not the problem. The problem is that # of iterations analysis
has a look at the first test, of form [x,+,4] == [x + 28, +, -4],
observes that the variables do not wrap, and concludes that the loop
is not infinite. So far OK, but next we infer that this means that
the exit is taken, i.e., that 28 % 8 = 0, and the things go down for
there. I fixed this error before, but special-cased the pointer ivs
in a strike of wishful thinking.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40087