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; }
This breaks during ivopts.
It may be caused by revision 147716: http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00693.html
It is related to PR 41497.
> 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);
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.
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.
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.
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.
Ok, exactly the case I thought of (a conversion around the CHREC). I'll see to fix that up.
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?
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.
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
Fixed.
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
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.