[Bug fortran/97176] Cannot return deferred length strings when using -fno-automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97176 --- Comment #3 from Jeremy Sanders --- I'm not using -fno-automatic out of choice, unfortunately (I'd never use it otherwise). I maintaining part of a large software package which has this switched on (for unclear reasons). It will require some testing to remove this option. What would be really useful is a warning in the manual which makes it clear that it is a bad idea to use this option. This would help prevent people switching it on without knowing that it breaks standards-conforming code. Unless you know the fortran standard well, it just seems a minor code generation option from the current docs. I'd be happy if this bug was closed with a documentation update (or a warning is added for this case). What about adding something like "Use of this option is highly discouraged as it can break standard-conforming code. Its use is only intended as a short-term fix for non-standard code." ?
[Bug fortran/97176] New: Cannot return deferred length strings when using -fno-automatic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97176 Bug ID: 97176 Summary: Cannot return deferred length strings when using -fno-automatic Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeremy at jeremysanders dot net Target Milestone: --- Created attachment 49261 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49261=edit Test case Functions returning deferred length strings return empty strings with the -fno-automatic compiler option. Please see the attached program (tested on trunk on godbolt.org). $ gfortran testprog.f90 $ ./a.out Hello, world! $ gfortran -fno-automatic testprog.f90 $ ./a.out
[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 --- 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 --- 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] New: Large stack usage with new gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87352 Bug ID: 87352 Summary: Large stack usage with new gfortran Product: gcc Version: 8.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jeremy at jeremysanders dot net Target Milestone: --- Created attachment 44718 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44718=edit Affected module and example main program With gcc/gfortran 7.3 and 8.2, creation of a variable in the main program with a particular type defined in a module (attached) leads to a segfault due to very large stack usage. This worked on gcc 4.8.4 and earlier versions. In addition compilation of the module creates an object file which is x1 times larger than for earlier gcc versions (200MB vs 25KB). With optimization (-O2), the compilation time is several minutes, rather than less than a second. Instructions for compilation: $ gfortran -ffixed-line-length-none -ffree-line-length-none -g -O2 -o testcomb testcomb.f90 testcomb.f90:1303:0: end module testmodule note: variable tracking size limit exceeded with -fvar-tracking-assignments, retrying without $ ./testcomb $ gdb ./testcomb GNU gdb (Ubuntu 8.1-0ubuntu3) 8.1.0.20180409-git ... (gdb) run Starting program: /home/jsanders/tmp/foo/testcomb Program received signal SIGSEGV, Segmentation fault. testprog () at testcomb.f90:1309 1309 type(instlist_type),target:: instlist It works if the stack is increased to 819200. This problem is seen using Ubuntu Bionic (18.04) on x86-64, using the built-in gcc (7.3.0), or a self-compiled version (8.2.0) with no special build options.
