Bug 54107 - [4.8 Regression] [F03] Memory hog with abstract interface
Summary: [4.8 Regression] [F03] Memory hog with abstract interface
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.8.0
: P4 normal
Target Milestone: 4.8.0
Assignee: janus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-07-27 12:00 UTC by Dominique d'Humieres
Modified: 2014-04-16 08:37 UTC (History)
5 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2012-09-22 00:00:00


Attachments
Not working patch (7.69 KB, patch)
2013-01-20 17:31 UTC, Mikael Morin
Details | Diff
patch v2 (9.07 KB, patch)
2013-01-25 14:43 UTC, janus
Details | Diff
patch v3 (8.94 KB, patch)
2013-01-26 16:10 UTC, janus
Details | Diff
Draft patch for comment #4, to be tested. (840 bytes, patch)
2013-01-28 12:31 UTC, Mikael Morin
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dominique d'Humieres 2012-07-27 12:00:23 UTC
The following test

module computation_data 
    implicit none 
    type computation_method 
        character(len=40)                           :: name 
        procedure(compute_routine), pointer, nopass :: compute 
    end type 
    abstract interface 
        subroutine compute_routine( param_value, zfunc, probability ) 
            real, dimension(:), intent(in) :: param_value 
            procedure(compute_routine)     :: zfunc 
            real, intent(in)               :: probability 
        end subroutine 
    end interface 
end module computation_data 

coming from 

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/4b313361fd13ca8d#

used to compile up to revision 189440 (with the patches for assumed-rank array). It now (after revision 189780 gives a segmentation fault after a very long time (~19 minutes) and using a lot of memory (more than 6462064 kb).
Comment 1 Dominique d'Humieres 2012-07-27 12:05:08 UTC
Forgot to fill the summary;-(
Comment 2 Dominique d'Humieres 2012-07-29 08:00:01 UTC
This is due to revision 189514 (with r189513 reverted in order to bootstrap):

Author:	janus
Date:	Mon Jul 16 10:13:19 2012 UTC (12 days, 21 hours ago)
Changed paths:	6
Log Message:	
2012-07-16  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/53956
	* gfortran.h (gfc_copy_formal_args,gfc_copy_formal_args_ppc): Modified
	prototypes.
	* symbol.c (gfc_copy_formal_args): New argument 'if_src'. Copy if_source
	of dummy procedures.
	(gfc_copy_formal_args_ppc): Ditto.
	* resolve.c (resolve_procedure_interface): Pass IFSRC_DECL to
	gfc_copy_formal_args.
	(resolve_fl_derived0): Pass IFSRC_DECL to gfc_copy_formal_args_ppc.


2012-07-16  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/53956
	* gfortran.dg/proc_decl_28.f90: New.
Comment 3 janus 2012-07-29 08:46:22 UTC
(In reply to comment #2)
> This is due to revision 189514 (with r189513 reverted in order to bootstrap):

Ok, I already suspected this revision as a possible candidate for the breakage. Will have a look ...
Comment 4 janus 2012-07-29 16:50:37 UTC
Reduced test case:

  subroutine compute_routine (zfunc) 
    procedure(compute_routine) :: zfunc 
  end subroutine 


I would assume that this is invalid, since the declaration of compute_routine's interface is somehow 'recursive', i.e. referring to itself.
Comment 5 janus 2012-07-29 20:54:21 UTC
(In reply to comment #4)
> I would assume that this is invalid, since the declaration of compute_routine's
> interface is somehow 'recursive', i.e. referring to itself.

... however, I could not find anything in the standard that would prohibit it. And also Bob Corbett claims that it is valid in the c.l.f. thread mentioned in comment #0.

The problem is that we generate an infinite chain of symbols: 'compute_routine' has a formal argument 'zfunc', which itself has an argument 'zfunc', and so on.

Certainly, gfc_copy_formal_args plays a role in this process, but also resolve_formal_arglist is involved.
Comment 6 Dominique d'Humieres 2012-09-22 22:21:02 UTC
(In reply to comment #4)
> I would assume that this is invalid, since the declaration of compute_routine's
> interface is somehow 'recursive', i.e. referring to itself.

From f2008 draft:

> 12.4.3.6 Procedure declaration statement
>
> ...
>
> 2 If proc-interface appears and consists of interface-name, it species an 
> explicit specic interface (12.4.3.2) for the declared procedures or procedure 
> pointers. The abstract interface (12.4) is that specied by the interface named 
> by interface-name.

My understanding of the above quote is that

    procedure(compute_routine) :: zfunc 

has nothing to do with recursiveness, but that zfunc has the same interface as compute_routine. Am I wrong?

BTW adding RECURSIVE to compute_routine does not help.
Comment 7 janus 2012-09-22 22:29:36 UTC
(In reply to comment #6)
> (In reply to comment #4)
> > I would assume that this is invalid, since the declaration of compute_routine's
> > interface is somehow 'recursive', i.e. referring to itself.
> 
> From f2008 draft:
> 
> > 12.4.3.6 Procedure declaration statement
> >
> > [...]
> 
> My understanding of the above quote is that
> 
>     procedure(compute_routine) :: zfunc 
> 
> has nothing to do with recursiveness, but that zfunc has the same interface as
> compute_routine.

Yes, sure. I'm not claiming that it actually indicates a recursive procedure. All I ment to say was that the *declaration* is 'recursive', in the sense that it refers to itself. (This recursiveness of the declaration is not to be confused with run-time recursiveness, where a procedure calls itself.)
Comment 8 Mikael Morin 2013-01-13 19:43:04 UTC
(In reply to comment #2)
> This is due to revision 189514 (with r189513 reverted in order to bootstrap):

Hum, that change looks very innocent.  Janus do you have an explanation for the regression?  I do see the "recursiveness", but I don't see its relationship with the change above.  It seems the latter only propagates the if_source information around.
Comment 9 Mikael Morin 2013-01-19 22:54:06 UTC
Maybe we could remove gfc_copy_formal_args{,_ppc} completely.  After all, we keep a pointer to the interface, so the dummy arguments remain available through sym->ts.interface->formal.
Comment 10 Mikael Morin 2013-01-20 17:31:24 UTC
Created attachment 29228 [details]
Not working patch

This patch implements comment #9.
It fails on proc_decl* and proc_ptr* and cray_pointer_9 unfortunately.  I investigated the last failure and the outcome is this:  if the dummy arguments are not present in the procedure symbol, then the array spec and the character length shall be taken out of it as well, as they contain expressions that may refer to the dummy arguments.  This makes the approach really too intrusive.
Comment 11 janus 2013-01-25 14:36:34 UTC
(In reply to comment #9)
> Maybe we could remove gfc_copy_formal_args{,_ppc} completely.  After all, we
> keep a pointer to the interface, so the dummy arguments remain available
> through sym->ts.interface->formal.

Yes, I think this should work in principle. Also it seems to be the only sane way to avoid the infinite-loop problem.
Comment 12 janus 2013-01-25 14:43:51 UTC
Created attachment 29274 [details]
patch v2

Here is an updated version of Mikael's patch, which is free of testsuite regressions.


It fixes comment #0, but fails with a very strange backtrace on comment 4:

gfortran-4.8: internal compiler error: Segmentation fault (program f951)
0x4069a3 execute
        /home/jweil/gcc48/trunk/gcc/gcc.c:2789
0x40adb1 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:4581
0x40e36e process_brace_body
        /home/jweil/gcc48/trunk/gcc/gcc.c:5838
0x40e18a handle_braces
        /home/jweil/gcc48/trunk/gcc/gcc.c:5752
0x40ce19 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:5235
0x40e36e process_brace_body
        /home/jweil/gcc48/trunk/gcc/gcc.c:5838
0x40e18a handle_braces
        /home/jweil/gcc48/trunk/gcc/gcc.c:5752
0x40ce19 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:5235
0x40d225 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:5340
0x40e36e process_brace_body
        /home/jweil/gcc48/trunk/gcc/gcc.c:5838
0x40e18a handle_braces
        /home/jweil/gcc48/trunk/gcc/gcc.c:5752
0x40ce19 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:5235
0x40e36e process_brace_body
        /home/jweil/gcc48/trunk/gcc/gcc.c:5838
0x40e18a handle_braces
        /home/jweil/gcc48/trunk/gcc/gcc.c:5752
0x40ce19 do_spec_1
        /home/jweil/gcc48/trunk/gcc/gcc.c:5235
0x40a40b do_spec_2
        /home/jweil/gcc48/trunk/gcc/gcc.c:4282
0x40a329 do_spec(char const*)
        /home/jweil/gcc48/trunk/gcc/gcc.c:4249
Comment 13 Mikael Morin 2013-01-25 20:58:10 UTC
(In reply to comment #12)
> Here is an updated version of Mikael's patch, which is free of testsuite
> regressions.

Indeed, it was not that difficult after all. :-)
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?
 
> 
> 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:

gfc_get_function_type (gfc_symbol * sym)
{
  [...]
  for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
    {
      arg = f->sym;
      if (arg)
	{
          [...]
	  if (arg->attr.flavor == FL_PROCEDURE)
	    {
	      type = gfc_get_function_type (arg);
	      type = build_pointer_type (type);
	    }
Comment 14 janus 2013-01-26 11:31:24 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > Here is an updated version of Mikael's patch, which is free of testsuite
> > regressions.
> 
> Indeed, it was not that difficult after all. :-)

Yeah, once you give it a try ... ;)

But seriously: Thanks for making a start on this (I guess it was a silly idea from the start to try and copy everything).


> 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

Without checking the standard, I would guess that this is illegal. Not sure if we reject it, though.


> > 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:
> 
> gfc_get_function_type (gfc_symbol * sym)
> {
>   [...]
>   for (f = gfc_sym_get_dummy_args (sym); f; f = f->next)
>     {
>       arg = f->sym;
>       if (arg)
>     {
>           [...]
>       if (arg->attr.flavor == FL_PROCEDURE)
>         {
>           type = gfc_get_function_type (arg);
>           type = build_pointer_type (type);
>         }

So, do you have an idea how to escape this infinite recursion?
Comment 15 janus 2013-01-26 16:10:40 UTC
Created attachment 29279 [details]
patch v3

Here is a new patch, which does some further cleanup, such as removing the 'formal' and 'formal_ns' members of gfc_component (which are not used any more).

Further, I removed the class.c part (I don't really see how it is related to the rest of the patch).
Comment 16 janus 2013-01-26 16:16:13 UTC
(In reply to comment #15)
> Created attachment 29279 [details]
> patch v3

Forgot to mention: Still regtests cleanly.
Comment 17 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.
Comment 18 Mikael Morin 2013-01-26 23:08:34 UTC
(In reply to comment #15)
> Here is a new patch, which does some further cleanup, such as removing the
> 'formal' and 'formal_ns' members of gfc_component (which are not used any
> more).

This implies a module version bump. :-(
If you are into removing things, maybe the resolve_structure_cons hunk can go too.


> Further, I removed the class.c part (I don't really see how it is related to
> the rest of the patch).

The point was to avoid the _copy member having no interface.  I don't remember if I did this while systematically checking uses of formal/interface or if it was fixing a regression;  I think it was the latter.  Bah, if it works...
Comment 19 janus 2013-01-27 09:22:56 UTC
(In reply to comment #17)
> (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

Well, I guess whether this is legal Fortran or not depends a bit on what the second [...] is supposed to be. If there is something like an END PROGRAM or END MODULE in there, then your PROCEDURE statement simply amounts to an external declaration of 'proc' and everything is fine.

If the second [...] is rather something like a CONTAINS, however, then your code is illegal, since you specify the interface twice in the same program unit (gfortran reports this error properly).


> 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').

No, I don't think this is possible (see above reasoning). Certainly every procedure is supposed to have a uniquely determined interface.
Comment 20 janus 2013-01-27 09:46:02 UTC
(In reply to comment #18)
> (In reply to comment #15)
> > Here is a new patch, which does some further cleanup, such as removing the
> > 'formal' and 'formal_ns' members of gfc_component (which are not used any
> > more).
> 
> This implies a module version bump. :-(

I actually thought that the module version had already been bumped for 4.8. At least this is claimed at http://gcc.gnu.org/wiki/GFortran#GCC4.8.

However, I just had a look into module.c in 4.7 and trunk, and both show:

#define MOD_VERSION "9"

I'm confused ...


> If you are into removing things, maybe the resolve_structure_cons hunk can go
> too.

Ah, yes.


> > Further, I removed the class.c part (I don't really see how it is related to
> > the rest of the patch).
> 
> The point was to avoid the _copy member having no interface.  I don't remember
> if I did this while systematically checking uses of formal/interface or if it
> was fixing a regression;  I think it was the latter.  Bah, if it works...

Huh, I'm not really sure if we really need the interface for the case of an ABSTRACT or unlimited polymorphic type (I'd rather think that we don't).

But if you have a case where this makes trouble, it should surely be fixed. Otherwise: If it ain't broke, don't try to fix fix it ... ;)
Comment 21 Paul Thomas 2013-01-27 12:58:23 UTC
Hi Janus and Mikael,

Is one of you going to take this bug and fix it?  It seems to me that this would be a good time to do so.

Cheers

Paul
Comment 22 janus 2013-01-27 13:24:01 UTC
Hi Paul,

> Is one of you going to take this bug and fix it?

we are both struggling to fix this, I guess :)


> It seems to me that this
> would be a good time to do so.

Certainly! I can post the current patch to the mailing list for review, and I would greatly appreciate if Mikael could have a closer look at the infinite recursion in gfc_get_function_type ...

One of the open questions is of course how to handle the MOD_VERSION issue (i.e. should this be bumped for 4.8?). If not, we should fix the docu on the wiki!

Unfortunately the patch is a bit intrusive, but it does fix a regression after all ...
Comment 23 Mikael Morin 2013-01-28 12:31:19 UTC
Created attachment 29294 [details]
Draft patch for comment #4, to be tested.

As I said on @fortran, I don't think it's possible to create recursive middle-end types.  With this patch the dummy procedure gets a variadic function type, which is the best we can do in this case.
Comment 24 janus 2013-01-28 13:48:54 UTC
(In reply to comment #23)
> Created attachment 29294 [details]
> Draft patch for comment #4, to be tested.

Thanks! Seems to work on comment 4 at least. I'll try a regtest.
Comment 25 janus 2013-01-28 16:04:14 UTC
(In reply to comment #24)
> > Draft patch for comment #4, to be tested.
> 
> Thanks! Seems to work on comment 4 at least. I'll try a regtest.

Regtest went through cleanly, and it also works well for an 'indirect' case like this:


contains

  subroutine s1 (arg1)
    procedure(s2) :: arg1
  end subroutine

  subroutine s2 (arg2)
    procedure(s1) :: arg2
  end subroutine

end
Comment 26 Mikael Morin 2013-01-28 19:46:01 UTC
Thanks for testing.
There is one case that remains to be handled.  I suppose it is valid if the other are valid.

  function foo () result(bar)
    procedure(foo), pointer :: bar 
  end function
Comment 27 janus 2013-01-28 22:42:48 UTC
(In reply to comment #26)
> There is one case that remains to be handled.  I suppose it is valid if the
> other are valid.
> 
>   function foo () result(bar)
>     procedure(foo), pointer :: bar 
>   end function

Yes, in principle proc-ptr valued functions are allowed. I don't see why it wouldn't be valid.

This ICEs for me with 4.6, 4.7 and trunk (with the current patches for this PR).
Comment 28 janus 2013-01-29 21:40:55 UTC
Author: janus
Date: Tue Jan 29 21:40:51 2013
New Revision: 195562

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195562
Log:
2013-01-29  Janus Weil  <janus@gcc.gnu.org>
	    Mikael Morin <mikael@gcc.gnu.org>

	PR fortran/54107
	* gfortran.h (gfc_component): Delete members 'formal' and 'formal_ns'.
	(gfc_copy_formal_args,gfc_copy_formal_args_ppc,gfc_expr_replace_symbols,
	gfc_expr_replace_comp): Delete.
	(gfc_sym_get_dummy_args): New prototype.
	* dependency.c (gfc_check_fncall_dependency): Use
	'gfc_sym_get_dummy_args'.
	* expr.c (gfc_is_constant_expr): Ditto.
	(replace_symbol,gfc_expr_replace_symbols,replace_comp,
	gfc_expr_replace_comp): Deleted.
	* frontend-passes.c (doloop_code,do_function): Use
	'gfc_sym_get_dummy_args'.
	* interface.c (gfc_check_operator_interface,gfc_compare_interfaces,
	gfc_procedure_use,gfc_ppc_use,gfc_arglist_matches_symbol,
	gfc_check_typebound_override): Ditto.
	* module.c (MOD_VERSION): Bump module version.
	(mio_component): Do not read/write 'formal' and 'formal_ns'.
	* resolve.c (resolve_procedure_interface,resolve_fl_derived0): Do not
	copy formal args, but just keep a pointer to the interface.
	(resolve_function,resolve_call,resolve_typebound_generic_call,
	resolve_ppc_call,resolve_expr_ppc,generate_component_assignments,
	resolve_fl_procedure,gfc_resolve_finalizers,check_generic_tbp_ambiguity,
	resolve_typebound_procedure,check_uop_procedure): Use
	'gfc_sym_get_dummy_args'.
	* symbol.c (free_components): Do not free 'formal' and 'formal_ns'.
	(gfc_copy_formal_args,gfc_copy_formal_args_ppc): Deleted.
	(gfc_sym_get_dummy_args): New function.
	* trans-array.c (get_array_charlen,gfc_walk_elemental_function_args):
	Use 'gfc_sym_get_dummy_args'.
	* trans-decl.c (build_function_decl,create_function_arglist,
	build_entry_thunks,init_intent_out_dt,gfc_trans_deferred_vars,
	add_argument_checking): Ditto.
	* trans-expr.c (gfc_map_fcn_formal_to_actual,gfc_conv_procedure_call,
	gfc_conv_statement_function): Ditto.
	* trans-stmt.c (gfc_conv_elemental_dependencies): Ditto.
	* trans-types.c (create_fn_spec,gfc_get_function_type): Ditto.


2013-01-29  Janus Weil  <janus@gcc.gnu.org>
	    Mikael Morin <mikael@gcc.gnu.org>

	PR fortran/54107
	* gfortran.dg/proc_ptr_comp_36.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_36.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/dependency.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/frontend-passes.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/interface.c
    trunk/gcc/fortran/module.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/symbol.c
    trunk/gcc/fortran/trans-array.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-expr.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog
Comment 29 janus 2013-01-29 21:45:56 UTC
r195562 fixes comment 0.

ToDo: The test case in comment 4 still fails (cf. also comment 23 - 27).
Comment 30 Dominique d'Humieres 2013-01-30 13:34:31 UTC
> ToDo: The test case in comment 4 still fails (cf. also comment 23 - 27).

Note that after revision 195562, the test in comment #4 and its subsequent modifications are no longer "memory hogs" and now give the ICE in a fraction of second.

r195562 is also likely to have changed the compiler behavior of some of my tests derived from pr55959 (see pr55959 comment #4).

Question: does the patch in comment #23 apply on top of r195562?
Comment 31 janus 2013-01-30 15:02:46 UTC
(In reply to comment #30)
> > ToDo: The test case in comment 4 still fails (cf. also comment 23 - 27).
> 
> Note that after revision 195562, the test in comment #4 and its subsequent
> modifications are no longer "memory hogs" and now give the ICE in a fraction of
> second.

Right.


> Question: does the patch in comment #23 apply on top of r195562?

Yes, it should.
Comment 32 Mikael Morin 2013-02-04 18:34:41 UTC
Author: mikael
Date: Mon Feb  4 18:34:30 2013
New Revision: 195729

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195729
Log:
fortran/
	PR fortran/54107
	PR fortran/54195
	* gfortran.h (struct gfc_symbol): New field 'resolved'.
	* resolve.c (resolve_fl_var_and_proc): Don't skip result symbols.
	(resolve_symbol): Skip duplicate calls.  Don't check the current
	namespace.

testsuite/
	PR fortran/54107
	* gfortran.dg/recursive_interface_1.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/recursive_interface_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
Comment 33 Dominique d'Humieres 2013-02-05 20:24:37 UTC
Anything missing before this PR can be closed?
Comment 34 Mikael Morin 2013-02-05 21:31:20 UTC
(In reply to comment #33)
> Anything missing before this PR can be closed?

Unburying the patch for comment #4, testing it, committing it.
:-)
Comment 35 Mikael Morin 2013-02-08 15:13:45 UTC
Author: mikael
Date: Fri Feb  8 15:13:32 2013
New Revision: 195890

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195890
Log:
fortran/
	PR fortran/54107
	* trans-types.c (gfc_get_function_type): Change a NULL backend_decl
	to error_mark_node on entry.  Detect recursive types.  Build a variadic
	procedure type if the type is recursive.  Restore the initial
	backend_decl.

testsuite/
	PR fortran/54107
	* gfortran.dg/recursive_interface_2.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/recursive_interface_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog
Comment 36 Mikael Morin 2013-02-08 15:42:53 UTC
(In reply to comment #34)
> (In reply to comment #33)
> > Anything missing before this PR can be closed?
> 
> Unburying the patch for comment #4, testing it, committing it.
> :-)

This is now done.
Comment 37 Dominique d'Humieres 2013-02-08 15:46:48 UTC
> This is now done.

Thanks.
Comment 38 Bernd Edlinger 2014-04-16 08:37:41 UTC
Hmm...

the whole thing goes kaboom if I try to call any of the procedures in
recursive_interface_2.f90.

i.e. if I add the following at the end of the test case:

use m
  procedure(foo), pointer :: p_foo
  procedure(bar), pointer :: p_bar
  procedure(baz), pointer :: p_baz
  p_foo => foo
  p_bar => bar
  p_baz => baz
  call foo (p_foo)
  call baz (p_bar)
  call bar (p_baz)
  call p_foo (p_foo)
  call p_baz (p_bar)
  call p_bar (p_baz)
end


gfortran recursive_interface_2.f90 
gfortran: internal compiler error: Segmentation fault (program f951)
0x40c914 execute
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:2848
0x40ccc4 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:4652
0x40f586 process_brace_body
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40f586 handle_braces
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40db39 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40f586 process_brace_body
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40f586 handle_braces
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40db39 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40d8a3 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5421
0x40f586 process_brace_body
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40f586 handle_braces
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40db39 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40f586 process_brace_body
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5935
0x40f586 handle_braces
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5849
0x40db39 do_spec_1
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:5306
0x40e656 do_spec_2
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:4353
0x40fc68 do_spec(char const*)
	../../gcc-4.9.0-RC-20140411/gcc/gcc.c:4320
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.