http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107
--- Comment #17 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-26
22:47:28 UTC ---
(In reply to comment #14)
> > Are procedure dummy arguments mutually exclusive with non-NULL procedure
> > interface, so that there is no dummy ambiguity in the array spec and char
> > length?
>
> I'm not sure I understand the question. You can certainly declare dummy
> procedures with the PROCEDURE statement (so that they get a ts.interface).
> Still, I don't see how this could create ambiguities with the as or cl. Or are
> you talking about something like this:
>
> procedure(some_interface) :: proc
> integer(4) :: proc
>
No, I was thinking of C-like forward declaration:
interface
function some_interface(ifc_arg)
[...]
end interface
procedure(some_interface) :: proc
[...]
! Now the actual function
function proc (arg)
[...]
That doesn't feel right this way, but I was wondering whether there was a way
for a procedure like `proc' above to have dummy arguments both directly (`arg')
and through the interface (`ifc_arg'). Then the array spec could use either
`arg' or `ifc_arg' depending on how parsing/resolution is done (which would be
bad).
> > > It fixes comment #0, but fails with a very strange backtrace on comment 4:
> >
> > It seems to be an infinite recursion in gfc_get_function_type:
> >
> So, do you have an idea how to escape this infinite recursion?
Hum, no. I thought we could use temporarily NULL_TREE in the argument type
list, which would be fixed just after the type is known. That would work for
foo->foo recursion, but not for foo->bar->foo.
I guess we'll have to bypass build_function_type completely, and use
error_mark_node or something ad hoc to prevent infinite recursion, like it's
done in gfc_nonrestricted_type.
