[Bug fortran/87352] [7/8/9 Regression] Large stack usage with new gfortran
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.