[Bug fortran/40011] Problems with -fwhole-file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011 Bug 40011 depends on bug 33097, which changed state. Bug 33097 Summary: Function decl trees without proper argument list https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33097 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #71 from burnus at gcc dot gnu dot org 2010-07-26 09:53 --- Subject: Bug 40011 Author: burnus Date: Mon Jul 26 09:53:19 2010 New Revision: 162531 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162531 Log: Add file forgotten in commit Rev. 162500 2010-07-24 Tobias Burnus bur...@net-b.de PR fortran/40011 * gfortran.dg/whole_file_21.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_21.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #72 from burnus at gcc dot gnu dot org 2010-07-26 13:15 --- (In reply to comment #70) With the patch of PR 40873 comment 18 applied [...] There is now a new patch which fixes tons of issues including the test case of comment 0 number 4, but not the one from comment 47. Are there still remaining issues, and if so which? I think this PR gets too long to have an overview... I only found the one in comment 47: Works -fno-whole-file but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021. I have now filled PR 45077 to track that issue. If you find a new issue - or if there is a left over, which I have missed, please fill a new PR. Thus: Close as FIXED. Thanks to all involved for the bug reporting and fixing! -- burnus at gcc dot gnu dot org changed: What|Removed |Added OtherBugsDependingO|45077 | nThis|| Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #70 from burnus at gcc dot gnu dot org 2010-07-25 10:11 --- Are there still remaining issues, and if so which? I think this PR gets too long to have an overview... I only found the one in comment 47: Works -fno-whole-file but fails otherwise with an ICE in fold_convert_loc, at fold-const.c:2021. With the patch of PR 40873 comment 18 applied, all tests seem to work with -fwhole-program -O3 - except of the comment 47 failure and an additional one for comment 0 test (4) (cf. PR 40873 comment 21) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #61 from jv244 at cam dot ac dot uk 2010-07-24 08:24 --- (In reply to comment #60) it seems possible to retain only the first 60498 lines of all.f90 (till the end of module fft_tools), and add END to get a much smaller testcase... I've started a delta reduction, I believe it is feasible, but could take a while. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #62 from jv244 at cam dot ac dot uk 2010-07-24 11:10 --- a testcase... cat bug.f90 SUBROUTINE fft_3d ( fft_type, fft_in_place, fsign, scale, n, zin, zout ) CALL fftsg3d ( fft_in_place, fsign, scale, n, zin, zout ) END SUBROUTINE fft_3d SUBROUTINE fft_1dm ( fft_type, fsign, trans, n, m, zin, zout, scale ) END SUBROUTINE fft_1dm SUBROUTINE fftsg3d ( fft_in_place, fsign, scale, n, zin, zout ) INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 ) CALL mltfftsg ( 'N', 'T', zin, nx, ny*nz, xf, ny*nz, nx, nx, ny*nz, fsign, 1.0_dp ) END SUBROUTINE fftsg3d SUBROUTINE mltfftsg ( transa, transb, a, ldax, lday, b, ldbx, ldby, n, m, isign, scale ) END SUBROUTINE mltfftsg MODULE fft_tools CONTAINS SUBROUTINE fft3d_s ( fsign, n, zin, zout, scale, status, debug ) CALL fft_3d ( fft_type, fft_in_place, sign, norm, n, zin, zoptr ) END SUBROUTINE fft3d_s SUBROUTINE fft3d_ps ( fsign, n, cin, gin, gs_group, rs_group, yzp, nyzray, bo, scale, status, debug ) CALL fft_1dm ( fft_type, sign, .TRUE., n(3), mx1*my1, pbuf, qbuf, norm ) END SUBROUTINE fft3d_ps END MODULE fft_tools END links with: gfortran-trunk -fno-whole-file bug.f90 fails with: gfortran-trunk -fwhole-file bug.f90 some of the argument mismatches are a result of the reduction, but not all of them, so I guess that is key. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #63 from jv244 at cam dot ac dot uk 2010-07-24 11:14 --- even better testcase... no mismatching arguments: SUBROUTINE fft_3d ( ) CALL fftsg3d () END SUBROUTINE fft_3d SUBROUTINE fft_1dm ( ) END SUBROUTINE fft_1dm SUBROUTINE fftsg3d ( ) CALL mltfftsg ( ) END SUBROUTINE fftsg3d SUBROUTINE mltfftsg ( ) END SUBROUTINE mltfftsg MODULE fft_tools CONTAINS SUBROUTINE fft3d_s ( ) CALL fft_3d ( ) END SUBROUTINE fft3d_s SUBROUTINE fft3d_ps ( ) CALL fft_1dm ( ) END SUBROUTINE fft3d_ps END MODULE fft_tools END -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #64 from burnus at gcc dot gnu dot org 2010-07-24 11:31 --- Reduced a tiny bit more. If one swaps one and two (functions or use) it works - if one swaps both, it fails again. Wild guess: gfortran does not properly walk the tree. Failure with -fwhole-file: /tmp/ccN7F1tB.o: In function `__mod_MOD_four': test.f90:(.text+0x3): undefined reference to `one_' SUBROUTINE one ( ) END SUBROUTINE one SUBROUTINE two ( ) END SUBROUTINE two MODULE mod CONTAINS SUBROUTINE three ( ) CALL two ( ) END SUBROUTINE three SUBROUTINE four ( ) CALL one ( ) END SUBROUTINE four END MODULE mod END -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org AssignedTo|pault at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #65 from burnus at gcc dot gnu dot org 2010-07-24 13:08 ---
(In reply to comment #64)
Failure with -fwhole-file:
/tmp/ccN7F1tB.o: In function `__mod_MOD_four':
test.f90:(.text+0x3): undefined reference to `one_'
If one sets a breakpoint in gfc_create_function_decl,
gfc_generate_function_code, and gfc_get_extern_function_decl one has:
...
gfc_get_extern_function_decl two
--- (1) ---
gfc_generate_function_code two
...
In between those functions calls, the gfc_global_ns_list changes from:
two-one to two-MAIN__.
If I add the following patch, it works with the reduced test case and seems to
also work with the one-file CP2K. I wonder why this problem did not show up
before. It seems to be pretty obvious and not restricted to -fwhole-file
(though, the chance of miscompilation is much increased with -fwhole-file).
Index: parse.c
===
--- parse.c (Revision 162498)
+++ parse.c (Arbeitskopie)
@@ -4414,7 +4414,11 @@
later and all their interfaces resolved. */ gfc_current_ns-code =
s.head;
if (next)
-next-sibling = gfc_current_ns;
+{
+ for (; next-sibling; next = next-sibling)
+ ;
+ next-sibling = gfc_current_ns;
+}
else
gfc_global_ns_list = gfc_current_ns;
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2009-12-09 11:50:57 |2010-07-24 13:08:14
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #66 from rguenther at suse dot de 2010-07-24 13:46 --- Subject: Re: Problems with -fwhole-file On Sat, 24 Jul 2010, burnus at gcc dot gnu dot org wrote: --- Comment #64 from burnus at gcc dot gnu dot org 2010-07-24 11:31 --- Reduced a tiny bit more. If one swaps one and two (functions or use) it works - if one swaps both, it fails again. Wild guess: gfortran does not properly walk the tree. Failure with -fwhole-file: /tmp/ccN7F1tB.o: In function `__mod_MOD_four': test.f90:(.text+0x3): undefined reference to `one_' SUBROUTINE one ( ) END SUBROUTINE one SUBROUTINE two ( ) END SUBROUTINE two MODULE mod CONTAINS SUBROUTINE three ( ) CALL two ( ) END SUBROUTINE three SUBROUTINE four ( ) CALL one ( ) END SUBROUTINE four END MODULE mod END To diagnose these kind of problems look at -fdump-tree-original-uid and/or -fdump-ipa-cgraph. You'll see if the middle-end thinks you have two different entities for one function or variable. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #67 from burnus at gcc dot gnu dot org 2010-07-24 14:08 --- (In reply to comment #66) Failure with -fwhole-file: /tmp/ccN7F1tB.o: In function `__mod_MOD_four': test.f90:(.text+0x3): undefined reference to `one_' To diagnose these kind of problems look at -fdump-tree-original-uid and/or -fdump-ipa-cgraph. You'll see if the middle-end thinks you have two different entities for one function or variable. Thanks for suggestion; I try to remember it for debugging the -fwhole-program issues for which it should be very useful. Though, in this case there is only one UID for one - for the external call. The function itself not even generated without the patch. Thus, the linker error says it all :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #68 from burnus at gcc dot gnu dot org 2010-07-24 16:32 --- Subject: Bug 40011 Author: burnus Date: Sat Jul 24 16:32:11 2010 New Revision: 162500 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162500 Log: 2010-07-24 Tobias Burnus bur...@net-b.de PR fortran/40011 * parse.c (gfc_parse_file): Do not override gfc_global_ns_list items. 2010-07-24 Tobias Burnus bur...@net-b.de PR fortran/40011 * gfortran.dg/whole_file_21.f90: New. * gfortran.dg/integer_exponentiation_3.F90: Use -ffloat-store only for i?86/x86-64 -m32. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/integer_exponentiation_3.F90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #69 from jvdelisle at gcc dot gnu dot org 2010-07-25 01:21 --- Great detective work folks! The sneaky bugs usually are simple to fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #59 from jv244 at cam dot ac dot uk 2010-07-23 22:15 --- I'm trying a recent trunk (162490), and I'm still observing that -fwhole-file causing linking errors. I have no easy testcase, the way to reproduce is: download http://www.pci.unizh.ch/vandevondele/tmp/CP2K_gcc_2007_06.tgz compile and link (takes several minutes about 2Gb RAM) in CP2K_gcc_2007_06/src as: gfortran -fwhole-file -O0 all.f90 -llapack -lblas this leads to undefined references to: /tmp/ccSrltD0.o: In function `__fft_tools_MOD_fft3d_pb': all.f90:(.text+0xb1c61): undefined reference to `fft_1dm_' all.f90:(.text+0xb2824): undefined reference to `fft_1dm_' all.f90:(.text+0xb33f7): undefined reference to `fft_1dm_' all.f90:(.text+0xb4227): undefined reference to `fft_1dm_' all.f90:(.text+0xb4dea): undefined reference to `fft_1dm_' /tmp/ccSrltD0.o:all.f90:(.text+0xb5984): more undefined references to `fft_1dm_' follow /tmp/ccSrltD0.o: In function `mltfftsg_': all.f90:(.text+0xdbb41a): undefined reference to `ctrig_' all.f90:(.text+0xdbb895): undefined reference to `fftpre_' all.f90:(.text+0xdbb95b): undefined reference to `fftstp_' all.f90:(.text+0xdbbd14): undefined reference to `fftstp_' all.f90:(.text+0xdbbe5c): undefined reference to `fftrot_' all.f90:(.text+0xdbbf64): undefined reference to `fftstp_' but goes fine without the '-fwhole-file'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #60 from jv244 at cam dot ac dot uk 2010-07-23 22:55 --- (In reply to comment #59) I have no easy testcase it seems possible to retain only the first 60498 lines of all.f90 (till the end of module fft_tools), and add END to get a much smaller testcase... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #58 from dfranke at gcc dot gnu dot org 2010-07-18 20:49 --- Subject: Bug 40011 Author: dfranke Date: Sun Jul 18 20:49:30 2010 New Revision: 162287 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162287 Log: gcc/fortran/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 * resolve.c (resolve_global_procedure): Improved checking if an explicit interface is required. PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. gcc/testsuite/: 2010-07-18 Daniel Franke franke.dan...@gmail.com Paul Thomas pa...@gcc.gnu.org PR fortran/30668 PR fortran/31346 PR fortran/34260 PR fortran/40011 * gfortran.dg/pr40999.f: Fix function type. * gfortran.dg/whole_file_5.f90: Likewise. * gfortran.dg/whole_file_6.f90: Likewise. * gfortran.dg/whole_file_16.f90: New. * gfortran.dg/whole_file_17.f90: New. * gfortran.dg/whole_file_18.f90: New. * gfortran.dg/whole_file_19.f90: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_16.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_17.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_18.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/resolve.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/pr40999.f branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_5.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/whole_file_6.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #56 from jv244 at cam dot ac dot uk 2010-05-26 13:13 --- (In reply to comment #55) Subject: Bug 40011 Author: pault Date: Wed May 26 05:11:04 2010 New Revision: 159852 I'm still having linking problems with -fwhole-file on the single source file version of CP2K. Will try to get to a testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #57 from dominiq at lps dot ens dot fr 2010-05-26 14:52 ---
Author: pault
Date: Wed May 26 05:11:04 2010
New Revision: 159852
The original code of pr40440 and the reduced test of comment #47 still ICE:
(gdb) run -fwhole-file pr40440_red.f90
Starting program:
/opt/gcc/gcc4.6w/libexec/gcc/x86_64-apple-darwin10.3.0/4.6.0/f951 -fwhole-file
pr40440_red.f90
line_get_string_advance line_init syntax_init_from_ifile
Breakpoint 1, fancy_abort (file=0x1009c1d20 ../../work/gcc/fold-const.c,
line=2042, function=0x100a2b850 fold_convert_loc) at
../../work/gcc/diagnostic.c:787
787 {
(gdb) bt
#0 fancy_abort (file=0x1009c1d20 ../../work/gcc/fold-const.c, line=2042,
function=0x100a2b850 fold_convert_loc) at ../../work/gcc/diagnostic.c:787
#1 0x0001004bb6d1 in fold_convert_loc (loc=0, type=0x141e17930, arg=value
temporarily unavailable, due to optimizations) at
../../work/gcc/fold-const.c:2042
#2 0x0001000cc014 in gfc_trans_scalar_assign (lse=0x7fff5fbfd5f0,
rse=0x7fff5fbfd5a0, ts={type = BT_DERIVED, kind = 0, u = {derived = 0x0, cl =
0x0}, interface = 0x0, is_c_interop = 0, is_iso_c = 0, f90_type = 0},
l_is_temp=0 '\0', r_is_var=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:4836
#3 0x0001000cf844 in gfc_trans_assignment_1 (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5282
#4 0x0001000cfc34 in gfc_trans_assignment (expr1=0x14181e5d0,
expr2=0x14181e750, init_flag=0 '\0', dealloc=1 '\001') at
../../work/gcc/fortran/trans-expr.c:5424
#5 0x0001000aa8e6 in trans_code (code=0x14181e810, cond=0x0) at
../../work/gcc/fortran/trans.c:1082
#6 0x0001000c769f in gfc_generate_function_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans-decl.c:4483
#7 0x0001000aad0b in gfc_generate_module_code (ns=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/trans.c:1392
#8 0x00010006cd0f in gfc_parse_file () at
../../work/gcc/fortran/parse.c:4287
#9 0x0001000a586c in gfc_be_parse_file (set_yydebug=value temporarily
unavailable, due to optimizations) at ../../work/gcc/fortran/f95-lang.c:239
#10 0x0001006dc789 in toplev_main (argc=3, argv=0x7fff5fbfdad0) at
../../work/gcc/toplev.c:1049
#11 0x00011094 in start ()
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #55 from pault at gcc dot gnu dot org 2010-05-26 05:11 --- Subject: Bug 40011 Author: pault Date: Wed May 26 05:11:04 2010 New Revision: 159852 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159852 Log: 2010-05-26 Paul Thomas pa...@gcc.gnu.org PR fortran/40011 * resolve.c (resolve_global_procedure): Resolve the gsymbol's namespace before trying to reorder the gsymbols. 2010-05-26 Paul Thomas pa...@gcc.gnu.org PR fortran/40011 * gfortran.dg/whole_file_19.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_19.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #53 from jv244 at cam dot ac dot uk 2010-05-03 10:57 --- testcase in comment #40 now works. Comment #42 still fails. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #54 from jvdelisle at gcc dot gnu dot org 2010-05-03 19:24 --- We should get the case in comment 40 added to the test suite if not already so we do not regress it later. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #51 from jv244 at cam dot ac dot uk 2009-12-09 11:50 --- still failing with current trunk, also leading to miscomples (see PR38913). As a consequence, should one disable -fwhole-file (and consequently -flto) for Fortran before release? -- jv244 at cam dot ac dot uk changed: What|Removed |Added Last reconfirmed|2009-05-04 09:10:10 |2009-12-09 11:50:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #52 from rguenther at suse dot de 2009-12-09 11:52 --- Subject: Re: Problems with -fwhole-file On Wed, 9 Dec 2009, jv244 at cam dot ac dot uk wrote: --- Comment #51 from jv244 at cam dot ac dot uk 2009-12-09 11:50 --- still failing with current trunk, also leading to miscomples (see PR38913). As a consequence, should one disable -fwhole-file (and consequently -flto) for Fortran before release? As neither is enabled by default I instead recommend to document the experimental status instead. Note that -flto works around most of the frontend issues by performing its own type and decl unification. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #50 from jv244 at cam dot ac dot uk 2009-10-11 12:45 --- As expected, the testcases in comment #40 and comment #42 now also fail at '-O2 -flto' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #47 from dominiq at lps dot ens dot fr 2009-08-26 10:32 --- Created an attachment (id=18427) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18427action=view) Self contained reduced test for pr40440 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #48 from dominiq at lps dot ens dot fr 2009-08-26 10:34 --- are there issues other than the ones reported in comment #44 I have opened pr41056 and pr41059 for other problems. There are ICEs for the original test in pr40440 (with external iso_varying_string.mod, but not if iso_varying_string.f95 is included) and a self contained reduced test I have posted on the mailing list and I am attaching. Also the test in comment #5 of pr40737 gives an ICE: [ibook-dhum] f90/bug% gfc -fwhole-file pr40737.f90 pr40737.f90: In function 'tf_ad_splitting_driver_plane': pr40737.f90:11:0: internal compiler error: Bus error On the positive side -fwhole-file fixes some ICE after errors as in pr37744 (with both .FALSE._C_BOOL and .FALSE.) and pr40994.f90. Finally the last time -fwhole-file was the default, -fno-whole-file, it was not working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #49 from dominiq at lps dot ens dot fr 2009-08-26 10:35 --- Finally the last time -fwhole-file was the default, -fno-whole-file, it was not working. Please read: Finally the last time -fwhole-file was the default, -fno-whole-file was not working. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #44 from jv244 at cam dot ac dot uk 2009-08-03 10:12 --- Just for completeness, current trunk still fails on the testcases in comment #40 and comment #42. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #43 from pault at gcc dot gnu dot org 2009-08-01 13:45 --- Subject: Bug 40011 Author: pault Date: Sat Aug 1 13:45:12 2009 New Revision: 150333 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=150333 Log: 2009-08-01 Paul Thomas pa...@gcc.gnu.org PR fortran/40011 * error.c : Add static flag 'warnings_not_errors'. (gfc_error): If 'warnings_not_errors' is set, branch to code from gfc_warning. (gfc_clear_error): Reset 'warnings_not_errors'. (gfc_errors_to_warnings): New function. * options.c (gfc_post_options): If pedantic and flag_whole_file change the latter to a value of 2. * parse.c (parse_module): Add module namespace to gsymbol. (resolve_all_program_units): New function. (clean_up_modules): New function. (translate_all_program_units): New function. (gfc_parse_file): If whole_file, do not clean up module right away and add derived types to namespace derived types. In addition, call the three new functions above. * resolve.c (not_in_recursive): New function. (not_entry_self_reference): New function. (resolve_global_procedure): Symbol must not be IFSRC_UNKNOWN, procedure must not be in the course of being resolved and must return false for the two new functions. Pack away the current derived type list before calling gfc_resolve for the gsymbol namespace. It is unconditionally an error if the ranks of the reference and ther procedure do not match. Convert errors to warnings during call to gfc_procedure_use if not pedantic or legacy. (gfc_resolve): Set namespace resolved flag to -1 during resolution and store current cs_base. * trans-decl.c (gfc_get_symbol_decl): If whole_file compilation substitute a use associated variable, if it is available in a gsymbolnamespace. (gfc_get_extern_function_decl): If the procedure is use assoc, do not attempt to find it in a gsymbol because it could be an interface. If the symbol exists in a module namespace, return its backend_decl. * trans-expr.c (gfc_trans_scalar_assign): If a derived type assignment, set the rhs TYPE_MAIN_VARIANT to that of the rhs. * trans-types.c (copy_dt_decls_ifequal): Add 'from_gsym' as a boolean argument. Copy component backend_decls directly if the components are derived types and from_gsym is true. (gfc_get_derived_type): If whole_file copy the derived type from the module if it is use associated, otherwise, if can be found in another gsymbol namespace, use the existing derived type as the TYPE_CANONICAL and build normally. * gfortran.h : Add derived_types and resolved fields to gfc_namespace. Include prototype for gfc_errors_to_warnings. 2009-08-01 Paul Thomas pa...@gcc.gnu.org PR fortran/40011 * gfortran.dg/whole_file_7.f90: New test. * gfortran.dg/whole_file_8.f90: New test. * gfortran.dg/whole_file_9.f90: New test. * gfortran.dg/whole_file_10.f90: New test. * gfortran.dg/whole_file_11.f90: New test. * gfortran.dg/whole_file_12.f90: New test. * gfortran.dg/whole_file_13.f90: New test. * gfortran.dg/whole_file_14.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/whole_file_10.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_11.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_12.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_13.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_14.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_7.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_8.f90 trunk/gcc/testsuite/gfortran.dg/whole_file_9.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/error.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/options.c trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #42 from jv244 at cam dot ac dot uk 2009-07-28 07:37 --- another issue I found is this: gfortran -fwhole-file test.f90 /tmp/cciOiaMB.o: In function `__m_MOD_b': test.f90:(.text+0xa): undefined reference to `c_' collect2: ld returned 1 exit status cat test.f90 SUBROUTINE c() CALL a() END SUBROUTINE c SUBROUTINE a() END SUBROUTINE a MODULE M CONTAINS SUBROUTINE b() CALL c() END SUBROUTINE END MODULE USE M CALL b() END things link fine if I swap the order of definition of the subroutines 'a' and 'c' it is similar to PR40873, but happens with just -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-07-26 21:23 --- 3323 gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE 3324 || TYPE_CONTEXT (decl) == sym-ns-proc_name-backend_decl); 3325 gcc_assert (DECL_CONTEXT (TYPE_STUB_DECL (decl)) == NULL_TREE 3326 || DECL_CONTEXT (TYPE_STUB_DECL (decl)) 3327 == sym-ns-proc_name-backend_decl); if the second assert isn't bogus then both types (the one in the replica_type module and the imported one) have to have separate type-stub-decls (thus two debug information entries). Personally I think it is quite reasonable to use the replica_type modules debug info for the USE imported one, thus simply remove the 2nd assert. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #40 from jv244 at cam dot ac dot uk 2009-07-25 16:53 --- (In reply to comment #38) Too large, not reducing. since you were so kind fixing PR40005, I felt some obligation ;-) MODULE replica_types TYPE replica_env_type END TYPE replica_env_type CONTAINS SUBROUTINE rep_env_create(rep_env, para_env, input, nrep, prep, sync_v,keep_wf_history,row_force) END SUBROUTINE rep_env_create SUBROUTINE rep_envs_add_rep_env(rep_env) TYPE(replica_env_type), POINTER :: rep_env END SUBROUTINE rep_envs_add_rep_env END MODULE replica_types MODULE ep_types USE replica_types TYPE ep_env_type TYPE(replica_env_type), POINTER :: mol_envs END TYPE ep_env_type TYPE ep_env_p_type TYPE(ep_env_type), POINTER :: ep_env END TYPE ep_env_p_type TYPE(ep_env_p_type), DIMENSION(:), POINTER :: ep_envs CONTAINS SUBROUTINE ep_force_release() END SUBROUTINE ep_force_release END MODULE ep_types bug.f90:7:0: internal compiler error: in gfc_create_module_variable, at fortran/trans-decl.c:3328 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #36 from rguenth at gcc dot gnu dot org 2009-07-24 10:24 --- With the newest whole-file patch I instead get #1 0x087a1c89 in tree_check_failed (node=0xb6e9fcb0, file=0x8b9d398 /home/richard/src/trunk/gcc/fortran/trans-types.c, line=2010, function=0x8b9da9d gfc_get_derived_type) at /home/richard/src/trunk/gcc/tree.c:7460 7460 internal_error (tree check: %s, have %s in %s, at %s:%d, (gdb) #2 0x081e2850 in gfc_get_derived_type (derived=0x136519f0) at /home/richard/src/trunk/gcc/fortran/trans-types.c:2010 2010 if (TYPE_FIELDS (derived-backend_decl)) with derived-backend_decl looking like random crap. (in fact it seems to be GC collected memory, all 0xa5a5a5a5). All of gfortran.h seems to be ignorant of the GC - which means we may not garbage collect while the FE is still running, so all calls to cgraph_finalize_function should have true as their 2nd argument. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #37 from rguenth at gcc dot gnu dot org 2009-07-24 10:27 --- We then get to the next ICE ... (gdb) up #1 0x0819bfaa in gfc_create_module_variable (sym=0x22cb3750) at /home/richard/src/trunk/gcc/fortran/trans-decl.c:3327 3327 gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE (gdb) l 3327 gcc_assert (TYPE_CONTEXT (decl) == NULL_TREE 3328 || TYPE_CONTEXT (decl) == sym-ns-proc_name-backend_decl); context namespace_decl 0xb7665cb0 global_types vs. namespace_decl 0xad5080e0 ep_types type void_type 0xb7ccb9a0 void VOID align 8 symtab 0 alias set -1 canonical type 0xb7ccb9a0 pointer_to_this pointer_type 0xb7ccba10 VOID file CP2K_2009-05-01.f90 line 332958 col 0 align 1 I'll reduce that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #38 from rguenth at gcc dot gnu dot org 2009-07-24 10:56 --- Too large, not reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #39 from jv244 at cam dot ac dot uk 2009-07-24 11:29 --- (In reply to comment #36) All of gfortran.h seems to be ignorant of the GC - which means we may not garbage collect while the FE is still running, so all calls to cgraph_finalize_function should have true as their 2nd argument. I wonder if this is the reason for PR40005 ?? since it garbage collector seems to run from within the frontend in that case: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005#c10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #34 from jv244 at cam dot ac dot uk 2009-07-24 05:39 --- Testing paul's latest patch at http://gcc.gnu.org/ml/fortran/2009-07/msg00202.html on the latest all file CP2K (see also PR40005) http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2009-05-01.f90.gz I get the following ICE for ulimit -s 512000 gfortran -c -O2 -march=native -fwhole-file CP2K_2009-05-01.f90 CP2K_2009-05-01.f90: In function broadcast_input_information: CP2K_2009-05-01.f90:53523:0: internal compiler error: tree check: expected record_type or union_type or qual_union_type, have H#65533;#65533;H#62020;$@ in gfc_get_derived_type, at fortran/trans-types.c:2010 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. I won't be able to reduce this failure for the next 10 days or so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #35 from jv244 at cam dot ac dot uk 2009-07-24 05:48 --- (In reply to comment #34) I won't be able to reduce this failure for the next 10 days or so. as a PS, the multiple-file compilation of trunk cp2k goes fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #33 from rguenth at gcc dot gnu dot org 2009-06-14 16:58 --- I am willing to help with analyzing/fixing middle-end problems with -fwhole-file, but it would be nice to have some of the progression pieces in trunk to do so ;) That said - I'm currently trying to hook up LTO for gfortran, which does seem to work for a simple two-file hello world. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #31 from dominiq at lps dot ens dot fr 2009-06-02 09:29 --- With the patch in comment #28, I have a dozen new ICEs in my test suite. They seems to be in two classes: [ibook-dhum] f90/bug% cat pr33295.f90 module A type A_type real comp end type end module A module B contains function initA() use A implicit none type(A_type):: initA initA%comp=1.0 end function end module B program C use B use A implicit none type(A_type):: A_var A_var = initA() end program C [ibook-dhum] f90/bug% gfc pr33295.f90 pr33295.f90: In function 'c': pr33295.f90:24: internal compiler error: in fold_convert, at fold-const.c:2687 and [ibook-dhum] f90/bug% cat test_point.f90 module global type:: mytype type(mytype),pointer :: this end type mytype type(mytype),target:: base end module global program test_equi use global call check() print *, base%this%this=base? , associated(base%this%this,base) print *, base%this%this=? , associated(base%this%this) print *, base%this=? , associated(base%this) contains subroutine check() type(mytype),target:: j base%this = j !have the variables point j%this = base !to one another end subroutine check !take j out of scope end program test_equi [ibook-dhum] f90/bug% gfc test_point.f90 gfc: Internal error: Segmentation fault (program f951) Concerning gfortran.dg/default_initialization_3.f90, I cannot say if the problem is with the front-end or the middle-end, but it is certainly tricky to do the correct inlining. I think the problem should go to another pr. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #32 from dominiq at lps dot ens dot fr 2009-06-02 12:32 --- I think the following code: function CHECK_INTEGER4_RANK1 (EXPECTED, COMPUTED) integer(4), intent(in), dimension(:) :: EXPECTED integer(4), intent(in), dimension(:) :: COMPUTED logical :: CHECK_INTEGER4_RANK1 CHECK_INTEGER4_RANK1 = all(COMPUTED == EXPECTED) end function CHECK_INTEGER4_RANK1 program array_test !use CHECK_SEM logical :: CHECK_INTEGER4_RANK1 integer,dimension(-1:1,-1:1) :: mis1=1.1 logical,dimension(-1:1,-1:1) :: ml2=.true. logical :: res integer, dimension(3) :: theo, dat theo = sum(mis1,dim=1,mask=ml2) dat = (/8,5,12/) res = CHECK_INTEGER4_RANK1 (theo, dat) end program array_test should give an error about missing interface with -fwhole-file (it does not with the patch in comment #28). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #28 from pault at gcc dot gnu dot org 2009-06-01 18:00 --- Created an attachment (id=17942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) A progression of -fwhole-file This patch is as far as I have got. It incorporates module procedures and this is where I have run into problems. I have posted an appeal for help on the list. It should be noted that -fwhole-file is fixed to be on all the time in parse.c so that the regtesting goes correctly. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #29 from jv244 at cam dot ac dot uk 2009-06-01 19:34 --- (In reply to comment #28) Created an attachment (id=17942) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17942action=view) [edit] A progression of -fwhole-file This patch is as far as I have got. this seems to have some memory problem somewhere, compiling the normal version of cp2k (i.e. one module per file), at least 10Gb of memory is needed in several cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #30 from jv244 at cam dot ac dot uk 2009-06-01 19:43 --- Created an attachment (id=17944) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17944action=view) testcase attached is a testcase, this actually causes a segfault outside of the build infrastructure, but consumes XGb within: gfortran -v -ffree-form btree_i8_k_i4_v.F (gdb) bt #0 0x7ffe74a0efb0 in strcmp () from /lib64/libc.so.6 #1 0x0051bcbd in gfc_find_symtree (st=0x13f4460, name=0x7ffe741dba90 btree_node_p) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2306 #2 0x0051bedb in gfc_find_sym_tree (name=0x7ffe741dba90 btree_node_p, ns=0x132b490, parent_flag=0, result=0x7fff7d54e068) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2466 #3 0x0051bf82 in gfc_find_symbol (name=0x7ffe741dba90 btree_node_p, ns=0x7ffe741dbbd0, parent_flag=0, result=0x7fff7d54e098) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/symbol.c:2502 #4 0x005724dd in gfc_get_derived_type (derived=0x13309f0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1945 #5 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #6 0x00572506 in gfc_get_derived_type (derived=0x132fc30) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 #7 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #8 0x00572506 in gfc_get_derived_type (derived=0x13309f0) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 #9 0x00572861 in copy_dt_decls_ifequal (from=value optimized out, to=value optimized out, from_gsym=value optimized out) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1864 #10 0x00572506 in gfc_get_derived_type (derived=0x132fc30) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/trans-types.c:1948 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #27 from pault at gcc dot gnu dot org 2009-05-30 08:27 --- (In reply to comment #25) types that are identical I'm not sure this is related, but note comment #8. Even identical types are not identical, unless they are sequence type. Joost, No, this is not related. The testing in the front end is more or less OK. However, the compiler receives more than one delaration of derived types, either through explicit declaration, host association or use assocation. The middle-end has to ensure that the same backend_decl is used for each. Otherwise, when one is assigned to the other, via a defined assignement, it is found that the TREE_TYPEs are not the same. I have been trying to move the backend_decls up to global scope so as to ensure that this happens but I am missing some essential trick somewhere. I'll be asking the experts next week :-) Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #24 from pault at gcc dot gnu dot org 2009-05-29 15:33 --- (In reply to comment #23) I've added a 'related' PR40275 on -combine not working for Fortran. I think that as soon as the -fwhole-file patch is added (default or not yet ;-) there would be interest in -combine doing the right thing. Just to let you all know the state of progress with the -fwhole-file work: (i) I think that I have fixes for all the problems here up to and including comment #17. (ii) I have now added code to incorporate modules into the scheme. (iii) If a patch that includes (i) and (ii) is made default, I see 168 regressions. Many are correct failures or legacy issues (eg hollerith to integer), and one or two ICEs have already been fixed. However, there are some problems involving ICEs dues to different backend_decls being used for derived types that are identical and one or two runtime failures that come in at )1 or O2. I cannot pick this up again until next week but I am going at it as fast as possible. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #25 from jv244 at cam dot ac dot uk 2009-05-29 16:34 --- (In reply to comment #24) However, there are some problems involving ICEs dues to different backend_decls being used for derived types that are identical I'm not sure this is related, but note comment #8. Even identical types are not identical, unless they are sequence type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #26 from burnus at gcc dot gnu dot org 2009-05-29 18:42 --- Even identical types are not identical, unless they are sequence type. ... or BIND(C) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #21 from burnus at gcc dot gnu dot org 2009-05-27 13:02 --- Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for invalid program with -fwhole-file). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #22 from dominiq at lps dot ens dot fr 2009-05-27 14:05 --- (In reply to comment #21) Regarding -fwhole-file issues, see also PR 40176 comment 5 (endless loop for invalid program with -fwhole-file). My post in PR 40176 #5 was ambiguous: the infinite loop does not need the -fwhole-file flag. I only wanted to say that I was using a clean tree+ the patch from http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #23 from jv244 at cam dot ac dot uk 2009-05-27 17:51 --- I've added a 'related' PR40275 on -combine not working for Fortran. I think that as soon as the -fwhole-file patch is added (default or not yet ;-) there would be interest in -combine doing the right thing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #20 from jv244 at cam dot ac dot uk 2009-05-25 06:13 --- (In reply to comment #19) It's good news that cp2k is now OK - did the performance improve? I didn't check that, I suspect that, since everything is module based, it needs the stuff for module procedure inlining first. Right now, trunk seems broken (PR40240) and I'm busy (PR00042) so there is no need to hurry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #19 from pault at gcc dot gnu dot org 2009-05-22 13:40 --- (In reply to comment #18) the patch posted here: http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html allows cp2k in its single source file form, 640klines as made available in PR40005, to compile with -fwhole-file (using the ulimit -s unlimited trick). Even the 3Gb memory usage seems reasonable. What about turning this option on by default now ? The warnings its generates are generally useful, and there is the potential gain in performance. I have just fixed the problem flagged up in comment #17, have cleaned up the code somewhat and am just turning my attention to module procedures. I expect to get the whole lot sorted in another day or so. As to the options for its use, I need to check out where we are with the testsuite. As you are aware, there are a number of problems there that I will have to turn to next. My inclination is to get the patch to full functionality but to leave it as an experiment for just a little while longer. It's good news that cp2k is now OK - did the performance improve? Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #18 from jv244 at cam dot ac dot uk 2009-05-17 05:11 --- the patch posted here: http://gcc.gnu.org/ml/fortran/2009-05/msg00244.html allows cp2k in its single source file form, 640klines as made available in PR40005, to compile with -fwhole-file (using the ulimit -s unlimited trick). Even the 3Gb memory usage seems reasonable. What about turning this option on by default now ? The warnings its generates are generally useful, and there is the potential gain in performance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #17 from dominiq at lps dot ens dot fr 2009-05-08 14:09 --- Thanks to the second program in http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/c6621b97f448b516# I think I have found a false positive for -fwhole-file (unpatched): Implicit None Interface Subroutine sub( a, b, c ) Implicit None Integer, Intent( In ) :: a Integer, Intent( In ) :: b Integer, Intent( In ), Optional :: c End Subroutine sub End Interface call sub(1,2) call sub(1,2,3) end subroutine sub(i,j,k) Implicit None Integer, Intent( In ) :: i Integer, Intent( In ) :: j Integer, Intent( In ), Optional :: k intrinsic present write(*,*)' 3 presence flag ',present(k) write(*,*)' 1st arg ',i write(*,*)' 2nd arg ',j if (present(k)) then write(*,*)' 3rd arg ',k else write(*,*)' 3rd arg is absent' endif return end [ibook-dhum] f90/bug% gfc -fwhole-file no_interface_1.f90 no_interface_1.f90:10.24: call sub(1,2) 1 Error: Unexpected alternate return spec in subroutine call at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #15 from dfranke at gcc dot gnu dot org 2009-05-07 18:00 --- There's a new ICE with -fwhole-file that crept in since yesterday (20090505, using the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html). I'll try to get a reduced testcase. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-05-07 18:34 --- $ cat ice.f90 MODULE module_foo TYPE :: foo_node TYPE(foo_node_private), POINTER :: p END TYPE TYPE :: foo_node_private TYPE(foo_node), DIMENSION(-1:1) :: link END TYPE TYPE :: foo TYPE(foo_node) :: root END TYPE END MODULE FUNCTION foo_insert() USE module_foo, ONLY: foo, foo_node INTEGER :: foo_insert TYPE(foo_node) :: parent, current INTEGER :: cmp parent = current current = current%p%link(cmp) END FUNCTION FUNCTION foo_count() USE module_foo, ONLY: foo INTEGER :: foo_count END FUNCTION $ gfortran-svn -fwhole-file ice.f90 ice.f90: In function 'foo_insert': ice.f90:22: internal compiler error: in fold_convert, at fold-const.c:2670 where fold-const.c:2670 is gcc_unreachable(). Adding Janus as CC as his patch has a high likelihood of being involved. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #9 from dominiq at lps dot ens dot fr 2009-05-05 07:04 --- Created an attachment (id=17802) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17802action=view) Full summary for the tests with -fwhole-file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #10 from dominiq at lps dot ens dot fr 2009-05-05 07:05 --- After filtering the useless warning with a line regsub -all (^|\n)cc1: warning: command line option .-fwhole-file. is valid for Fortran but not for C $text text gcc/testsuite/lib/prune.expI get: === gfortran Summary === # of expected passes118146 # of unexpected failures144 # of expected failures 78 # of unsupported tests 906 I attached a full summary. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #11 from dominiq at lps dot ens dot fr 2009-05-05 11:33 --- The summary of the attached file in comment #9 is: FAIL: gfortran.dg/bounds_check_strlen_1.f90 -O0 (test for excess errors) FAIL: gfortran.dg/bounds_temporaries_1.f90 -O (test for excess errors) FAIL: gfortran.dg/contained_3.f90 -O0 execution test FAIL: gfortran.dg/entry_17.f90 -O (test for warnings, line 27) FAIL: gfortran.dg/func_decl_4.f90 -O (test for errors, line 7) FAIL: gfortran.dg/generic_actual_arg.f90 -O (test for excess errors) FAIL: gfortran.dg/global_references_1.f90 -O (test for errors, line 39) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) FAIL: gfortran.dg/hollerith_legacy.f90 -O (test for warnings, line 24) FAIL: gfortran.dg/import6.f90 -O (test for excess errors) FAIL: gfortran.dg/integer_exponentiation_2.f90 -O0 (test for excess errors) FAIL: gfortran.dg/intrinsic_actual_1.f -O (test for excess errors) FAIL: gfortran.dg/intrinsic_std_1.f90 -O scan-tree-dump original abort : dump file does not exist FAIL: gfortran.dg/pr20865.f90 -O (test for excess errors) FAIL: gfortran.dg/pr37243.f -O0 (test for excess errors) FAIL: gfortran.dg/sizeof.f90 -O0 (test for excess errors) FAIL: gfortran.dg/used_before_typed_4.f90 -O (test for excess errors) FAIL: gfortran.dg/g77/970625-2.f -O (test for excess errors) and with -m64 FAIL: gfortran.dg/loc_1.f90 -O1 (test for excess errors) With the patch in comment #8 of pr40006, the following failures are changed: FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) FAIL: gfortran.dg/hollerith_legacy.f90 -O (test for excess errors) FAIL: gfortran.dg/integer_exponentiation_2.f90 -O0 (test for excess errors) without patch === gfortran Summary for unix//-fwhole-file === # of expected passes28733 # of unexpected failures68 # of expected failures 16 # of unsupported tests 397 with patch === gfortran Summary === # of expected passes28751 # of unexpected failures66 # of expected failures 16 # of unsupported tests 397 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #12 from dominiq at lps dot ens dot fr 2009-05-05 15:57 --- Reduced test for gfortran.dg/contained_3.f90: [ibook-dhum] f90/bug% cat contained_3_red.f90 MODULE ksbin1_aux_mod CONTAINS FUNCTION binden() INTEGER :: binden INTEGER :: setbd binden = 0 ENTRY setbd() setbd = 99 END FUNCTION binden END MODULE ksbin1_aux_mod PROGRAM test integer setbd ! setbd is external, since not use assoc. print *, setbd () if (setbd () .ne. 42 ) call abort () call foo contains subroutine foo USE ksbin1_aux_mod ! module setbd is available print *, setbd () if (setbd () .ne. 99 ) call abort () end subroutine END PROGRAM test INTEGER FUNCTION setbd() setbd=42 END FUNCTION setbd [ibook-dhum] f90/bug% gfc contained_3_red.f90 [ibook-dhum] f90/bug% a.out 42 99 [ibook-dhum] f90/bug% gfc -fwhole-file contained_3_red.f90 [ibook-dhum] f90/bug% a.out 42 42 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #13 from pault at gcc dot gnu dot org 2009-05-05 18:12 --- (In reply to comment #12) ...snip... [ibook-dhum] f90/bug% a.out 42 42 Abort This turns out to be the same bug as that which caused the segfault in gas_dyn.f90. Use associated procedures need to be excluded from the part of the patch in trans-decl.c. Once this is done, the whole polyhedron suite compiles and runs at any level of optimization. The updated patch is regtesting right now. It still needs module procedures to be incorporated but it is nearly there. I have been thinking hard about type cheating - I am likely to allow it for std-f77 and legacy, to warn with other standards and fail with -pedantic. However, I am open to better proposals. I have not checked yet whether type cheating references to a procedure need a double declaration or not (ie. to avoid typing troubles in the back end). Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #14 from jv244 at cam dot ac dot uk 2009-05-05 19:28 --- (In reply to comment #13) I have been thinking hard about type cheating - I am likely to allow it for std-f77 and legacy, to warn with other standards and fail with -pedantic. this sounds reasonable. Note the other testcases in PR40006 that cheat somewhat beyond the 'type', I think they should be treated on the same footing. Note that type cheating and the like should only be allowed for calls that involve procedures with an implicit interface, it should still be a hard error if there is an explicit interface. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #1 from pault at gcc dot gnu dot org 2009-05-04 09:10 --- Dominique, Thanks for setting this up. I'll poll everybody involved for contributions and have assigned myself the bug(s). Cheers Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-04 09:10:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #2 from pault at gcc dot gnu dot org 2009-05-04 09:29 --- see PR40006: allow type cheating for procedures with an implicit interface -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||40006 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #3 from pault at gcc dot gnu dot org 2009-05-04 09:31 --- ...and PR39896 : ICE with -fwhole-file -- pault at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39896 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #4 from dominiq at lps dot ens dot fr 2009-05-04 17:54 --- With thee patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html without type cheating, all the ICEs in my tests are gone. It even fixes pr37744!-(it may give a clue on how to fix it without -fwhole-file). For the test arr_fun.f90, I now get: arr_fun.f90:10.6: res = test(2) 1 Error: The reference to function 'test' at (1) either needs an explicit INTERFACE or the rank is incorrect which seems right (without -fwhole-file I get a bus error at run time). Test gcc/testsuite/gfortran.dg/hollerith.f90 and friends won't probably pass regtesting: call test (8h hello) 1 Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8) I have to run the polyhedron tests and to regtest, so it is all for this time. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #5 from dominiq at lps dot ens dot fr 2009-05-04 21:52 --- With the patch in http://gcc.gnu.org/ml/fortran/2009-05/msg00056.html gas_dyn.f90 fails as in commet #0, except for -O1: [ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90 gas_dyn.f90: In function 'chozdt': gas_dyn.f90:216: internal compiler error: Bus error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #6 from dominiq at lps dot ens dot fr 2009-05-04 22:20 ---
Regtest gives:
=== gfortran Summary ===
# of expected passes117714
# of unexpected failures576
# of expected failures 78
# of unsupported tests 906
for RUNTESTFLAGS=--target_board=unix'{,-m64,/-fwhole-file,-m64/-fwhole-file}'
with no unexpected failures for {,-m64}. 444 failures come from
cc1: warning: command line option -fwhole-file is valid for Fortran but not
for C
I think I know how to filter them.
--- generic_actual_arg.f90 fails with
/opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/generic_actual_arg.f90:40.64:
CALL F(CALCULATION2) ! OK because there is a same name specific
1
Error: More actual than formal arguments in procedure call at (1)
False positive?
--- global_references_1.f90 fails with
SUBROUTINE j (x)! { dg-error is already being used as a FUNCTION }
2
Error: Global name 'j' at (1) is already being used as a SUBROUTINE at (2)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:39.6:
T = j () ! { dg-error is already being used as a FUNCTION }
1
Error: Missing actual argument for argument 'x' at (1)
/opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/global_references_1.f90:68.64:
--- hollerith.f90 fails with
call test (8h hello)
1
Error: Type mismatch in argument 'h' at (1); passed HOLLERITH to INTEGER(8)
--- hollerith_legacy.f90 same failure
--- import6.f90 fails with
opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13:
call func1(x)
1
Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to
TYPE(my_type)
Obviously some tests will require adjustments to pass with -fwhole-file.
More tomorrow.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #7 from dominiq at lps dot ens dot fr 2009-05-04 22:44 --- Also gfortran.dg/contained_3.f90 is miscompiled with -fwhole-file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
[Bug fortran/40011] Problems with -fwhole-file
--- Comment #8 from jv244 at cam dot ac dot uk 2009-05-05 04:18 --- (In reply to comment #6) opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/import6.f90:42.13: call func1(x) 1 Error: Type mismatch in argument 'param' at (1); passed TYPE(my_type) to TYPE(my_type) that's a proper error as well, TYPE(my_type) needs to have the SEQUENCE attribute for this to be correct -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40011
