Hello world, front-end optimization and FORALL do not appear to mix well.
This patch fixes an ICE resulting from an attempt by front-end optimization to use a BLOCK inside a FORALL statement. I will commit this as obvious in a day or so unless somebody objects. I will also backport (time to install the gcc 5 branch...) There would be an alternative, in principle, to put the BLOCK around the FORALL, but frankly, I don't think it is worth spending the effort and complicating the code. Regards Thomas 2015-06-11 Thomas Koenig <tkoe...@gcc.gnu.org> PR fortran/66385 * frontend-passes.c (combine_array_constructor): Return early if inside a FORALL loop. 2015-06-11 Thomas Koenig <tkoe...@gcc.gnu.org> PR fortran/66385 * gfortran.dg/forall_17.f90: New test.
! { dg-do compile } ! { dg-options "-ffrontend-optimize" } ! PR fortran/66385 - this used to ICE ! Original test case by Mianzhi Wang program test double precision::aa(30) double precision::a(3,3),b b=1d0 forall(i=1:3) a(:,i)=b*[1d0,2d0,3d0] end forall forall(i=1:10) aa(10*[0,1,2]+i)=1d0 end forall end program
Index: frontend-passes.c =================================================================== --- frontend-passes.c (Revision 223876) +++ frontend-passes.c (Arbeitskopie) @@ -1243,6 +1243,10 @@ combine_array_constructor (gfc_expr *e) if (in_assoc_list) return false; + /* With FORALL, the BLOCKS created by create_var will cause an ICE. */ + if (forall_level > 0) + return false; + op1 = e->value.op.op1; op2 = e->value.op.op2;