From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27916 invoked by alias); 26 Jan 2013 22:47:54 -0000 Received: (qmail 27866 invoked by uid 48); 26 Jan 2013 22:47:32 -0000 From: "mikael at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/54107] [4.8 Regression] Memory hog with abstract interface Date: Sat, 26 Jan 2013 22:47:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: mikael at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Priority: P4 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2013-01/txt/msg02468.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107 --- Comment #17 from Mikael Morin 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.