[Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface

["mikael at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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.