compiling CP2K at -O1 I get the following ICE: > gfortran -c -O1 -cpp bug.f90 bug.f90: In function ‘qs_ks_build_kohn_sham_matrix’: bug.f90:1392: internal compiler error: Segmentation fault with a trace Program received signal SIGSEGV, Segmentation fault. find_decomposable_subregs (px=<value optimized out>, data=0x7fff4c98757c) at /data03/vondele/gcc_trunk/gcc/gcc/lower-subreg.c:250 250 if (GET_CODE (x) == SUBREG) (gdb) bt #0 find_decomposable_subregs (px=<value optimized out>, data=0x7fff4c98757c) at /data03/vondele/gcc_trunk/gcc/gcc/lower-subreg.c:250 #1 0x00000000006eceb1 in for_each_rtx (x=0x20110060, f=0xb60cf0 <find_decomposable_subregs>, data=0x7fff4c98757c) at /data03/vondele/gcc_trunk/gcc/gcc/rtlanal.c:2827 #2 0x0000000000b61120 in decompose_multiword_subregs () at /data03/vondele/gcc_trunk/gcc/gcc/lower-subreg.c:1119 #3 0x0000000000b61ff9 in rest_of_handle_lower_subreg2 () at /data03/vondele/gcc_trunk/gcc/gcc/lower-subreg.c:1320 #4 0x000000000069c2ad in execute_one_pass (pass=0x10e4d40) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1279 #5 0x000000000069c4f5 in execute_pass_list (pass=0x10e4d40) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1328 #6 0x000000000069c50d in execute_pass_list (pass=0x10dfc00) at /data03/vondele/gcc_trunk/gcc/gcc/passes.c:1329 #7 0x0000000000792ccc in tree_rest_of_compilation (fndecl=0x7f14440fce00) at /data03/vondele/gcc_trunk/gcc/gcc/tree-optimize.c:419 #8 0x00000000009124c4 in cgraph_expand_function (node=0x7f1443c11f00) at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1047 #9 0x0000000000914225 in cgraph_optimize () at /data03/vondele/gcc_trunk/gcc/gcc/cgraphunit.c:1106 #10 0x000000000048db65 in gfc_be_parse_file (set_yydebug=<value optimized out>) at /data03/vondele/gcc_trunk/gcc/gcc/fortran/f95-lang.c:240 #11 0x000000000074357d in toplev_main (argc=<value optimized out>, argv=<value optimized out>) at /data03/vondele/gcc_trunk/gcc/gcc/toplev.c:970 #12 0x00007f1444431436 in __libc_start_main () from /lib64/libc.so.6 #13 0x0000000000402bf9 in _start () I'll be working on a testcase
For gcc version 4.4.0 20090104 (experimental) [trunk revision 143050] (GCC)
testcase: http://www.pci.uzh.ch/vandevondele/tmp/PR38722.tgz untar, and reproduce with gfortran -v -c -O1 -cpp bug.f90 If the module files cause problems, I can try to get to a source file only reproducer.
The ICE only happens at -O1 and not at -O0 or -O2
Can you fill in the "known-to-work" field please, if you think this is a regression?
(In reply to comment #2) > If the module files cause problems, I can try to get to a source file only > reproducer http://www.pci.uzh.ch/vandevondele/tmp/CP2K_2008_12_03.tgz can be used as a source files only testcase, just change in the Makefile FCFLAGS to FCFLAGS = -O1 $(DFLAGS)
Does not fail for me on i686-pc-cygwin with gcc version 4.4.0 20090103 (experimental) [trunk revision 143030]. What target are you compiling for?
(In reply to comment #6) > Does not fail for me on i686-pc-cygwin with gcc version 4.4.0 20090103 > (experimental) [trunk revision 143030]. What target are you compiling for? > Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,fortran --disable-multilib Thread model: posix gcc version 4.4.0 20090104 (experimental) [trunk revision 143050] (GCC) COLLECT_GCC_OPTIONS='-c' '-ffree-form' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH="Linux-x86-64-gfortran"' '-D__COMPILE_DATE="Sat Dec 6 19:17:28 CET 2008"' '-D__COMPILE_HOST="venus"' '-D__COMPILE_LASTCVS="/xray_diffraction.F/1.24/Wed Dec 3 20:49:04 2008//"' '-O1' '-v' '-D__GFORTRAN' '-D__FFTSG' '-D__COMPILE_ARCH="Linux-x86-64-gfortran"' '-D__COMPILE_DATE="Sat Dec 6 19:17:28 CET 2008"' '-D__COMPILE_HOST="venus"' '-D__COMPILE_LASTCVS="/xray_diffraction.F/1.24/Wed Dec 3 20:49:04 2008//"' '-mtune=generic' /data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/f951 qs_ks_methods.F -cpp /tmp/ccoNXrxb.f90 -quiet -v -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH="Linux-x86-64-gfortran" -D__COMPILE_DATE="Sat Dec 6 19:17:28 CET 2008" -D__COMPILE_HOST="venus" -D__COMPILE_LASTCVS="/xray_diffraction.F/1.24/Wed Dec 3 20:49:04 2008//" -D__GFORTRAN -D__FFTSG -D__COMPILE_ARCH="Linux-x86-64-gfortran" -D__COMPILE_DATE="Sat Dec 6 19:17:28 CET 2008" -D__COMPILE_HOST="venus" -D__COMPILE_LASTCVS="/xray_diffraction.F/1.24/Wed Dec 3 20:49:04 2008//" qs_ks_methods.F -quiet -dumpbase qs_ks_methods.F -mtune=generic -auxbase qs_ks_methods -O1 -version -ffree-form -fintrinsic-modules-path /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude -o /tmp/ccCuRhVc.s ignoring nonexistent directory "/data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/finclude /usr/local/include /data03/vondele/gcc_trunk/build/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include /data03/vondele/gcc_trunk/build/lib/gcc/x86_64-unknown-linux-gnu/4.4.0/include-fixed /usr/include End of search list. GNU Fortran (GCC) version 4.4.0 20090104 (experimental) [trunk revision 143050] (x86_64-unknown-linux-gnu) compiled by GNU C version 4.4.0 20090104 (experimental) [trunk revision 143050], GMP version 4.2.2, MPFR version 2.3.1. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 qs_ks_methods.F: In function ‘qs_ks_build_kohn_sham_matrix’: qs_ks_methods.F:1262: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. make: *** [qs_ks_methods.o] Error 1
Revision 143027 is the cause.
Thanks HJ for looking into this. I think revision 143027 is not the cause, it's more likely that it uncovers a latent bug. I'm trying to reduce Joost's code to a small test case. So far, what I'm seeing is that INSN_CODE is wrong on the insn that causes the ICE. So some pass is not properly re-recognizing an insn. The ICE Joost is seeing is happening in lower_subreg2. My test case (reduced with delta) ICEs with in IRA's record_operand_cost because extract_insn is filling recog_data.operands with the wrong information. I'll accept this for now, while I'm investigating.
Created attachment 17031 [details] Failing test case (still needs all the .mod files) This is as far as I can reduce it with delta. Joost, could you please try to "uninclude" the modules that are still USEd? You probably only have to add simplified versions of the modules (e.g. just interfaces and the types).
Note that this test case ICEs in IRA, but I've checked that it ICEs on the same insn, and in both cases we're looking at incorrect recog_data. $ gdb --args ../f951.exe -O t.f90 GNU gdb 6.8.0.20080328-cvs (cygwin-special) Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "i686-pc-cygwin"... (gdb) run Starting program: /home/Steven_Bosscher/devel/build-x86_64/gcc/f951.exe -O t.f90 [New thread 6068.0x1710] [New thread 6068.0x1574] qs_ks_build_kohn_sham_matrix Analyzing compilation unit Performing interprocedural optimizations <visibility> <early_local_cleanups> <summary generate> <inline> <static-var> <pure-const>Assembling functions: qs_ks_build_kohn_sham_matrix Program received signal SIGSEGV, Segmentation fault. 0x00d8c3f6 in record_operand_costs (insn=0x7fd6a690, op_costs=0x10d46d8, allocno_pref=0x0) at ../../trunk/gcc/ira-costs.c:953 953 if (GET_CODE (recog_data.operand[i]) == SUBREG) (gdb) up #1 0x00d8c854 in scan_one_insn (insn=0x7fd6a690) at ../../trunk/gcc/ira-costs.c:1034 1034 record_operand_costs (insn, op_costs, allocno_pref); (gdb) p debug_rtx(insn) (insn 265 200 227 25 t.f90:8 (parallel [ (set (reg:DI 179) (mult:DI (reg:DI 178) (reg:DI 92 [ D.4651 ]))) (clobber (reg:CC 17 flags)) ]) 89 {*movdi_1_rex64} (expr_list:REG_DEAD (reg:DI 178) (expr_list:REG_DEAD (reg:DI 92 [ D.4651 ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))))) $1 = void (gdb) # That is *not* a mov insn (gdb) # Let's reset INSN_CODE, and re-recog it... (gdb) set insn.u.fld[6]=-1 (gdb) set insn.u.fld[6] = recog(insn.u.fld[5],insn,0)(gdb) # ...and suddenly it's a mul insn, as it should be: (gdb) p debug_rtx(insn) (insn 265 200 227 25 t.f90:8 (parallel [ (set (reg:DI 179) (mult:DI (reg:DI 178) (reg:DI 92 [ D.4651 ]))) (clobber (reg:CC 17 flags)) ]) 332 {*muldi3_1_rex64} (expr_list:REG_DEAD (reg:DI 178) (expr_list:REG_DEAD (reg:DI 92 [ D.4651 ]) (expr_list:REG_UNUSED (reg:CC 17 flags) (nil))))) $10 = void
This fixes it for me. However, I'm no RTL expert, and especially combine I know nothing about :-) I'll test/post this and see how the RTL guru's judge it. * combine.c (try_combine): Adjust INSN_CODE after making a valid replacement of an insn's PATTERN. Index: combine.c =================================================================== --- combine.c (revision 143052) +++ combine.c (working copy) @@ -2900,6 +2900,7 @@ try_combine (rtx i3, rtx i2, rtx i1, int *new_dire change to the destination of I3. This requires us to do a few adjustments. */ + INSN_CODE (i3) = insn_code_number; PATTERN (i3) = newpat; adjust_for_new_dest (i3); }
My patch is wrong. The changes are reverted by undo_all() later on. However, the bug still is in combine.c. It should not leave insns with the wrong INSN_CODE.
Leaving this to an RTL expert.
Created attachment 17032 [details] testcase without module dependencies based on Steven's testcase > gfortran -c -O1 reduced.f90 reduced.f90: In function ‘qs_ks_build_kohn_sham_matrix’: reduced.f90:16: internal compiler error: Segmentation fault
Reduced test case - works on i686-pc-linux-gnu for all optimization levels - works with -m32 on x86-64-unknown-linux-gnu - works with 4.3.2
Slightly more reduced: ! PR rtl-optimization/38722 ! { dg-do compile } ! { dg-options "-O1" } SUBROUTINE foo(x, n, ga, gc, vr) TYPE pt DOUBLE PRECISION, DIMENSION (:, :, :), POINTER :: cr END TYPE pt TYPE pu TYPE(pt), POINTER :: pw END TYPE pu LOGICAL, INTENT(in) :: x, ga, gc INTEGER :: i, n LOGICAL :: dd, ep, fe TYPE(pu) :: vr TYPE(pu), DIMENSION(:), POINTER :: v IF (.NOT. fe) THEN IF (ga) THEN CALL bar (dd, ep, gc) END IF IF (x .AND. .NOT. ga) THEN IF (gc) THEN DO i=1,n CALL baz (v(i), x, gc) v(i)%pw%cr = 1.0 END DO DO i=1,n IF (ep) THEN IF (dd) THEN IF (i==1) THEN v(i)%pw%cr=v(i)%pw%cr + vr%pw%cr ENDIF END IF END IF END DO END IF ENDIF END IF END SUBROUTINE foo I'd say the bug is in /* If we will be able to accept this, we have made a change to the destination of I3. This requires us to do a few adjustments. */ PATTERN (i3) = newpat; adjust_for_new_dest (i3); being done before last check that might decide to undo_all (and without recording the changes into undo structures). A patch which just sets a flag and does these 2 stmts if the flag is set after the last undo_all cures this, I'll bootstrap/regtest it soon.
Subject: Bug 38722 Author: jakub Date: Tue Jan 6 20:41:52 2009 New Revision: 143132 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=143132 Log: PR rtl-optimization/38722 * combine.c (try_combine): Don't modify PATTERN (i3) and notes too early, only set a flag and modify after last possible undo_all point. * gfortran.dg/pr38722.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr38722.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/combine.c trunk/gcc/testsuite/ChangeLog
Fixed.