[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42512

--- Comment #15 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

https://gcc.gnu.org/g:4c5b1160776382772fc0a33130dfaf621699fdbf

commit r13-3486-g4c5b1160776382772fc0a33130dfaf621699fdbf
Author: Richard Biener <rguenther@suse.de>
Date:   Mon Oct 24 08:52:12 2022 +0200

    tree-optimization/107176 - SCEV analysis association issue

    The following fixes a wrong-code issue caused by SCEV analysis
    associating an addition due trying to use tail-recursion in
    follow_ssa_edge_expr.  That causes us to apply a conversion at
    the wrong point and thus miscompute the scalar evolution of
    an induction variable.  This reverts the PR66375 fix and
    revisits the PR42512 fix by keeping the evolution symbolic
    up to the point we process the first linear function when
    we then can check for the supported cases and substitute the
    whole symbolic expression with the built chrec substituting
    the proper initial value.

    To simplify passing around things and to clarify scoping of
    the involved functions this change wraps the SCEV DFS walking
    code into a class.

            PR tree-optimization/107176
            PR tree-optimization/66375
            PR tree-optimization/42512
            * tree-scalar-evolution.cc (follow_ssa_edge_expr): Revert
            the PR66375 fix, do not not associate PLUS_EXPR to be able
            to use tail-recursion.
            (follow_ssa_edge_binary): Likewise.
            (interpret_loop_phi): Revert PR42512 fix, do not throw
            away analyze_evolution_in_loop result after the fact.
            (follow_ssa_edge_expr): When reaching halting_phi initalize
            the evolution to the symbolic value of the PHI result.
            (add_to_evolution_1): When adding the first evolution verify
            we can handle the expression wrapping the symbolic evolution
            and replace that in full using the initial condition.
            (class scev_dfs): New, contains ...
            (follow_ssa_edge_expr, follow_ssa_edge_binary,
            follow_ssa_edge_in_condition_phi_branch,
            follow_ssa_edge_in_condition_phi,
            follow_ssa_edge_inner_loop_phi,
            add_to_evolution, add_to_evolution_1): ... these with
            loop and halting_phi arguments in class data.
            (scev_dfs::get_ev): New toplevel DFS entry, start with
            a chrec_dont_know evolution.
            (analyze_evolution_in_loop): Use scev_dfs.

            * gcc.dg/torture/pr107176.c: New testcase.

[Bug c/42512] New: possible integer wrong code bug

[regehr at cs dot utah dot edu]

regehr@john-home:~$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/home/regehr/z/tmp/gcc-r155465-install/libexec/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/tmp/gcc-r155465-install --program-prefix=r155465-
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20091225 (experimental) (GCC) 
regehr@john-home:~$ current-gcc -O2 small.c -o small
regehr@john-home:~$ ./small
g_3 = -1
regehr@john-home:~$ current-gcc -O3 small.c -o small
regehr@john-home:~$ ./small
g_3 = 255
regehr@john-home:~$ cat small.c
#include <stdio.h>

int g_3;

int main (void)
{
    long long l_2;
    for (l_2 = -1; l_2 != 0; l_2 = (unsigned char)(l_2 - 1))
    {
        g_3 |= l_2;
    }
    printf("g_3 = %d\n", g_3);
    return 0;
}


-- 
           Summary: possible integer wrong code bug
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: regehr at cs dot utah dot edu
 GCC build triplet: i686-pc-linux-gnu
  GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[jakub at gcc dot gnu dot org]

------- Comment #1 from jakub at gcc dot gnu dot org  2009-12-26 20:00 -------
This breaks during ivopts.


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
           Priority|P3                          |P1
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-26 20:00:19
               date|                            |
            Summary|integer wrong code bug with |[4.5 Regression] integer
                   |loop                        |wrong code bug with loop
   Target Milestone|---                         |4.5.0


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2009-12-26 22:13 -------
It may be caused by revision 147716:

http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html


-- 

hjl dot tools at gmail dot com changed:

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


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2009-12-26 22:16 -------
It is related to PR 41497.


-- 

hjl dot tools at gmail dot com changed:

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


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[ebotcazou at gcc dot gnu dot org]

------- Comment #4 from ebotcazou at gcc dot gnu dot org  2009-12-27 14:43 -------
> It may be caused by revision 147716:
> 
> http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html

Same trigger as the other so the same partial reversion works:

Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c     (revision 155361)
+++ tree-scalar-evolution.c     (working copy)
@@ -1159,7 +1159,7 @@ follow_ssa_edge_expr (struct loop *loop,

   switch (code)
     {
-    CASE_CONVERT:
+    case NOP_EXPR:
       /* This assignment is under the form "a_1 = (cast) rhs.  */
       res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
                                  halting_phi, evolution_of_loop, limit);
@@ -1222,7 +1222,7 @@ follow_ssa_edge_in_rhs (struct loop *loo

   switch (code)
     {
-    CASE_CONVERT:
+    case NOP_EXPR:
       /* This assignment is under the form "a_1 = (cast) rhs.  */
       res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
                                  halting_phi, evolution_of_loop, limit);


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #5 from rguenth at gcc dot gnu dot org  2010-01-08 14:07 -------
I believe we can only either allow truncations or widenings in following
SSA edges.  Otherwise we miss that in

  int l_2; 
  for (l_2 = -1; l_2 != 0; l_2 = (unsigned char)(l_2 - 1))
    g_3 |= l_2;

the evolution is irregular in that the initial value is integer -1.  That is
what happens - we compute the evolution of the result of (unsigned char)(l_2
-1)
as { 255, +, 255 }_1 but we may not use this evolution to derive that of
the value assigned to l_2, (int) { 255, +, 255 }_1 because we cannot represent
this.  The correct evolution is -1, 254, 253 ..., 0 which isn't representable.

Thus I think we need to either kill the conversion code completely or
at least severely restrict it with sth like

Index: gcc/tree-scalar-evolution.c
===================================================================
--- gcc/tree-scalar-evolution.c (revision 155732)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -1161,9 +1161,19 @@ follow_ssa_edge_expr (struct loop *loop,
     {
     CASE_CONVERT:
       /* This assignment is under the form "a_1 = (cast) rhs.  */
-      res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
-                                 halting_phi, evolution_of_loop, limit);
-      *evolution_of_loop = chrec_convert (type, *evolution_of_loop, at_stmt);
+      rhs0 = TREE_OPERAND (expr, 0);
+      if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs0))
+         || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+       {
+         res = follow_ssa_edge_expr (loop, at_stmt, TREE_OPERAND (expr, 0),
+                                     halting_phi, evolution_of_loop, limit);
+         *evolution_of_loop = chrec_convert (type, *evolution_of_loop,
at_stmt);
+       }
+      else
+       {
+         *evolution_of_loop = chrec_dont_know;
+         res = t_false;
+       }
       break;

     case INTEGER_CST:
@@ -1219,14 +1229,25 @@ follow_ssa_edge_in_rhs (struct loop *loo
   enum tree_code code = gimple_assign_rhs_code (stmt);
   tree type = gimple_expr_type (stmt), rhs1, rhs2;
   t_bool res;
+  tree name;

   switch (code)
     {
     CASE_CONVERT:
       /* This assignment is under the form "a_1 = (cast) rhs.  */
-      res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
-                                 halting_phi, evolution_of_loop, limit);
-      *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+      name = gimple_assign_rhs1 (stmt);
+      if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (name))
+         || TREE_CODE (*evolution_of_loop) != POLYNOMIAL_CHREC)
+       {
+         res = follow_ssa_edge_expr (loop, stmt, gimple_assign_rhs1 (stmt),
+                                     halting_phi, evolution_of_loop, limit);
+         *evolution_of_loop = chrec_convert (type, *evolution_of_loop, stmt);
+       }
+      else
+       {
+         *evolution_of_loop = chrec_dont_know;
+         res = t_false;
+       }
       break;

     case POINTER_PLUS_EXPR:
@@ -1759,7 +1780,11 @@ interpret_rhs_expr (struct loop *loop, g

     CASE_CONVERT:
       chrec1 = analyze_scalar_evolution (loop, rhs1);
-      res = chrec_convert (type, chrec1, at_stmt);
+      if (TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (rhs1))
+         || TREE_CODE (chrec1) != POLYNOMIAL_CHREC)
+       res = chrec_convert (type, chrec1, at_stmt);
+      else
+       res = chrec_dont_know;
       break;

     default:


Sebastian - any better idea?  This will at least regress

FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(unsigned
char\)" 1
FAIL: gcc.dg/tree-ssa/scev-cast.c scan-tree-dump-times optimized "= \(char\)" 1


because we cannot distinguish the really critical cases from ok ones.
The patch in comment #4 just makes the issue latent again.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #6 from rguenth at gcc dot gnu dot org  2010-01-08 15:00 -------
Hm, actually what is wrong is the evolution of l_2_18:

  (scalar = l_2_18)
  (scalar_evolution = {255, +, 0x0ffffffff}_1))

that of l_2_10 is correct:

  (scalar = l_2_10)
  (scalar_evolution = (unsigned int) {254, +, 255}_1))

<bb 3>:
  # l_2_18 = PHI <l_2_10(4), 0x0ffffffff(2)>
  # prephitmp.10_25 = PHI <g_3.2_7(4), pretmp.9_24(2)>
  # ivtmp.19_37 = PHI <ivtmp.19_29(4), 255(2)>
  D.1960_3 = (short unsigned int) l_2_18;
  g_3.1_5 = (short unsigned int) prephitmp.10_25;
  D.1963_6 = D.1960_3 | g_3.1_5;
  g_3.2_7 = (short int) D.1963_6;
  g_3_lsm.18_11 = g_3.2_7;
  D.1965_8 = (unsigned char) l_2_18;
  D.1966_9 = D.1965_8 + 255;
  l_2_10 = (unsigned int) D.1966_9;
  ivtmp.19_29 = ivtmp.19_37 - 1;
  if (ivtmp.19_29 != 0)
    goto <bb 4>;
  else
    goto <bb 5>;

<bb 4>:
  goto <bb 3>;


Thus we need to verify we maintain the correct initial condition only?
Like for example with

Index: tree-scalar-evolution.c
===================================================================
--- tree-scalar-evolution.c     (revision 155732)
+++ tree-scalar-evolution.c     (working copy)
@@ -1642,6 +1642,15 @@ interpret_loop_phi (struct loop *loop, g
   init_cond = analyze_initial_condition (loop_phi_node);
   res = analyze_evolution_in_loop (loop_phi_node, init_cond);

+  /* Verify we maintained the correct initial condition throughout
+     possible conversions in the SSA chain.  */
+  if (res != chrec_dont_know)
+    {
+      tree new_init = initial_condition (res);
+      if (!operand_equal_p (init_cond, new_init, 0))
+       return chrec_dont_know;
+    }
+
   return res;
 }


Maybe too strict in case the returned chrec is wrapped in a conversion
operation itself (no idea if that ever happens - at least initial_condition
doesn't seem to deal with that during recursion either).

I'm going to test that patch.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2009-12-26 20:00:19         |2010-01-08 15:00:44
               date|                            |


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[spop at gcc dot gnu dot org]

------- Comment #7 from spop at gcc dot gnu dot org  2010-01-08 16:20 -------
Subject: Re:  [4.5 Regression] integer wrong code bug 
        with loop

I like the patch that you proposed in Comment #6.
Let's see if it passes bootstrap and test.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #8 from rguenth at gcc dot gnu dot org  2010-01-08 16:53 -------
It FAILs

FAIL: gcc.dg/vect/pr36630.c scan-tree-dump-times vect "vectorized 1 loops" 1

but otherwise passes testing.  I'll see what effect it has on SPEC 2006 and
investigate the above.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #9 from rguenth at gcc dot gnu dot org  2010-01-08 17:07 -------
Ok, exactly the case I thought of (a conversion around the CHREC).  I'll see to
fix that up.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-01-08 17:21 -------
Ok, I have that fixed locally at the place of the patch but I wonder if
initial_condition () shouldn't return for example

  1ul for (unsigned long) { 1, +, 1 }_1

and

  (int) i_2 for (int) { i_2, +, 1 }_1

and further (for short i_2)

  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1

?  Can the latter two happen all?  Is it even correct to talk about a
general initial condition in this case?  Consider

  { { 1, +, 1 }_2, +, 1 }_1

initial_condition will return 1 for the chrec even though that is not
correct because the initial condition is not constant in loop 1.
I suppose I'd only see that if instantiating the chrec at the point
where I placed the fix?  So I really only see at most a single outer
conversion around the chrec?


-- 


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

Re: [Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[Sebastian Pop]

> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
>  1ul for (unsigned long) { 1, +, 1 }_1
>

This is correct.

> and
>
>  (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
>  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ?  Can the latter two happen all?

Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.

> Is it even correct to talk about a
> general initial condition in this case?  Consider
>
>  { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.

If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:

loop_2
  i = loop_2_phi (0, i+1) = {1, +, 1}_2
  loop_1
    j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1

> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix?  So I really only see at most a single outer
> conversion around the chrec?

Yes, I think that at most you can have only one conversion around a chrec.

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[sebpop at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]



------- Comment #11 from sebpop at gmail dot com  2010-01-08 17:55 -------
Subject: Re:  [4.5 Regression] integer wrong code bug 
        with loop

> Ok, I have that fixed locally at the place of the patch but I wonder if
> initial_condition () shouldn't return for example
>
>  1ul for (unsigned long) { 1, +, 1 }_1
>

This is correct.

> and
>
>  (int) i_2 for (int) { i_2, +, 1 }_1
>
> and further (for short i_2)
>
>  i_2 for (short) { (int) { i_2, +, 1 }_2, +, 1 }_1
>
> ?  Can the latter two happen all?

Yes, these could happen, and you are right, we should see
the initial value of a chrec through the type conversion lenses.

> Is it even correct to talk about a
> general initial condition in this case?  Consider
>
>  { { 1, +, 1 }_2, +, 1 }_1
>
> initial_condition will return 1 for the chrec even though that is not
> correct because the initial condition is not constant in loop 1.

If you want, there is an initial condition for the loop_1 and that would be
{1, +, 1}_2, and there is an initial condition 1 for loop nest loop_2:

loop_2
  i = loop_2_phi (0, i+1) = {1, +, 1}_2
  loop_1
    j = loop_1_phi (i, j+1) = {{1, +, 1}_2, +, 1}_1

> I suppose I'd only see that if instantiating the chrec at the point
> where I placed the fix?  So I really only see at most a single outer
> conversion around the chrec?

Yes, I think that at most you can have only one conversion around a chrec.


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2010-01-09 12:04 -------
Fixed.


-- 

rguenth at gcc dot gnu dot org changed:

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


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[rguenth at gcc dot gnu dot org]

------- Comment #12 from rguenth at gcc dot gnu dot org  2010-01-09 12:04 -------
Subject: Bug 42512

Author: rguenth
Date: Sat Jan  9 12:04:17 2010
New Revision: 155757

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155757
Log:
2010-01-09  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42512
        * tree-scalar-evolution.c (interpret_loop_phi): Make sure
        the evolution is compatible with the initial condition.

        * gcc.c-torture/execute/pr42512.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-scalar-evolution.c


-- 


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

[Bug middle-end/42512] [4.5 Regression] integer wrong code bug with loop

[hjl at gcc dot gnu dot org]

------- Comment #14 from hjl at gcc dot gnu dot org  2010-02-07 04:45 -------
Subject: Bug 42512

Author: hjl
Date: Sun Feb  7 04:41:22 2010
New Revision: 156562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156562
Log:
Backport testcases from mainline to 4.4.

2010-02-06  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2010-02-05  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42915
        * g++.dg/other/crash-9.C: New test.

        2010-02-03  Jason Merrill  <jason@redhat.com>

        PR c++/40138
        * g++.dg/ext/builtin11.C: New.

        2010-02-03  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42944
        * gcc.dg/errno-1.c: New testcase.

        2010-02-03  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42927
        * gcc.c-torture/compile/pr42927.c: New testcase.

        2010-01-29  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42758
        PR c++/42634
        PR c++/42336
        PR c++/42797
        PR c++/42880
        * g++.dg/other/crash-5.C: New test.
        * g++.dg/other/crash-7.C: New test.
        * g++.dg/other/crash-8.C: New test.

        2010-01-28  Uros Bizjak  <ubizjak@gmail.com>

        PR target/42891
        * gcc.target/i386/pr42891.c: New test.

        2010-01-28  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42883
        * g++.dg/torture/pr42883.C: New testcase.

        2010-01-28  Michael Matz  <matz@suse.de>

        * gcc.target/i386/pr42881.c: New test.

        2010-01-28  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42713
        PR c++/42820
        * g++.dg/template/typedef27.C: New test case.
        * g++.dg/template/typedef28.C: New test case.

        2010-01-27  Jakub Jelinek  <jakub@redhat.com>

        PR middle-end/42874
        * gcc.dg/vla-22.c: New test.

        2010-01-26  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42250
        * gcc.dg/pr42250.c: New testcase.

        2010-01-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/42858
        * gfortran.dg/generic_21.f90: New test.

        2010-01-21  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42585
        * gcc.dg/tree-ssa/pr42585.c: New test.

        2010-01-20  Alexandre Oliva  <aoliva@redhat.com>

        PR debug/42715
        * gcc.dg/pr42715.c: New.

        2010-01-20  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42717
        * gcc.c-torture/compile/pr42717.c: New testcase.

        2010-01-19  Paul Thomas  <pault@gcc.gnu.org>

        PR fortran/42783
        * gfortran.dg/bounds_check_15.f90 : New test.

        2010-01-18  Dodji Seketeli  <dodji@redhat.com>

        PR c++/42766
        * g++.dg/conversion/op6.C: New test.

        2010-01-18  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42781
        * gfortran.fortran-torture/compile/pr42781.f90: New testcase.

        2010-01-17  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42248
        * gcc.c-torture/execute/pr42248.c: New testcase.

        2010-01-17  Janus Weil  <janus@gcc.gnu.org>

        PR fortran/42677
        * gfortran.dg/interface_assignment_5.f90: New test.

        2010-01-15  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42739
        * g++.dg/torture/pr42739.C: New testcase.

        2010-01-14 Jerry DeLisle <jvdelisle@gcc.gnu.org>

        PR fortran/42684
        * gfortran.dg/interface_31.f90: New test.

        2010-01-14  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42706
        * gcc.dg/ipa/pr42706.c: New testcase.

        2010-01-14  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42714
        * g++.dg/torture/pr42714.C: New test.

        2010-01-14  Alexander Monakov  <amonakov@ispras.ru>

        PR rtl-optimization/42388
        * gcc.dg/pr42388.c: New.

        2010-01-14  Alexander Monakov <amonakov@ispras.ru>

        PR rtl-optimization/42294
        * gfortran.dg/pr42294.f: New.

        2010-01-14  Ira Rosen  <irar@il.ibm.com>

        PR tree-optimization/42709
        * gcc.dg/vect/pr42709.c: New test.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42730
        * gcc.c-torture/compile/pr42730.c: New testcase.

        2010-01-13  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42704
        * g++.dg/torture/pr42704.C: New test.

        2010-01-13  Martin Jambor  <mjambor@suse.cz>

        PR tree-optimization/42703
        * gcc.c-torture/compile/pr42703.c: New test.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR tree-optimization/42705
        * gcc.c-torture/compile/pr42705.c: New testcase.

        2010-01-13  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42716
        * gcc.c-torture/compile/pr42716.c: New testcase.

        2010-01-12  Joseph Myers  <joseph@codesourcery.com>

        PR c/42708
        * gcc.c-torture/compile/pr42708-1.c: New test.

        2010-01-09  Alexandre Oliva  <aoliva@redhat.com>

        PR middle-end/42363
        * gcc.dg/torture/pr42363.c: New.

        2010-01-09  Alexandre Oliva  <aoliva@redhat.com>

        PR debug/42604
        PR debug/42395
        * gcc.dg/vect/pr42604.c: New.
        * gcc.dg/vect/pr42395.c: New.

        2010-01-09  Richard Guenther  <rguenther@suse.de>

        PR middle-end/42512
        * gcc.c-torture/execute/pr42512.c: New testcase.

Added:
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/conversion/op6.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/conversion/op6.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/ext/builtin11.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/ext/builtin11.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-5.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-5.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-7.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-7.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-8.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-8.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/other/crash-9.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/other/crash-9.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef27.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef27.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/typedef28.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/template/typedef28.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42704.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42704.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42714.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42714.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42739.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42739.C
    branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr42883.C
      - copied unchanged from r156561,
trunk/gcc/testsuite/g++.dg/torture/pr42883.C
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42703.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42703.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42705.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42705.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42708-1.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42716.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42716.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42717.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42717.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42730.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42730.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/compile/pr42927.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/compile/pr42927.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42248.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42248.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr42512.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.c-torture/execute/pr42512.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/errno-1.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/errno-1.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/ipa/pr42706.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/ipa/pr42706.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42250.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42250.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42388.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42388.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr42715.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/pr42715.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr42363.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/torture/pr42363.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr42585.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42395.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42395.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42604.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42604.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vect/pr42709.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.dg/vect/pr42709.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/vla-22.c
      - copied unchanged from r156561, trunk/gcc/testsuite/gcc.dg/vla-22.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42881.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42881.c
    branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr42891.c
      - copied unchanged from r156561,
trunk/gcc/testsuite/gcc.target/i386/pr42891.c
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/bounds_check_15.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/generic_21.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/generic_21.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_31.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_31.f90
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/interface_assignment_5.f90
    branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/pr42294.f
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.dg/pr42294.f
   
branches/gcc-4_4-branch/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
      - copied unchanged from r156561,
trunk/gcc/testsuite/gfortran.fortran-torture/compile/pr42781.f90
Modified:
    branches/gcc-4_4-branch/gcc/testsuite/ChangeLog


-- 


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