Re: [FORTRAN PATCH] Another nested FORALL bug-fix

[Paul Thomas <paulthomas2 at wanadoo dot fr>]

Roger Sayle,
> Instead of the assignment to one and increment loops each being executed
> 100 (i.e. 10*10) times, we expand the second "increment" FORALL as a
> triply nested loop of i,j,k which then gets executed a 1000 times.  This
> then leads to the result that instead of tot being the expected 200,
> mainline gfortran actually produces the result 1100!
>   
Yes, that's about as bad as it gets.  Personnally, I would prefer 
gfortran to ICE that to quietly produce wrong results like that.
> Investigating in subversion, it turns out that like the previous FORALL
> mask bug, this also dates back to the addition of trans-stmt.c to
> mainline, and is therefore in the strictest sense not a regression.
> Thankfully, Steve Kargl's recent FORALL analysis reveals the construct is
> still rare, so hopefully not many codes are affected.
>   
Hopefully, you can get it into a good state so that we can educatepeople 
that it is a smart thing to do :-)
> be the innermost FORALL.  This then only requires a singly linked list,
> O(1) cons as we enter a scope and no need to unlink the head as we pop out
> of a scope.  Much like other "scopes" are handled in GCC.
>   
That's just the business...
> As an additional benefit, not only does this reorganization simplify the
> code and resolve the bug, but also enables some further FORALL
> optimizations that I'll submit as a follow-up patch.  However, its better
> to keep this as an independent bug-fix, as I suspect the gfortran
> maintainers might request a 4.2 backport given its seriousness despite not
> being a "classical" regression.
>   
Yes indeed.  We cannot have a feature that is so fundamental to f95 
producing wrong results.
> The following patch has been tested on x86_64-unknown-linux-gnu with a
> full "make bootstrap", all default languages including fortran and
> regression tested with a top-level "make -k check" with no new failures.
>
> Ok for mainline?
>   
Yes, OK and, as I said above, OK for 4.2.

Paul

PS Modulo the correction on the initialization using an uninitialized 
variable that Tobias picked up  my patch for WHERE interface assignments 
is ready to go;  I will re-submit it in a few minutes.  Would you be 
kind enough to cast an eye over it, please?  I am in a position to do 
one commit this weekend.  I would like this one to sit on trunk for a 
few weeks before submitting an upgrade of the implementation of 
interface assignments everywhere.