This started failing very recently on trunk : > gfortran -c -O2 -funroll-loops bug.f90 bug.f90: In function ‘calc_s_derivs’: bug.f90:1:0: internal compiler error: in check_loop_closed_ssa_use, at tree-ssa-loop-manip.c:557 SUBROUTINE calc_S_derivs() ^ 0xa0cf93 check_loop_closed_ssa_use ../../gcc/gcc/tree-ssa-loop-manip.c:557 0xa0d591 check_loop_closed_ssa_stmt ../../gcc/gcc/tree-ssa-loop-manip.c:572 0xa0d591 verify_loop_closed_ssa(bool) ../../gcc/gcc/tree-ssa-loop-manip.c:606 0xa0d880 gimple_duplicate_loop_to_header_edge(loop*, edge_def*, unsigned int, simple_bitmap_def*, edge_def*, vec_t<edge_def*>**, int) ../../gcc/gcc/tree-ssa-loop-manip.c:762 0xdbd99a try_unroll_loop_completely ../../gcc/gcc/tree-ssa-loop-ivcanon.c:519 0xdbd99a canonicalize_loop_induction_variables ../../gcc/gcc/tree-ssa-loop-ivcanon.c:666 0xdbea10 tree_unroll_loops_completely(bool, bool) ../../gcc/gcc/tree-ssa-loop-ivcanon.c:815 > cat bug.f90 SUBROUTINE calc_S_derivs() INTEGER, DIMENSION(6, 2) :: c_map_mat INTEGER, DIMENSION(:), POINTER:: C_mat DO j=1,3 DO m=j,3 n=n+1 c_map_mat(n,1)=j IF(m==j)CYCLE c_map_mat(n,2)=m END DO END DO DO m=1,6 DO j=1,2 IF(c_map_mat(m,j)==0)CYCLE CALL foo(C_mat(c_map_mat(m,j))) END DO END DO END SUBROUTINE calc_S_derivs
Confirmed, r92440 is OK.
I assume it is: r190978 | rguenth | 2012-09-05 15:29:13 +0200 (Wed, 05 Sep 2012) | 11 lines 2012-09-05 Richard Guenther <rguenther@suse.de>
> I assume it is: > > r190978 | rguenth | 2012-09-05 15:29:13 +0200 (Wed, 05 Sep 2012) | 11 lines > > 2012-09-05 Richard Guenther <rguenther@suse.de> I don't think so: r192440 is OK (copy and paste error in comment #1). Actually r192449 is also OK. Indeed this does rule out that a post r192449 revision has only uncovered a latent bug caused by an earlier revision.
The ICE appears at revision 192538 and requires gcc to be configured with --enable-checking=yes (default). I don't see it for gcc configured with --enable-checking=release.
Honza, that's yours.
Looking into it. Obviously complette unroling ought not affect loop closedness :) Honza
OK, the problem is that unloop is shuffling a basic block out of the outer loop: DO m=1,6 after unrolling the inner loop: DO j=1,2 12 times. So here are several problems 1) I need to work out what to do when unloop moves basic blocks out of the loop and why it happens in this case 2) array bound is based on array access n_29 = n_5 + 1; _45 = (integer(kind=8)) n_29; _58 = _45 + -1; c_map_mat[_58] = m_1; and it is 12 instead of 2 because we lose track of the fact that the array is 2 dimensional with known bounds. Somehow we should keep track of this. 3) tree-ssa-loop-niter ought to take into account known bounds on IV variables of the outer loop when computing the inner loop. Honza
The test libgomp.graphite/force-parallel-6.c fails to execute with a bus error on x86_64-apple-darwin10 at revision 192538. Is it related to this PR or should I open a new one?
Author: hubicka Date: Tue Oct 23 09:57:36 2012 New Revision: 192709 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192709 Log: PR middle-end/54967 * cfgloopmanip.c (fix_bb_placements): Add loop_closed_ssa_invalidated; track basic blocks that moved out of their loops. (unloop): Likewise. (remove_path): Update. (fix_loop_placements): Update. * tree-ssa-loop-ivcanon.c (try_unroll_loop_completely): Add loop_closed_ssa_invalidated parameter; pass it around. (canonicalize_loop_induction_variables): Update loop closed SSA form if needed. (tree_unroll_loops_completely): Likewise; do irred update out of the outer loop; verify that SSA form is closed. * cfgloop.h (unrloop): Update. * gfortran.dg/pr54967.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr54967.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/cfgloop.h trunk/gcc/cfgloopmanip.c trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-loop-ivcanon.c
Fixed.
The test gfortran.dg/pr54967.f90 fails because SUBROUTINE calc_S_derivs() is duplicated.