This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [Patch, Fortran] PING: RFC: PR fortran/37779, diagnose "missing" recursive

Hi Paul,

thanks for your reply!

Paul Richard Thomas wrote:
Dear Daniel,

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 ;)


-- Done: Arc-Bar-Cav-Rog-Sam-Val-Wiz To go: Hea-Kni-Mon-Pri-Ran-Tou

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]