This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
[PATCH] Fix ICE in lambda-code (regression from 4.1.1, PR tree-optimization/29290)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: Sebastian Pop <sebastian dot pop at cri dot ensmp dot fr>, Daniel Berlin <dberlin at dberlin dot org>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 5 Oct 2006 06:17:27 -0400
- Subject: [PATCH] Fix ICE in lambda-code (regression from 4.1.1, PR tree-optimization/29290)
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
Hi!
linear_transform_loops checks that none of the inner loops have multiple
exits, but doesn't check whether loop_nest itself has multiple exits.
Before the mid August change
http://gcc.gnu.org/viewcvs?view=rev&revision=116223
there was no ICE, all that happened when loop_nest->single_exit == NULL
is that gcc_loopnest_to_lambda_loopnest called gcc_loop_to_lambda_loop
and that immediately failed:
/* Find out induction var and exit condition. */
inductionvar = find_induction_var_from_exit_cond (loop);
exit_cond = get_loop_exit_condition (loop);
if (inductionvar == NULL || exit_cond == NULL)
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file,
"Unable to convert loop: Cannot determine exit condition or induction variable for loop.\n");
return NULL;
}
because a loop with multiple exits has exit_cond == NULL.
gcc_loop_to_lambda_loop failure leeds to gcc_loopnest_to_lambda_loopnest
faiure and so linear_transform_loops did nothing for this loop.
But after the 116223 checkin, gcc_loopnest_to_lambda_loopnest
first calls:
bool perfect_nest = perfect_nest_p (loop_nest);
if (!perfect_nest && !can_convert_to_perfect_nest (loop_nest))
goto fail;
and can_convert_to_perfect_nest relies on loop_nest->single_exit != NULL,
so we ICE in there. As from the above I'm very sure we wouldn't do
anything meaningful with multiple exit loops anyway, I think it is better
to jump ship early then robustify various places in lambda-code.c.
The exact testcase doesn't ICE on the trunk, apparently because earlier
optimizations resulted in different loop set at the start of
-ftree-loop-linear pass, but I don't see what would prevent such an ICE
if ever a multiple exit loop is passed to it and gets through the
tree-loop-linear.c conditions up to gcc_loopnest_to_lambda_loopnest.
Ok for trunk/4.1?
2006-10-05 Jakub Jelinek <jakub@redhat.com>
PR tree-optimization/23625
* tree-loop-linear.c (linear_transform_loops): Bail if loop_nest has
multiple exits.
* gfortran.dg/pr29290.f90: New test.
--- gcc/tree-loop-linear.c.jj 2006-10-05 11:51:35.000000000 +0200
+++ gcc/tree-loop-linear.c 2006-10-05 11:53:34.000000000 +0200
@@ -267,12 +267,12 @@ linear_transform_loops (struct loops *lo
{
...
}
- for (j = 0; j < 50; j++)
+ for (j = 0; j < 50; j++)
{
...
}
} */
- if (!loop_nest || !loop_nest->inner)
+ if (!loop_nest || !loop_nest->inner || !loop_nest->single_exit)
continue;
VEC_truncate (tree, oldivs, 0);
VEC_truncate (tree, invariants, 0);
--- gcc/testsuite/gfortran.dg/pr29290.f90.jj 2006-10-05 11:56:01.000000000 +0200
+++ gcc/testsuite/gfortran.dg/pr29290.f90 2006-10-05 11:59:01.000000000 +0200
@@ -0,0 +1,9 @@
+! PR tree-optimization/23625
+! { dg-do compile }
+! { dg-options "-O3 -ftree-loop-linear" }
+
+subroutine pr23625 (a, b, c, d)
+ integer c, d
+ real*8 a(c,c), b(c,c)
+ a(1:d,1:d) = b(1:d,1:d)
+end
Jakub