[Bug target/26304] New: 25_algorithms/prev_permutation/1.cc on powerpc64-linux

[Bug target/26304] New: 25_algorithms/prev_permutation/1.cc on powerpc64-linux

[pcarlini at suse dot de]

Between 20060207 and 20060209 the testcase started failing like this:

1.exe:
/usr/src/pcarlini/gcc-head/gcc/libstdc++-v3/testsuite/25_algorithms/prev_permutation/1.cc:75:
void test4(): Assertion `array[i] == 5 - i' failed.
FAIL: 25_algorithms/prev_permutation/1.cc execution test

Seems a miscompilation: the problem goes away at -O1. By the way, the failing
test4 is pretty easy to make self contained, I'm attaching it for convenience.


-- 
           Summary: 25_algorithms/prev_permutation/1.cc on powerpc64-linux
           Product: gcc
           Version: 4.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: pcarlini at suse dot de


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

[Bug target/26304] 25_algorithms/prev_permutation/1.cc on powerpc64-linux

[pcarlini at suse dot de]

------- Comment #1 from pcarlini at suse dot de  2006-02-15 14:02 -------
Created an attachment (id=10855)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10855&action=view)
Reduced failing test


-- 


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

[Bug target/26304] 25_algorithms/prev_permutation/1.cc on powerpc64-linux

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-02-15 14:07 -------
This also shows up on powerpc-darwin since at least 20060208.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.2 Regression]            |25_algorithms/prev_permutati
                   |25_algorithms/prev_permutati|on/1.cc on powerpc64-linux
                   |on/1.cc on powerpc64-linux  |


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

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 GCC target triplet|                            |powerpc{64,}-linux-gnu,
                   |                            |powerpc-darwin
            Summary|25_algorithms/prev_permutati|[4.2 Regression]
                   |on/1.cc on powerpc64-linux  |25_algorithms/prev_permutati
                   |                            |on/1.cc on powerpc{64,}-
                   |                            |linux and powerpc-darwin
   Target Milestone|---                         |4.2.0


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-15 15:18 -------
-O2 -fno-tree-vrp cures the wrong code which either means VRP is messing up or
some other pass is messing up after VRP.  Though I should note:
-  ivtmp.209 = ivtmp.209 - 1;
+  ivtmp.211 = ivtmp.211 - 1;
   ivtmp.214 = ivtmp.214 + 4B;
-  goto <bb 11> (<L22>);
+  if (ivtmp.211 != 4294967295) goto <L9>; else goto <L13>;

Which looks more like VRP messing up.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |law at gcc dot gnu dot org
          Component|target                      |tree-optimization


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-02-15 15:19 -------
Also -O2 -fno-ivopts cures the problem too.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-02-15 15:23 -------
Folding predicate ivtmp.209_41 != 4294967295 to 1
Folded statement: if (ivtmp.209_41 != 4294967295) goto <L24>; else goto <L13>;
            into: if (1) goto <L24>; else goto <L13>;


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-02-15 15:26 -------
The part which is being miscompiled is:
  for(int i = 0; i < 6; ++i)
    assert(array[i] == 5 - i);

which is funny.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-15 15:37 -------
Here is a self contained program without using libstdc++:
int array[10] = {5, 4, 3, 2, 1, 0};
int array1[10] = {5, 4, 3, 2, 1, 0};
int array2[10] = {5, 4, 3, 2, 1, 0};
#include <cassert>

void g(int *a)
{
  *a = 0;
}

void
test4()
{
  g(array+6);
  for(int i = 0; i < 6; ++i)
    assert(array[i] == 5 - i);
  for(int i = 0; i < 6; ++i)
    {
    assert(array[i] == 5 - i);
    assert(array1[i] == 5 - i);
    assert(array2[i] == 5 - i);
    }
}

int main()
{
  test4();
}


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2006-02-15 15:37:33
               date|                            |


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

[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 #8 from law at redhat dot com  2006-02-15 23:34 -------
Subject: Re:  [4.2 Regression]
        25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin

On Wed, 2006-02-15 at 15:19 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #3 from pinskia at gcc dot gnu dot org  2006-02-15 15:18 -------
> -O2 -fno-tree-vrp cures the wrong code which either means VRP is messing up or
> some other pass is messing up after VRP.  Though I should note:
> -  ivtmp.209 = ivtmp.209 - 1;
> +  ivtmp.211 = ivtmp.211 - 1;
>    ivtmp.214 = ivtmp.214 + 4B;
> -  goto <bb 11> (<L22>);
> +  if (ivtmp.211 != 4294967295) goto <L9>; else goto <L13>;
> 
> Which looks more like VRP messing up.
Can you check something for me.  Is sizetype an unsigned type on 
this platform?  And what type is ivtmp?




jeff


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #9 from pinskia at gcc dot gnu dot org  2006-02-16 02:59 -------
(In reply to comment #8)
> > Which looks more like VRP messing up.
> Can you check something for me.  Is sizetype an unsigned type on 
> this platform?  And what type is ivtmp?
sizetype should be "unsigned long int" but I am not 100% sure.

  unsigned int ivtmp.60;


-- 


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

[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 #10 from law at redhat dot com  2006-02-16 03:52 -------
Subject: Re:  [4.2 Regression]
        25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin

On Thu, 2006-02-16 at 02:59 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #9 from pinskia at gcc dot gnu dot org  2006-02-16 02:59 -------
> (In reply to comment #8)
> > > Which looks more like VRP messing up.
> > Can you check something for me.  Is sizetype an unsigned type on 
> > this platform?  And what type is ivtmp?
> sizetype should be "unsigned long int" but I am not 100% sure.
> 
>   unsigned int ivtmp.60;
Thanks.  There's a reasonable possibility this is the same bug
I'm already working in.  It's a latent problem in how we set up
TYPE_MAX_VALUE on targets which have an unsigned sizetype.

jeff


-- 


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

[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 #11 from law at redhat dot com  2006-02-17 00:19 -------
Subject: Re:  [4.2 Regression]
        25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin

On Wed, 2006-02-15 at 15:37 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #7 from pinskia at gcc dot gnu dot org  2006-02-15 15:37 -------
> Here is a self contained program without using libstdc++:
> int array[10] = {5, 4, 3, 2, 1, 0};
> int array1[10] = {5, 4, 3, 2, 1, 0};
> int array2[10] = {5, 4, 3, 2, 1, 0};
> #include <cassert>
> 
> void g(int *a)
> {
>   *a = 0;
> }
> 
> void
> test4()
> {
>   g(array+6);
>   for(int i = 0; i < 6; ++i)
>     assert(array[i] == 5 - i);
>   for(int i = 0; i < 6; ++i)
>     {
>     assert(array[i] == 5 - i);
>     assert(array1[i] == 5 - i);
>     assert(array2[i] == 5 - i);
>     }
> }
> 
> int main()
> {
>   test4();
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.

Thanks,
jeff


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- 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.


-- 


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

[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

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

[pinskia at gcc dot gnu dot org]

------- Comment #14 from pinskia at gcc dot gnu dot org  2006-02-17 03:37 -------
Hmm, I wonder if the following loop in scev_probably_wraps_p is wrong.

  estimate_numbers_of_iterations_loop (loop);
  for (bound = loop->bounds; bound; bound = bound->next)
    if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
      return false;

it says that if one bounds does not wrap, then all variables asked about don't
which is not true.


-- 


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

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

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker


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

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

[pcarlini at suse dot de]

------- Comment #15 from pcarlini at suse dot de  2006-03-28 20:20 -------
*** Bug 26911 has been marked as a duplicate of this bug. ***


-- 

pcarlini at suse dot de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu dot org


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

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

[janis at gcc dot gnu dot org]

------- Comment #16 from janis at gcc dot gnu dot org  2006-04-18 16:23 -------
I verified that the failure starts with Jeff's patch:

r110705 | law | 2006-02-07 10:31:27 -0800 (Tue, 07 Feb 2006)

http://gcc.gnu.org/viewcvs?view=rev&rev=110705


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #17 from pinskia at gcc dot gnu dot org  2006-04-23 23:14 -------
Rewritting that loop like:
[kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c
Index: tree-ssa-loop-niter.c
===================================================================
--- tree-ssa-loop-niter.c       (revision 113199)
+++ tree-ssa-loop-niter.c       (working copy)
@@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b
   tree unsigned_type, valid_niter;
   tree base_plus_step, bpsps;
   int cps, cpsps;
+  bool known_not_to_wrap;

   /* FIXME: The following code will not be used anymore once
      http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is
@@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b

   estimate_numbers_of_iterations_loop (loop);
   for (bound = loop->bounds; bound; bound = bound->next)
-    if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
-      return false;
+    if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
+      known_not_to_wrap = false;
+  if (known_not_to_wrap)
+   return false;

   /* At this point we still don't have a proof that the iv does not
      overflow: give up.  */



----------------------------

Makes it work,  Now I am not going to say this is the "correct" fix or not.  
What I am going to say, this is the most logical fix in that we know one iv can
not overflow does not mean all will not.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |spop at gcc dot gnu dot org


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #18 from pinskia at gcc dot gnu dot org  2006-04-23 23:15 -------
Oh, I did not test the patch at all except on the testcase I gave in comment
#7.


-- 


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

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

[Daniel Berlin]

On Sun, 2006-04-23 at 23:14 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #17 from pinskia at gcc dot gnu dot org  2006-04-23 23:14 -------
> Rewritting that loop like:
> [kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c
> Index: tree-ssa-loop-niter.c
> ===================================================================
> --- tree-ssa-loop-niter.c       (revision 113199)
> +++ tree-ssa-loop-niter.c       (working copy)
> @@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b
>    tree unsigned_type, valid_niter;
>    tree base_plus_step, bpsps;
>    int cps, cpsps;
> +  bool known_not_to_wrap;
> 
>    /* FIXME: The following code will not be used anymore once
>       http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is
> @@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b
> 
>    estimate_numbers_of_iterations_loop (loop);
>    for (bound = loop->bounds; bound; bound = bound->next)
> -    if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> -      return false;
> +    if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> +      known_not_to_wrap = false;
> +  if (known_not_to_wrap)
> +   return false;
> 
>    /* At this point we still don't have a proof that the iv does not
>       overflow: give up.  */
> 

known_to_wrap may be uninitialized at the if statement here.
You need to init it to true.

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

[dberlin at dberlin dot org]

------- Comment #19 from dberlin at gcc dot gnu dot org  2006-04-24 01:10 -------
Subject: Re:  [4.2 Regression]
        25_algorithms/prev_permutation/1.cc on powerpc{64,}-linux and
powerpc-darwin

On Sun, 2006-04-23 at 23:14 +0000, pinskia at gcc dot gnu dot org wrote:
> 
> ------- Comment #17 from pinskia at gcc dot gnu dot org  2006-04-23 23:14 -------
> Rewritting that loop like:
> [kudzu:local/trunk/gcc] pinskia% svn diff tree-ssa-loop-niter.c
> Index: tree-ssa-loop-niter.c
> ===================================================================
> --- tree-ssa-loop-niter.c       (revision 113199)
> +++ tree-ssa-loop-niter.c       (working copy)
> @@ -1939,6 +1939,7 @@ scev_probably_wraps_p (tree type, tree b
>    tree unsigned_type, valid_niter;
>    tree base_plus_step, bpsps;
>    int cps, cpsps;
> +  bool known_not_to_wrap;
> 
>    /* FIXME: The following code will not be used anymore once
>       http://gcc.gnu.org/ml/gcc-patches/2005-06/msg02025.html is
> @@ -2077,8 +2078,10 @@ scev_probably_wraps_p (tree type, tree b
> 
>    estimate_numbers_of_iterations_loop (loop);
>    for (bound = loop->bounds; bound; bound = bound->next)
> -    if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> -      return false;
> +    if (!proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
> +      known_not_to_wrap = false;
> +  if (known_not_to_wrap)
> +   return false;
> 
>    /* At this point we still don't have a proof that the iv does not
>       overflow: give up.  */
> 

known_to_wrap may be uninitialized at the if statement here.
You need to init it to true.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #20 from pinskia at gcc dot gnu dot org  2006-05-02 05:55 -------
The code which I replaced here is changed.


-- 


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #21 from pinskia at gcc dot gnu dot org  2006-05-02 06:14 -------
This still fails even after the code change.

CCing the person who changed the code:
http://gcc.gnu.org/ml/gcc-cvs/2006-05/msg00024.html


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rakdver at gcc dot gnu dot
                   |                            |org


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

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

[rakdver at gcc dot gnu dot org]

------- Comment #22 from rakdver at gcc dot gnu dot org  2006-05-02 07:56 -------
(In reply to comment #14)
> Hmm, I wonder if the following loop in scev_probably_wraps_p is wrong.
> 
>   estimate_numbers_of_iterations_loop (loop);
>   for (bound = loop->bounds; bound; bound = bound->next)
>     if (proved_non_wrapping_p (at_stmt, bound, type, valid_niter))
>       return false;
> 
> it says that if one bounds does not wrap, then all variables asked about don't
> which is not true.

this piece of code seems OK to me (modulo that proved_non_wrapping_p was quite
missleading way to name that function).  What it does is that we know that the
loop is executed at most BOUND times, and that the variable will not wrap for
at least VALID_NITER iterations; therefore, if we are able to prove that
VALID_NITER > BOUND for any of the bounds, we know that the variable does not
wrap.  There is probaby off-by-one error in one of the functions.


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rakdver at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-04-11 23:17:57         |2006-05-02 07:56:20
               date|                            |


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

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

[rakdver at gcc dot gnu dot org]

------- Comment #23 from rakdver at gcc dot gnu dot org  2006-05-02 08:57 -------
Somehow, we record that the loop iterates at most once, which obviously leads
to problems.


-- 


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

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

[rakdver at gcc dot gnu dot org]

------- Comment #24 from rakdver at gcc dot gnu dot org  2006-05-08 11:18 -------
Patch: http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00290.html


-- 

rakdver at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                URL|                            |http://gcc.gnu.org/ml/gcc-
                   |                            |patches/2006-
                   |                            |05/msg00290.html
           Keywords|                            |patch


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

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

[pinskia at gcc dot gnu dot org]

------- Comment #25 from pinskia at gcc dot gnu dot org  2006-05-16 06:11 -------
This was fixed by the patch for PR 27603.

*** This bug has been marked as a duplicate of 27603 ***


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |DUPLICATE


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