[Bug tree-optimization/26304] [4.2 Regression] 25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and powerpc-darwin

[law at redhat dot com]

------- Comment #13 from law at redhat dot com  2006-02-17 02:47 -------
Subject: Re:  [4.2 Regression]
        25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin

On Fri, 2006-02-17 at 01:17 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #12 from pinskia at gcc dot gnu dot org  2006-02-17 01:17 -------
> (In reply to comment #11)
> > I've just checked in a patch which may (or may not) fix this problem;
> > can you update your stor-layout.c and see if that change happens to
> > fix this problem.
> 
> Nope, sorry it does not fix the problem:
> -  if (ivtmp.60_19 != 4294967295) goto <L5>; else goto <L13>;
> -
> -<L13>:;
> -  return;
> +  goto <bb 7> (<L22>);
> 
> 
> +ivtmp.60_19: [0, 4]  EQUIVALENCES: { } (0 elements)
> 
> the C testcase (changing cassert to assert.h) fails the same way.
I'm pretty sure this is an SCEV problem.

scev_probably_wraps_p is returning false even though the loop
iteration variable clearly wraps.  The iteration variable will
have the values 4, 3, 2, 1, 0, 0xffffffff, then the loop terminates.

This in turn causes us to use the SCEV information to refine a
range improperly.

Someone who knows/understands the SCEV code should be assigned this
bug.

jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26304