Re: [Patch, Fortran, 4.5] Procedure Pointer Components

[Janus Weil <janus at gcc dot gnu dot org>]

>>> Paul, I don't know if you have time to look into this. If not I will
>>> try to fix it myself.
>
> As you might have gathered, I did not have time - sorry.
>
>>
>> This finally works now (proc_ptr_comp_3.f90).
>
> Good :-)
>
>
>> Of course there still remains some work to be done:
>> * there is still one testsuite failure (typebound_call_4.f03)
>> * assignment checking does not yet work for PPCs
>> * PASS is not implemented
>
> Will you post a PR for these or will you fix them soonest?

I am planning to work on this soon and include it in the patch, so I
think a separate PR is not necessary.
As my project was just accepted for this year's GSoC, the Google
funding will enable me to put a reasonable amount of work into this in
the coming weeks and months :)


>> Furthermore I plan to do some more work on gfc_conv_procedure call
>> (previously named gfc_conv_function_call), to unify the handling of
>> ordinary functions/subroutines and PPCs. Also my PPC implementation
>
> I'm sorry but in what sense is it not unified? ?Am I being stupid or
> have I forgot something? ?I thought that procedure pointers were
> already handled here.

Well, let me explain what I meant here: This does not concern plain
procedure pointers, but only procedure pointer components.

The way I handled the problem that your previous implementation had
with proc_ptr_comp_3.f90 (i.e. replacing the derived type symbol's
backend_decl with the backend_decl for the PPC) is:

I passed the whole gfc_expr of the PPC through to
gfc_conv_function_call and gfc_conv_function_val, so that I can call
gfc_get_proc_ptr_comp from *there*, and don't need to make your
hackish replacement.

Before, these gfc_conv_function_* things could only handle
gfc_symbols, but not components. Now they get also passed a gfc_expr
(so that they can handle components), but also still have arguments
"sym" and an "arg". For EXPR_FUNCTION, the sym and arg could in
principle be inferred from the gfc_expr, so that we would only need
the expr argument, instead of the sym and arg. However, this does not
work yet for SUBROUTINE calls, where the symbol and argument list are
not stored in the gfc_expr, but in gfc_code->resolved_symbol and
gfc_code->ext.actual. If we change this, so that it is handled
analogously to FUNCTIONS, then we just need to pass a gfc_expr and be
happy. This is what I plan to do.


>> still uses the f2k_derived namespace that Daniel introduced with his
>> patches for type-bound procedures. This is done mostly for
>> convenience, and should in principle not be necessary. Therefore I
>> would prefer to avoid it for PPCs, but this will require some more
>
> Actually, I introduced the idea and I still think that it is necessary
> in order to correctly treat derived type extension and, ultimately
> OOP.

Sure, I agree that it is necessary for type-bound procedures (TBP),
but not so for PPCs, where you don't have all the problems with
extension etc.


> In some ways it is for convenience but mainly because one can
> use all the machinery in symbol.c. ?However, it comes into its own
> when you want to have a different contained procedure for an extension
> from one with the same name in the parent type. ?Whilst I agree that
> for procedure components, you could implement gfc_find_ppc by a linear
> search through the derived type components, what you have done is
> every bit as good/clean and might even be more efficient.

I think we agree that using f2k_derived for PPCs is *only* for
convenience, i.e. having a gfc_symbol to pass to all those routines
handling FUNCTIONS/SUBROUTINES which expect only a gfc_symbol, and no
component structures.

On the downside, this also produces some overhead, since for one PPC
you have to take care of a gfc_component *and* a gfc_symbol (in
f2k_derived) and keep both synchronized etc.

And it may not be that hard to generalize the FUNCTION handling
routines to handle a gfc_expr (including component references). This
is the route that I would prefer, but of course I'm open for
discussion, if you any striking arguments for using f2k_derived.


> I take it that you did not find a better way to pass the backend_decls
> around? *sigh* This will have to do for now - could you hang TODOs
> where it is done, please?

I think I solved this. See above.


> Anyway, the patch looks to be OK for trunk.

Actually I was planning to work a little more on this patch before I
commit it (my posting was meant more as a status update), but If
people agree that it makes sense to commit it already now, I can
surely do this.

Anyway, thanks a lot for your comments.

Cheers,
Janus