[4.5, Patch, Fortran] PR 36704: Procedure pointer as function result

[Janus Weil]

Hi Mikael,

first off: thanks a lot for your review!

> Now, the details.
>
> About this:
> +
> +  if (add_hidden_procptr_result (sym) == SUCCESS)
> +    sym = sym->result;
> +
> Is it really needed in the case of a subroutine ?

Actually, yes. This snippet appearing inside gfc_match_subroutine is
needed for cases like the one labeled "h" in my test case, where a
function returns a pointer to a subroutine, and the subroutine is
specified by an INTERFACE statement.


> +    sym = sym->result;
> sym->name becomes invalid. Try this for example:
> --- proc_ptr_13.f90     2008-12-08 16:44:13.000000000 +0100
> +++ proc_ptr_13.f90.old 2008-12-08 16:44:08.000000000 +0100
> @@ -57,7 +57,7 @@
>   function f()
>     pointer :: f
>     interface
> -      integer function f(x) bind(c)
> +      integer function f(x)
>         integer :: x
>       end function
>     end interface

Hm, good point. In the error message the wrong name appears. However,
I'm not sure how to fix this. Anyway I need to replace the symbol by
sym->result here, so that the rest of the function interface is
applied to the result, not to the original function symbol.

I don't really want to add an extra check like "if (strcmp
("ppr@",sym->name) ..." to every possible error message :(

Ideas, anyone?


> +  else if (strcmp (block_name, "ppr@") == 0
> This is hard to understand if it's not used close to where "ppr@" was
> defined. One should either use sym->attr.proc_pointer && (...) or add a
> comment before explaining what we are doing  or simply reminding that
> ppr stands for procedure pointer result.

I don't think I can use sym->attr.proc_pointer here, since the pointer
attribute may not have been specified at this point (cf. case "g").
But a simple comment will do, I guess.


> Looks good otherwise. I failed to make it fail.

Nice to hear :)


> PS: Why not add a runtime test for h and i as well ?

Yeah, will do. No particular reason, apart from laziness.


> PPS: How are generic intrinsics handled? I tried this, and it doesn't
> complain. (And chooses the real_4 specific according to gdb).
> --- proc_ptr_13.f90.old 2008-12-08 16:44:08.000000000 +0100
> +++ proc_ptr_13.f90     2008-12-08 17:29:53.000000000 +0100
> @@ -90,10 +90,11 @@
>     pointer :: i
>     interface
>       function i(x)
> -        real :: i,x
> +        real :: i
> +        real(8) :: x
>       end function i
>     end interface
>     i => sin

Ok, this is more of a general procptr issue, not specific to function results.
One reason for this being accepted silently, is that there are still
some interface checks missing for procptr assignments (see PR38290).
This is next on my list for 4.5 :)


I also found one other thing that was missing: Up to now I only
included cases where the function gets assigned some value. However it
is also possible to assign another procptr to the return value inside
the function (see my new testcase "k"), which I fixed now.

Am I missing anything else? I think all other uses of a procptr return
value inside the returning function would be recursive. Or ambiguous
in some way. Example:

  function f()
    procedure(real),pointer :: f
    f => ...
    print *,f()
  end function

How would one interpret this? Which function is called in the print
statement? The function that is the return value of f? Or the function
f itself (recursively)? Is this example legal at all?


I have updated the patch & testcase, and also added a test for Tobias'
objection regarding use-association.

If there are any further comments on the patch: Keep it coming ;)
Anyway we'll have some time until this can be checked in. And I still
have to think of a way to handle the wrong name in error messages that
Mikael complained about ...

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr36704_2.diff
Type: text/x-patch
Size: 10713 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081209/236ab153/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_ptr_13.f90
Type: application/octet-stream
Size: 2113 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/fortran/attachments/20081209/236ab153/attachment.obj>