Revision 141067 http://gcc.gnu.org/ml/gcc-cvs/2008-10/msg00270.html breaks bootstrap on Linux/x86: [hjl@gnu-33 libgcc]$ /export/gnu/import/svn/gcc-test/bld/./gcc/xgcc -B/export/gnu/import/svn/gcc-test/bld/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -g -O2 -m32 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../.././gcc -I../../../../src-trunk/libgcc -I../../../../src-trunk/libgcc/. -I../../../../src-trunk/libgcc/../gcc -I../../../../src-trunk/libgcc/../include -I../../../../src-trunk/libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS -DUSE_TLS -o _muldc3.o -MT _muldc3.o -MD -MP -MF _mulsc3.dep -DL_mulsc3 -c ../../../../src-trunk/libgcc/../gcc/libgcc2.c \ > -fvisibility=hidden -DHIDE_EXPORTS ../../../../src-trunk/libgcc/../gcc/libgcc2.c: In function â__mulsc3â: ../../../../src-trunk/libgcc/../gcc/libgcc2.c:1890: 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. [hjl@gnu-33 libgcc]$
Program received signal SIGSEGV, Segmentation fault. 0x000000000063d28e in df_set_bb_dirty (bb=0x0) at ../../src-trunk/gcc/df-core.c:1427 1427 bitmap_set_bit (dflow->out_of_date_transfer_functions, bb->index); (gdb) bt #0 0x000000000063d28e in df_set_bb_dirty (bb=0x0) at ../../src-trunk/gcc/df-core.c:1427 #1 0x0000000000659318 in df_ref_change_reg_with_loc_1 (old_df=0x255ebd8, new_df=0x255ec08, new_regno=3, loc=0x7ffff331cf80) at ../../src-trunk/gcc/df-scan.c:1983 #2 0x0000000000659451 in df_ref_change_reg_with_loc (old_regno=2, new_regno=3, loc=0x7ffff331cf80) at ../../src-trunk/gcc/df-scan.c:2027 #3 0x000000000118e246 in ix86_output_function_epilogue (file=0x249ca40, size=36) at ../../src-trunk/gcc/config/i386/i386.c:8323 #4 0x00000000007188d4 in final_end_function () at ../../src-trunk/gcc/final.c:1636 #5 0x000000000071c5e4 in rest_of_handle_final () at ../../src-trunk/gcc/final.c:4153 #6 0x00000000008e55e6 in execute_one_pass (pass=0x234f0e0) at ../../src-trunk/gcc/passes.c:1279 #7 0x00000000008e5773 in execute_pass_list (pass=0x234f0e0) at ../../src-trunk/gcc/passes.c:1327 #8 0x00000000008e5791 in execute_pass_list (pass=0x23d0780) at ../../src-trunk/gcc/passes.c:1328 #9 0x00000000008e5791 in execute_pass_list (pass=0x23d0720) at ../../src-trunk/gcc/passes.c:1328 #10 0x0000000000c647dc in tree_rest_of_compilation (fndecl=0x7ffff340f600) at ../../src-trunk/gcc/tree-optimize.c:418 ---Type <return> to continue, or q <return> to quit--- #11 0x00000000011f06a2 in cgraph_expand_function (node=0x7ffff2fd9400) at ../../src-trunk/gcc/cgraphunit.c:1038 #12 0x00000000011f0856 in cgraph_expand_all_functions () at ../../src-trunk/gcc/cgraphunit.c:1097 #13 0x00000000011f0de8 in cgraph_optimize () at ../../src-trunk/gcc/cgraphunit.c:1302 #14 0x000000000043524a in c_write_global_declarations () at ../../src-trunk/gcc/c-decl.c:8073 #15 0x0000000000ae761f in compile_file () at ../../src-trunk/gcc/toplev.c:979 #16 0x0000000000ae923d in do_compile () at ../../src-trunk/gcc/toplev.c:2190 #17 0x0000000000ae92a1 in toplev_main (argc=15, argv=0x7fffffffe388) at ../../src-trunk/gcc/toplev.c:2222 #18 0x0000000000509e6b in main (argc=15, argv=0x7fffffffe388) at ../../src-trunk/gcc/main.c:35 (gdb)
This a target specific failure.
Created attachment 16485 [details] possible patch to fix the problem I am pretty sure that this fixes it, but i need to do more testing. kenny
(In reply to comment #3) > Created an attachment (id=16485) [edit] > possible patch to fix the problem > > I am pretty sure that this fixes it, but i need to do more testing. > > kenny > I too had this ICE. The patch seems to make it work nicely.
(In reply to comment #4) > I too had this ICE. The patch seems to make it work nicely. Same thing here on i686-apple-darwin9. The test suite (all languages but ada) passed without regression.
Confirmed, the regression tester sees it too.
I see a failure on sparc-solaris8/10 too. Configury of stage2 fails. Applying the mentioned patch cures compilation. My sparc config is with multilib. 32-bit/64-bit.
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86 andreast at gcc dot gnu dot org wrote: > ------- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31 ------- > I see a failure on sparc-solaris8/10 too. Configury of stage2 fails. > Applying the mentioned patch cures compilation. > My sparc config is with multilib. 32-bit/64-bit. > > > The problem is that the bb is no longer kept in the df-ref, and is instead extracted from the insn. This particular problem was caused by insns being deleted in a pass that defers rescanning but that also changes register numbers. The fix checks to make sure the insn is still in a basic block before trying to mark the block as being dirty. 2008-10-12 Kenneth Zadeck <zadeck@naturalbridge.com> PR middle-end/37808 * df-scan.c (df_ref_change_reg_with_loc_1): Added test to make sure that ref has valid bb. Tested by me on both x86-32 and x86-64. Also tested by andreast on spark-solaris and by keating. OK to commit? kenny Index: df-scan.c =================================================================== --- df-scan.c (revision 141071) +++ df-scan.c (working copy) @@ -1980,7 +1980,8 @@ df_ref_change_reg_with_loc_1 (struct df_ DF_REF_PREV_REG (new_df->reg_chain) = the_ref; new_df->reg_chain = the_ref; new_df->n_refs++; - df_set_bb_dirty (DF_REF_BB (the_ref)); + if (DF_REF_BB (the_ref)) + df_set_bb_dirty (DF_REF_BB (the_ref)); /* Need to sort the record again that the ref was in because the regno is a sorting key. First, find the right
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86 On Sun, Oct 12, 2008 at 11:12 PM, Kenneth Zadeck <zadeck@naturalbridge.com> wrote: > andreast at gcc dot gnu dot org wrote: >> ------- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31 ------- >> I see a failure on sparc-solaris8/10 too. Configury of stage2 fails. >> Applying the mentioned patch cures compilation. >> My sparc config is with multilib. 32-bit/64-bit. >> >> >> > The problem is that the bb is no longer kept in the df-ref, and is > instead extracted from the insn. > This particular problem was caused by insns being deleted in a pass that > defers rescanning but that also changes register numbers. The fix > checks to make sure the insn is still in a basic block before trying to > mark the block as being dirty. Ok. I think it's odd that we keep refs to deleted insns - but that's probably because of the deferred re-scan, right? Thanks, Richard. > 2008-10-12 Kenneth Zadeck <zadeck@naturalbridge.com> > > PR middle-end/37808 > * df-scan.c (df_ref_change_reg_with_loc_1): Added test to make > sure that ref has valid bb. > > Tested by me on both x86-32 and x86-64. Also tested by andreast on > spark-solaris and by keating. > > OK to commit? > > kenny >
Subject: Bug 37808 Author: zadeck Date: Sun Oct 12 21:16:57 2008 New Revision: 141078 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=141078 Log: 2008-10-12 Kenneth Zadeck <zadeck@naturalbridge.com> PR middle-end/37808 * df-scan.c (df_ref_change_reg_with_loc_1): Added test to make sure that ref has valid bb. Modified: trunk/gcc/ChangeLog trunk/gcc/df-scan.c
Subject: Re: [4.4 Regression]: Revision 141067 breaks Linux/x86 Richard Guenther wrote: > On Sun, Oct 12, 2008 at 11:12 PM, Kenneth Zadeck > <zadeck@naturalbridge.com> wrote: > >> andreast at gcc dot gnu dot org wrote: >> >>> ------- Comment #7 from andreast at gcc dot gnu dot org 2008-10-12 20:31 ------- >>> I see a failure on sparc-solaris8/10 too. Configury of stage2 fails. >>> Applying the mentioned patch cures compilation. >>> My sparc config is with multilib. 32-bit/64-bit. >>> >>> >>> >>> >> The problem is that the bb is no longer kept in the df-ref, and is >> instead extracted from the insn. >> This particular problem was caused by insns being deleted in a pass that >> defers rescanning but that also changes register numbers. The fix >> checks to make sure the insn is still in a basic block before trying to >> mark the block as being dirty. >> > > Ok. I think it's odd that we keep refs to deleted insns - but that's probably > because of the deferred re-scan, right? > > Thanks, > Richard. > yes, this only is because of the deferred rescan. committed as revision 14178. kenny > >> 2008-10-12 Kenneth Zadeck <zadeck@naturalbridge.com> >> >> PR middle-end/37808 >> * df-scan.c (df_ref_change_reg_with_loc_1): Added test to make >> sure that ref has valid bb. >> >> Tested by me on both x86-32 and x86-64. Also tested by andreast on >> spark-solaris and by keating. >> >> OK to commit? >> >> kenny >> >>
fixed with the above patch.