Roger Sayle - [FORTRAN PATCH] PR30400: ANY not accepted as FORALL mask (original) (raw)

This is the mail archive of the gcc-patches@gcc.gnu.orgmailing list for the GCC project.

• From: "Roger Sayle"
• To: fortran at gcc dot gnu dot org
• Cc: gcc-patches at gcc dot gnu dot org
• Date: Thu, 15 Feb 2007 23:04:20 -0700 (MST)
• Subject: [FORTRAN PATCH] PR30400: ANY not accepted as FORALL mask

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 :[:].

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

Attachment:patchF.txt
Description: Text document

Attachment:pr30400_1.f90
Description: Text document

• Follow-Ups:
  • Re: [FORTRAN PATCH] PR30400: ANY not accepted as FORALL mask
    * From: Paul Thomas