[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #21 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #19)
> Comment on attachment 44718 [details]
> Affected module and example main program
> 
> The only way at the moment would be to change
> 
> program testprog
> 
>   use testmodule
> 
>   type(instlist_type),target:: instlist
>  
>   instlist%min_tstart = 42
>   instlist%max_tstop = 101
> 
>   print *, "Hello world"
>   
> end program testprog
> 
> into
> 
> program testprog
> 
>   use testmodule
> 
>   type(instlist_type),target, allocatable:: instlist
>  
>   allocate (instlist)
>   instlist%min_tstart = 42
>   instlist%max_tstop = 101
> 
>   print *, "Hello world"
>   
> end program testprog
> 
> if instlist is large enough, possibly in a front-end pass.

Actually no, this change does not work.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

Thomas Koenig  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|tkoenig at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #20 from Thomas Koenig  ---
Unassigning for now.  I don't think the stack part can be fixed
in the gcc 9.1 release timeframe.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #19 from Thomas Koenig  ---
Comment on attachment 44718
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44718
Affected module and example main program

The only way at the moment would be to change

program testprog

  use testmodule

  type(instlist_type),target:: instlist

  instlist%min_tstart = 42
  instlist%max_tstop = 101

  print *, "Hello world"

end program testprog

into

program testprog

  use testmodule

  type(instlist_type),target, allocatable:: instlist

  allocate (instlist)
  instlist%min_tstart = 42
  instlist%max_tstop = 101

  print *, "Hello world"

end program testprog

if instlist is large enough, possibly in a front-end pass.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #18 from Thomas Koenig  ---
The quadratic behavior is gone, but the very large stack usage is not
fixed yet.

Looking further.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #17 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Apr 14 12:27:44 2019
New Revision: 270352

URL: https://gcc.gnu.org/viewcvs?rev=270352=gcc=rev
Log:
2019-04-14  Thomas Koenig  

PR fortran/87352
Backport from trunk
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early.  Set component->finalized on exit.

2019-04-14  Thomas Koenig  

Backport from trunk
PR fortran/87352
* gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
* gfortran.dg/finalize_34.f90: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/finalize_34.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/class.c
branches/gcc-7-branch/gcc/fortran/gfortran.h
branches/gcc-7-branch/gcc/testsuite/ChangeLog
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/finalize_28.f90

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-14 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #16 from Thomas Koenig  ---
Author: tkoenig
Date: Sun Apr 14 12:17:42 2019
New Revision: 270351

URL: https://gcc.gnu.org/viewcvs?rev=270351=gcc=rev
Log:
2019-04-14  Thomas Koenig  

PR fortran/87352
Backport from trunk
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early.  Set component->finalized on exit.

2019-04-14  Thomas Koenig  

Backport from trunk
PR fortran/87352
* gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
* gfortran.dg/finalize_34.f90: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/finalize_34.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/class.c
branches/gcc-8-branch/gcc/fortran/gfortran.h
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/finalize_28.f90

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-04-06 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #15 from Thomas Koenig  ---
Author: tkoenig
Date: Sat Apr  6 22:10:28 2019
New Revision: 270184

URL: https://gcc.gnu.org/viewcvs?rev=270184=gcc=rev
Log:
2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.h (gfc_component): Add finalized field.
* class.c (finalize_component): If the component is already
finalized, return early.  Set component->finalized on exit.

2019-04-06  Thomas Koenig  

PR fortran/87352
* gfortran.dg/finalize_28.f90: Adjust count of __builtin_free.
* gfortran.dg/finalize_33.f90: Likewise.
* gfortran.dg/finalize_34.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/finalize_34.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/class.c
trunk/gcc/fortran/gfortran.h
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/finalize_28.f90
trunk/gcc/testsuite/gfortran.dg/finalize_33.f90

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #14 from Jeremy Sanders  ---
Created attachment 46064
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46064=edit
Patch to instrument gfortran for test case

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #13 from Jeremy Sanders  ---
Created attachment 46063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46063=edit
log (minor edits) from instrumentation patch

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #12 from Jeremy Sanders  ---
Thomas - unfortunately I don't have a copy of what I did. I think reverting
this patch fixes the problem though:
https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/fortran/resolve.c?r1=254427=254426=254427

Sorry - I left out the allocate statements in the test case. Do you want me to
fix the test case?

I've not fixed the problem, but I've been putting debugging statements into the
code to try to understand what is going on. Please see the attached log file
and print patch.

What appears to happen is that generate_finalization_wrapper for
testmodule_Evtlistlist_type calls finalize_component for evtlistlist_type. This
in turn calls finalize_component for each member of evtlist_type. For N
members, N gfc_code objects are created (See the code pointers in the log).
Here my program has members p00, p01, p02 and p03.

When these code objects are then interpreted in gfc_trans_deallocate
structure_alloc_comps does a deallocation for each of the members. This leads
to the N^2 behaviour as the is a gfc_code object made for each member, and each
of these code objects does a deallocation of all members.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tkoenig at gcc dot 
gnu.org

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #11 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #10)
> This patch
> 
> Index: class.c
> ===
> --- class.c (Revision 269895)
> +++ class.c (Arbeitskopie)
> @@ -1031,11 +1031,13 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
>  }
>else
>  {
> +#if 0
>gfc_component *c;
>  
>for (c = comp->ts.u.derived->components; c; c = c->next)
> finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray,
> code,
> sub_ns);
> +#endif 
>gfc_free_expr (e);
>  }
>  }
> 
> leads to a reduction in the compile time, but a segfault in the
> test case.

... but then the test case lacks a few ALLOCATE statements to be valid :-)

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #10 from Thomas Koenig  ---
This patch

Index: class.c
===
--- class.c (Revision 269895)
+++ class.c (Arbeitskopie)
@@ -1031,11 +1031,13 @@ finalize_component (gfc_expr *expr, gfc_symbol *de
 }
   else
 {
+#if 0
   gfc_component *c;

   for (c = comp->ts.u.derived->components; c; c = c->next)
finalize_component (e, comp->ts.u.derived, c, stat, fini_coarray, code,
sub_ns);
+#endif 
   gfc_free_expr (e);
 }
 }

leads to a reduction in the compile time, but a segfault in the
test case.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-31 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #9 from Thomas Koenig  ---
I think this is a high-priority bug that we should try to fix
before the GCC 9 release.

Some discussion here:

https://gcc.gnu.org/ml/fortran/2019-03/msg00124.html

Jeremy, you mentioned that you commented out a loop in finalize_component.
Could you put a patch here to see exactly what you did?

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-21 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #8 from Jeremy Sanders  ---
Created attachment 46003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46003=edit
Much smaller testcase. Switch 73/74 to see the difference.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-21 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #7 from Jeremy Sanders  ---
Created attachment 46002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46002=edit
Tiny patch to fix testcase

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2019-03-21 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #6 from Jeremy Sanders  ---
I think I have worked out where the problem lies. The code contains fixed-sized
arrays of types containing allocatable arrays and other nested types with
allocatable arrays. If I switch the fixed-sized declarations to allocatable,
then the compile time and output size drastically reduce.

Changing three of the declarations in the source code to allocatable fixes the
problem (see attached test case patch).

I've also made a much smaller testcase (only 90 lines) which highlights the
problem. This source code takes 50s to compile on my system. Commenting out
line 73 and uncommenting line 74 reduces the compile time to 0.4s.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2018-11-27 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||jakub at gcc dot gnu.org,
   ||pault at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
The first growth of *.original dump is r241885, where it grew from a ~70KB to
~320KB.  And then the next even larger growth is in r254427.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2018-10-27 Thread jeremy at jeremysanders dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #4 from Jeremy Sanders  ---
Janne: This problem is also present on version 7, whereas the other bug is new
in 8. There may be a relation, however.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2018-10-26 Thread jb at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #3 from Janne Blomqvist  ---
Might this be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487 ?

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2018-09-30 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

--- Comment #2 from Thomas Koenig  ---
(In reply to Thomas Koenig from comment #1)

> so we are generating a factor of 15 more code.

I mean 150.

[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran

2018-09-30 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352

Thomas Koenig  changed:

   What|Removed |Added

   Keywords||compile-time-hog,
   ||memory-hog
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-09-30
 CC||tkoenig at gcc dot gnu.org
   Target Milestone|--- |9.0
Summary|Large stack usage with new  |[7/8/9 Regression] Large
   |gfortran|stack usage with new
   ||gfortran
 Ever confirmed|0   |1

--- Comment #1 from Thomas Koenig  ---
4.8 is OK, 7, 8, and 9 all show the same kind of behavior.

Size of *.original with 4.8:

-rw-r--r-- 1 ig25 users 119187 30. Sep 20:40 big.f90.003t.original

Size of *.original with recent trunk:

-rw-r--r-- 1 ig25 users 17933202 30. Sep 20:41 big.f90.004t.original

so we are generating a factor of 15 more code.