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

Janus Weil jaydub66@googlemail.com
Thu Dec 11 21:07:00 GMT 2008


>>> +    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?
> What about keeping the original name?

This obviously does not work, since we cannot have two symbols with
the same name in one namespace.


>> 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?
> 12.5.2.1
>   /If RESULT is specified, the name of the result variable of the
> function is result-name and all occurrences of the function name in
> execution-part statements in the scoping unit refer to the function
> itself. If RESULT is not specified, the result variable is function-name
> and all occurrences of the function name in execution-part statements in
> the scoping unit are references to the result variable./
>
> I guess it is valid, and the f referenced is the (pointer) return value.
> If one wants the function to be (recursively) called, I guess it would
> need to use a result suffix. At least, that's what I would do.

Ok, thanks for pointing this out. I added a test case for the above
example. However there is still one variant of this which is not
working yet (see commented out line in the test case). Uncommenting
this line results in:

proc_ptr_13.f90: In function 'l':
proc_ptr_13.f90:157: error: type mismatch in comparison expression
logical(kind=4)
integer(kind=4) (*<T39d>) (void)
integer(kind=4)
if (D.1645 != 11) goto <D.1646>; else goto <D.1647>;

proc_ptr_13.f90:157: internal compiler error: verify_gimple failed

I haven't managed yet to fix this without breaking something else.
Seemingly something goes wrong somewhere in trans-*.c. I'm always
having some trouble with the trans-* stuff, but I'll keep trying.

Apart from the things above I made some more modifications to the
patch and added new test cases.

Cheers,
Janus
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pr36704_2.diff
Type: text/x-patch
Size: 12602 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20081211/628f2d1c/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: proc_ptr_13.f90
Type: application/octet-stream
Size: 2559 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20081211/628f2d1c/attachment.obj>


More information about the Gcc-patches mailing list