> The problem was that forall could handle substring expressions, > but not if it had to create a temporary array. I did my best > to fix this. I left a couple of TODO comments in the code.
Well, I don’t understand why the test needs a temporary for forall (i1 = nl1:nu1) o(i1:i1) = i(i1:i1) ! <<<< ICE If I am not mistaken this is equivalent to o(nl1:nu1) = i(nl1:nu1) for which gfortran does not generate any temporary while it does for forall (i1 = nl1:nu1) o(i1:i1) = o(nu1+1-i1:nu1+1-i1) where it is needed (looking at the dumps when compiling with -fdump-tree-original). Note that your patch generates a temporary which is not needed. At this point I have two questions: (1) why does gfortran want to create a temporary? (2) why does it fails? > Part of the issue is that forall doesn't usually create > a temporary, so that code doesn't get as much test coverage > as it probably should. In an ideal world, the compiler should create temporaries for assignment only when needed. AFAICR the coverage is rather good for usual assignments, I’ld be surprised if this were the case for FORALL. > I added an option (-fforce-forall-temp) > to force forall to use a temporary, and I set that option > in a couple of the test files. I am not really fond of this option. At best, it could only be a work around missing temporaries. What would be more helpful would be to report temporary creations when compiling with -Warray-temporaries or -fcheck=array-temps. Thanks for working on the issue. Dominique > I would not be surprised if there were a better way to do this. > > When I tweak gfc_trans_forall_1() to force usage of a temporary > for all assignments, all tests pass with the exception > of forall_8.f90, and the whole point of that test is making > sure that this particular forall *doesn't* use a temporary. > > Louis Krupp
