[Bug fortran/54107] New: [4.8 Regression]

[Bug fortran/54107] New: [4.8 Regression]

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

             Bug #: 54107
           Summary: [4.8 Regression]
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr
                CC: burnus@net-b.de


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

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.8 Regression]            |[4.8 Regression] Memory hog
                   |                            |with abstract interface

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-07-27 12:05:08 UTC ---
Forgot to fill the summary;-(

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #3 from janus at gcc dot gnu.org 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 ...

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #4 from janus at gcc dot gnu.org 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #5 from janus at gcc dot gnu.org 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.

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

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-22
     Ever Confirmed|0                           |1

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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 speci\fes an 
> explicit speci\fc interface (12.4.3.2) for the declared procedures or procedure 
> pointers. The abstract interface (12.4) is that speci\fed 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #7 from janus at gcc dot gnu.org 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.)

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #8 from Mikael Morin <mikael at gcc dot gnu.org> 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.

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #9 from Mikael Morin <mikael at gcc dot gnu.org> 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.

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #10 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-20 17:31:24 UTC ---
Created attachment 29228
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29228
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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #11 from janus at gcc dot gnu.org 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #12 from janus at gcc dot gnu.org 2013-01-25 14:43:51 UTC ---
Created attachment 29274
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29274
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

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #13 from Mikael Morin <mikael at gcc dot gnu.org> 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);
        }

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #14 from janus at gcc dot gnu.org 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?

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #15 from janus at gcc dot gnu.org 2013-01-26 16:10:40 UTC ---
Created attachment 29279
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29279
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).

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #16 from janus at gcc dot gnu.org 2013-01-26 16:16:13 UTC ---
(In reply to comment #15)
> Created attachment 29279 [details]
> patch v3

Forgot to mention: Still regtests cleanly.

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

[mikael at gcc dot gnu.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.

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #18 from Mikael Morin <mikael at gcc dot gnu.org> 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...

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #19 from janus at gcc dot gnu.org 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #20 from janus at gcc dot gnu.org 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 ... ;)

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

[pault at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pault at gcc dot gnu.org

--- Comment #21 from Paul Thomas <pault at gcc dot gnu.org> 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

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #22 from janus at gcc dot gnu.org 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 ...

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |janus at gcc dot gnu.org
                   |gnu.org                     |
            Summary|[4.8 Regression] Memory hog |[4.8 Regression] [F03]
                   |with abstract interface     |Memory hog with abstract
                   |                            |interface

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #23 from Mikael Morin <mikael at gcc dot gnu.org> 2013-01-28 12:31:19 UTC ---
Created attachment 29294
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29294
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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #24 from janus at gcc dot gnu.org 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.

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #25 from janus at gcc dot gnu.org 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

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #26 from Mikael Morin <mikael at gcc dot gnu.org> 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

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #27 from janus at gcc dot gnu.org 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).

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #28 from janus at gcc dot gnu.org 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

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #29 from janus at gcc dot gnu.org 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).

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #30 from Dominique d'Humieres <dominiq at lps dot ens.fr> 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?

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

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #31 from janus at gcc dot gnu.org 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.

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #32 from Mikael Morin <mikael at gcc dot gnu.org> 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

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #33 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-05 20:24:37 UTC ---
Anything missing before this PR can be closed?

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #34 from Mikael Morin <mikael at gcc dot gnu.org> 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.
:-)

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #35 from Mikael Morin <mikael at gcc dot gnu.org> 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

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

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #36 from Mikael Morin <mikael at gcc dot gnu.org> 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.

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

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

--- Comment #37 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2013-02-08 15:46:48 UTC ---
> This is now done.

Thanks.

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

[bernd.edlinger at hotmail dot de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54107

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #38 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
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.