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

[Daniel Kraft <d at domob dot eu>]

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

Yours,
Daniel


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