This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PING: RFC: PR fortran/37779, diagnose "missing" recursive
thanks for your reply!
Paul Richard Thomas wrote:
Where a *non-RECURSIVE* procedure is used as "procedure expression" and
could thus lead easily to being called recursively. In the PR is referenced
a clf-thread, where it seems to be not agreed upon whether this code is
really "illegal", but it is surely highly suspect.
I can think of no reason to distinguish it from a non-pointer
recursive procedure call. The reasons for prohibiting in should be
the same. I think that it should be an error and not a warning.
My personal opinion regarding this question is this:
In general, doing a procedure pointer assignment or passing as actual
argument is "suspicious" for non-RECURSIVE procedures and should thus be
a warning, regardless of it being in the procedure's own body or not
(maybe except for -std=f77 where defining RECURSIVE is no option).
Passing as actual argument *inside* the procedure body (as in the PR)
should be an error obviously, and doing a procedure pointer assignment
is somewhat inbetween; I would not necessarily regard this as "error"
but it is certainly dubious.
I'm however open for all behaviours, just depending on what we agree upon.
I attached the current patch reflecting the basic idea and open for
adaptions according to your opinions on the point above; in this version it
regression-tests fine on GNU/Linux-x86-32.
Apart from above, this is OK
Thanks for looking at it!
PS: It seems that resolve_actual_arglist never calls gfc_resolve_expr on
procedure expressions in the arglist. Is this a "bug" (without impacts) or
intended? On the other hand, gfc_resolve_expr *is* called for RHS's of
procedure pointer assignments, for instance. I'd have guessed that
gfc_resolve_expr "should" also be called for the actual arguments.
Yes, that is a "bug".
In this case, I'll revisit the patch and see if I can rewrite it as to
do the check only inside gfc_resolve_expr and make it called "always" on
the other hand, as this (calling gfc_resolve_expr as noted above as well
as doing the check only in this one place) seems better to me. If this
works out as well, you may choose which patch you prefer ;)
To go: Hea-Kni-Mon-Pri-Ran-Tou