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

[Tobias Schlüter]

Roger Sayle wrote:
> Hi Paul,
> 
> On Fri, February 16, 2007 6:33 am, Paul Richard Thomas wrote:
>> I believe that the enclosed accomplishes the required result in a
>> cleaner fashion. It regtests OK on Cygwin_NT/amd64.
> 
> I must admit that I'm having difficulty finding/following where the
> n.sym->new field gets set and cleared.  What I can figure out is that
> the side-effect that we're concerned about revolves around the call
> to gfc_add_flavor in the FL_UNKNOWN case on line 2395 of primary.c.
> Basically, we need some way to identify from the caller
> (match_forall_iterator) that this clause triggered, and we changed the
> symbol's flavor from FL_UNKNOWN to FL_VARIABLE.  Reseting flavor to
> FL_UNKNOWN any other time runs the risk of latent bugs.

If the n.sym->new field is set this means that the symbol is in the 
current gfc_namespace's list of new symbols.   This is a linked list of 
symbols which are removed from the namespace if an error occurs during 
the matching of a statement.  The list of new statements is cleared from 
gfc_commit_symbols().  Teh fields relating to this are defined below 
gfortran.h:865:
   /* Change management fields.  Symbols that might be modified by the
      current statement have the mark member nonzero and are kept in a
      singly linked list through the tlink field.  Of these symbols,
      symbols with old_symbol equal to NULL are symbols created within
      the current statement.  Otherwise, old_symbol points to a copy of
      the old symbol.  */

   struct gfc_symbol *old_symbol, *tlink;
   unsigned mark:1, new:1;

The whole business of backing up symbols is necessary because we create 
symbols very early, as soon as we match a name, long before we know if 
we match a legal statement or what kind of symbol could come in the 
current place.  In the case under consideration it is always clear from 
context if the current name should refer to a function or variable, so 
determining the flavor after matching the whole statement seems like the 
safest route, not creating any inconsistencies by incomplete or 
ill-advised backups.  This is probably true for most of the expression 
matching code, and a nice project would be reworking it to create the 
symbols much later in the process (Summer of Code anyone? :-)

Hope this helps in some way,
- Tobi