[FORTRAN PATCH] PR30400: ANY not accepted as FORALL mask

[Roger Sayle]

The following patch fixes PR fortran/30400 which is a rejects-valid and
ICE-on-valid problem using ANY, ALL or any logical intrinsic function as
the mask in a FORALL statement.

The problem is in the parser (match.c's match_forall_iterator) where the
parser when analysing a statement such as the one below speculatively
considers the identifiers after each comma to be the name of an iteration
variable to be followed by "=", then <start>:<end>[:<stride>].

  forall (i = 1:5, j = 1:5, k = 1:5, any (a (i, j, k, :) .gt. 6))

Hence it's not until the "(" after the "any" that syntactically we can
tell that "any" isn't another iteration variable such as "i", "j" or "k".
However it turns out that the speculative call to primary.c's
match_variable can occassionally modify the symbol it finds, for example
updating it's "flavor" from FL_UNKNOWN to FL_VARIABLE given the context.
To undo this side-effect when we roll-back the parse, the code following
the "cleanup:" label in match_forall_iterator *always* resets the
identifier's symbol flavour back to FL_UNKNOWN.

Unfortunately, in the case of this PR this "undo" mechanism is far too
aggressive.  For our "ANY" symbol, the match_variable fails because we
already know that the flavor is FL_PROCEDURE.  Reseting this to FL_UNKNOWN
even when it wasn't modified, causes the front-end to loose track of the
intrinsic's properties including logical return type, etc...


The fix below is to guard the parser roll-back/undo such that we only
revert the symbol flavour in a failed parse, if the flavor is currently
FL_VARIABLE.  This avoids corrupting the built-in intrinsics that are
FL_PROCEDURE, and better limits the modification to those symbols that
were actually/likely modified.  I don't think this is perfect, there's a
possibility that a symbol was FL_VARIABLE before we tried
treating/interpreting it as an forall iterator variable, in which case
we'll anonymize it back to FL_UNKNOWN.  However, this patch is sufficient
to resolve the current class of failures.

The following patch has been tested on x86_64-unknown-linux-gnu with a
full "make bootstrap", including gfortran, and tested with a top-level
"make -k check" with no new failures.

Ok for mainline?  Thoughts on a better fix?


2007-02-15  Roger Sayle  <roger@eyesopen.com>

        PR fortran/30400
        * match.c (match_forall_iterator): Only reset the flavor of the
        failed iteration variable's symbol to FL_UNKNOWN if match_variable
        may have updated it to FL_VARIABLE.

        * gfortran.dg/pr30400_1.f90: New test case.

Roger
--
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: patchF.txt
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070216/aa5eb785/attachment.txt>
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: pr30400_1.f90
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20070216/aa5eb785/attachment.f90>