[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