This fixes PR56426. We were ICEing during the loop pipeline,
because copyprop changed an irreducible region into a reducible - thus
the number_of_loops grew. Firstly, in tree_ssa_loop_init, number_of_loops
was == 1, which means we didn't initialize SCEV. But then later on, in
tree_ssa_loop_bounds, the number_of_loops was 2, thus we called
estimate_numbers_of_iterations. Oops. So fixed by always initializing
SCEV in the loop initialization on the tree level.
Another approach would be to skip the whole loop pipeline - but then
we'd miss e.g. the BB vectorization.
Richi: no, I didn't forget to change the TODO_update_ssa to 0, but that
ICEd pretty soon when building gcc :(.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-02-25 Marek Polacek <pola...@redhat.com>
PR tree-optimization/56426
* tree-ssa-loop.c (tree_ssa_loop_init): Always call
scev_initialize.
* gcc.dg/pr56436.c: New test.
--- gcc/tree-ssa-loop.c.mp 2013-02-25 13:06:47.212132327 +0100
+++ gcc/tree-ssa-loop.c 2013-02-25 20:09:30.668978936 +0100
@@ -70,10 +70,13 @@ tree_ssa_loop_init (void)
| LOOPS_HAVE_RECORDED_EXITS);
rewrite_into_loop_closed_ssa (NULL, TODO_update_ssa);
+ /* We might discover new loops, e.g. when turning irreducible
+ regions into reducible. */
+ scev_initialize ();
+
if (number_of_loops () <= 1)
return 0;
- scev_initialize ();
return 0;
}
--- gcc/testsuite/gcc.dg/pr56436.c.mp 2013-02-25 20:19:10.213561026 +0100
+++ gcc/testsuite/gcc.dg/pr56436.c 2013-02-25 20:19:02.944541180 +0100
@@ -0,0 +1,22 @@
+/* PR tree-optimization/56426 */
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+int a, *c;
+
+void
+f (void)
+{
+ int b = 0;
+
+ for (a = 0;; a++)
+ if (--b)
+ {
+ if (a)
+ lbl:
+ a++;
+
+ c = &b;
+ goto lbl;
+ }
+}
Marek
