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

Roger Sayle roger@eyesopen.com
Fri Feb 16 16:25:00 GMT 2007


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.

One approach may be a new gfc_match_iterator_variable function that
doesn't modify the flavor and leaves this task to the caller.  This can be
just a shallow wrapper function such as gfc_match_variable and
gfc_match_equiv_varaible.  Then we commit to a flavor change at the same
place as we set n.sym->forall_index (line 3408 of match.c).

However, if you're confident in the ->refs == 1" to "->new == 1" fix, and
you're certainly more familiar with this code than I am, might I propose a
hybrid patch (i.e. both of our changes)?  Testing that the symbol we're
about to reset has flavor FL_VARIABLE should be an invariant of the
rollback, and guaranteed by your solution, and I much prefer a passive
(and fast) check than an assertion using gcc_assert or similar.

Yet another approach might be to sequester the previous value of
sym->attr.flavor on all calls to match_variable, much like combine's
subst, so that we can restore the original (or confirm that we've had an
FL_UNKNOWN to FL_VARIABLE transition) when we clean-up.


My apologies if I've complicated things.  Not fully understanding how your
fix works, I thought it best to clarrify how my solution works but why
perhaps isn't a complete solution.  Tightening necessary but not
sufficient conditions.

Roger
--




More information about the Fortran mailing list