[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #72 from hjl at gcc dot gnu.org hjl at gcc dot gnu.org --- Author: hjl Date: Tue Nov 25 21:07:43 2014 New Revision: 218062 URL: https://gcc.gnu.org/viewcvs?rev=218062root=gccview=rev Log: Add a testcase for PR target/63534 PR target/63534 * gcc.target/i386/pr63534.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63534.c Modified: trunk/gcc/testsuite/ChangeLog
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #71 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- Actually closing.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #70 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #69) Apart from comment #69 (which I am not sure is related to the issue), the rest of the PR seems now fixed by the various commits here, as well as the fix for PR63845. I am thus closing here. Other issues should be reported separately, because this has become such a monster thread.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added CC||fxcoudert at gcc dot gnu.org --- Comment #66 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #52) Igor, can you post the patch from c#50 for official review? Thanks! ping?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #67 from Igor Zamyatin izamyatin at gmail dot com --- Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html Now discussion stop here - http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00320.html
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #68 from Francois-Xavier Coudert fxcoudert at gcc dot gnu.org --- (In reply to Igor Zamyatin from comment #67) Posted a patch here - http://gcc.gnu.org/ml/gcc-patches/2014-10/msg03318.html Now discussion stop here - http://gcc.gnu.org/ml/gcc-patches/2014-11/msg00320.html Isn't Jeff's email an approval to commit? As I read it, he said it's OK, but asked if you were sure why you wanted to do this. It seems you are sure. Jeff, could you confirm?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #69 from Dominique d'Humieres dominiq at lps dot ens.fr --- On top of pr63815, r216154 is also responsible of FAIL: gcc.target/i386/avx512f-kandnw-1.c scan-assembler-times kandnw[ t]+[^\\n]*%k[1-7] 1 FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not pop FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-not push FAIL: gcc.target/i386/fuse-caller-save-rec.c scan-assembler-times addl\\t%[re]?dx, %[re]?ax 1 FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times addpd\\t%xmm1, %xmm0 1 FAIL: gcc.target/i386/fuse-caller-save-xmm.c scan-assembler-times movapd\\t%xmm0, %xmm1 1 FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not pop FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-not push FAIL: gcc.target/i386/fuse-caller-save.c scan-assembler-times addl\\t%[re]?dx, %[re]?ax 1 with -m32 (may be related to pr63527).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Martin Liška marxin at gcc dot gnu.org changed: What|Removed |Added CC||marxin at gcc dot gnu.org --- Comment #58 from Martin Liška marxin at gcc dot gnu.org --- Hello Jack. I would like to thank you for the effort you invested in testing. I'm going to push all IPA ICF related patches to mainline as soon as possible. Interesting think would be to have a machine with darwin platform in compile farm. But I know it must be a different machine than your MacPro :) Thanks, Martin
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #59 from howarth at bromo dot med.uc.edu ---
(In reply to Martin Liška from comment #58)
Hello Jack.
I would like to thank you for the effort you invested in testing. I'm going
to push all IPA ICF related patches to mainline as soon as possible.
Interesting think would be to have a machine with darwin platform in compile
farm. But I know it must be a different machine than your MacPro :)
Thanks,
Martin
Martin,
Using make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32,-m64}' on the build from Comment 57 as
a quick regression scan shows...
Test Run By howarth on Fri Nov 7 02:25:01 2014
Native configuration is x86_64-apple-darwin14.0.0
=== gfortran tests ===
Schedule of variations:
unix/-m32
unix/-m64
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/coarray/caf.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/debug/debug.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/dg.exp
...
FAIL: gfortran.dg/assumed_rank_10.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/assumed_rank_10.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O2 execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -g execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -Os execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O2 execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O3 -g execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -Os execution test
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/gomp/gomp.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/graphite/graphite.exp
...
FAIL: gfortran.dg/graphite/pr42393.f90 -O (internal compiler error)
FAIL: gfortran.dg/graphite/pr42393.f90 -O (test for excess errors)
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/guality/guality.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/ieee/ieee.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/lto/lto.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/vect/vect.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/compile/compile.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.fortran-torture/execute/execute.exp
...
=== gfortran Summary for unix/-m32 ===
# of expected passes46508
# of unexpected failures16
# of expected failures52
# of unsupported tests214
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/config/default.exp
as tool-and-target-specific interface file.
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/coarray/caf.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/debug/debug.exp
...
Running
/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/gcc/testsuite/gfortran.dg/dg.exp
...
FAIL: gfortran.dg/assumed_rank_8.f90 -O2 execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer -funroll-loops
execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -O3 -g execution test
FAIL: gfortran.dg/assumed_rank_8.f90 -Os execution test
FAIL: gfortran.dg/assumed_rank_9.f90 -O2 execution test
FAIL:
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #60 from Dominique d'Humieres dominiq at lps dot ens.fr ---
Martin,
Using make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
on the build from Comment 57 as a quick regression scan shows...
See pr63622 comment 7.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #61 from howarth at bromo dot med.uc.edu ---
(In reply to Dominique d'Humieres from comment #60)
Martin,
Using make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
on the build from Comment 57 as a quick regression scan shows...
See pr63622 comment 7.
Oddly adding in the patch from Comment 50 here doesn't eliminate the fortran
regressions. Is there a second section to that change?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #62 from howarth at bromo dot med.uc.edu ---
(In reply to howarth from comment #61)
(In reply to Dominique d'Humieres from comment #60)
Martin,
Using make -k check-gfortran
RUNTESTFLAGS=--target_board=unix'{-m32,-m64}'
on the build from Comment 57 as a quick regression scan shows...
See pr63622 comment 7.
Oddly adding in the patch from Comment 50 here doesn't eliminate the fortran
regressions. Is there a second section to that change?
Reading through pr63622 a second time, it appears that these fortran
regressions were never triaged. I think we should proceed with the bootstrap
fixes and consider the test suite regression fixes in a second set of patches
unless these are impacting other targets.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #63 from Dominique d'Humieres dominiq at lps dot ens.fr --- Reading through pr63622 a second time, it appears that these fortran regressions were never triaged. I think we should proceed with the bootstrap fixes and consider the test suite regression fixes in a second set of patches unless these are impacting other targets. Please stop mixing the problems introduced by r216154 and r216305. While I agree that the first step is to fix bootstrap, there is no hope to fix the issues introduced by r216305 with patches for r216154: the fortran issues as well as the gcc/g++/ada ones are fall out of the former and should be reported in pr63622.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #64 from howarth at bromo dot med.uc.edu --- (In reply to Dominique d'Humieres from comment #63) Please stop mixing the problems introduced by r216154 and r216305. While I agree that the first step is to fix bootstrap, there is no hope to fix the issues introduced by r216305 with patches for r216154: the fortran issues as well as the gcc/g++/ada ones are fall out of the former and should be reported in pr63622. Then which should just put the test suite regressions aside for the moment and simply focus on fixing the bootstrap. We need though to either discuss all of the bootstrap patches in a single PR, cc the same information into all associated PRs or create a single meta PR for bootstrapping darwin. Otherwise, it become far to difficult to collate all of the required patches from the individual PRs.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #65 from Kirill Yukhin kyukhin at gcc dot gnu.org --- Author: kyukhin Date: Fri Nov 7 20:42:36 2014 New Revision: 217237 URL: https://gcc.gnu.org/viewcvs?rev=217237root=gccview=rev Log: PR target/63534 gcc/ * config/i386/i386.md (builtin_setjmp_receiver): Use pic_offset_table_rtx for PIC register. (nonlocal_goto_receiver): Delete. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 howarth at bromo dot med.uc.edu changed: What|Removed |Added CC||howarth at bromo dot med.uc.edu --- Comment #54 from howarth at bromo dot med.uc.edu --- What is the status of this PR? I am finding that current gcc trunk requires https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the use of alias on darwin resulting in undefined symbols in libstdc++. However then the error shifts to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to that reported in Comment 9 here. If I use the patch from https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=diff in this PR, the bootstrap failure shifts to... /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/xg++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/./prev-gcc/ -B/sw/lib/gcc5.0/x86_64-apple-darwin14.0.0/bin/ -nostdinc++ -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -B/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include/x86_64-apple-darwin14.0.0 -I/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc50-5.0.0-1000/gcc-5.0-20141106/libstdc++-v3/libsupc++ -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/prev-x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs -c -g -O2 -gtoggle -DIN_GCC-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc-5.0-20141106/gcc -I../../gcc-5.0-20141106/gcc/. -I../../gcc-5.0-20141106/gcc/../include -I../../gcc-5.0-20141106/gcc/../libcpp/include -I/sw/include -I/sw/include -I../../gcc-5.0-20141106/gcc/../libdecnumber -I../../gcc-5.0-20141106/gcc/../libdecnumber/dpd -I../libdecnumber -I../../gcc-5.0-20141106/gcc/../libbacktrace -DCLOOG_INT_GMP -I/sw/include -DCLOOG_INT_GMP -I/sw/include -I/sw/include -o tree-inline.o -MT tree-inline.o -MMD -MP -MF ./.deps/tree-inline.TPo ../../gcc-5.0-20141106/gcc/tree-inline.c ../../gcc-5.0-20141106/gcc/tree-inline.c: In function ‘int estimate_num_insns_seq(gimple_seq, eni_weights*)’: ../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: error: invalid argument to gimple call } ^ stmts # .MEM_3 = VDEF .MEM_1(D) retval.1677_4 = count_insns_seq (stmts, weights_2(D)); [tail call] ../../gcc-5.0-20141106/gcc/tree-inline.c:5820:1: internal compiler error: verify_gimple failed in stage2.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #55 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33915 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33915action=edit patch disabling nonlocal goto receiver and fixing setjmp receiver (In reply to howarth from comment #54) What is the status of this PR? I am finding that current gcc trunk requires https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the use of alias on darwin resulting in undefined symbols in libstdc++. However then the error shifts to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to that reported in Comment 9 here. If I use the patch from https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=diff in this PR, the bootstrap failure shifts to... Please try attached patch instead of https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=diff;
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #56 from Stupachenko Evgeny evstupac at gmail dot com --- If this does not help, then described issue is not related to this bug, as darwin bootstrap passed with the patch applied on r216304 (along with already committed to trunk patches from PR63618 and PR63620). The patch is discussed here: https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00445.html
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #57 from howarth at bromo dot med.uc.edu --- (In reply to Stupachenko Evgeny from comment #55) Created attachment 33915 [details] patch disabling nonlocal goto receiver and fixing setjmp receiver (In reply to howarth from comment #54) What is the status of this PR? I am finding that current gcc trunk requires https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 in order to avoid the use of alias on darwin resulting in undefined symbols in libstdc++. However then the error shifts to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c19 which is identical to that reported in Comment 9 here. If I use the patch from https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=diff in this PR, the bootstrap failure shifts to... Please try attached patch instead of https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=diff; Using gcc trunk at r217202 with the patches from... https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00541.html https://gcc.gnu.org/ml/gcc-patches/2014-11/msg00555.html https://gcc.gnu.org/bugzilla/attachment.cgi?id=33843 from https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63622#c3 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63580#c4 and your revised patch for disabling nonlocal goto receiver and fixing setjmp receiver from Comment 55 applied allows x86_64-apple-darwin14 to completely bootstrap when configured as... ../gcc-5.0-20141106/configure --prefix=/sw --prefix=/sw/lib/gcc5.0 --mandir=/sw/share/man --infodir=/sw/lib/gcc5.0/info --enable-languages=c,c++,fortran,lto,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-isl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --program-suffix=-fsf-5.0 Hopefully these patches can get pushed into gcc trunk to allow routine regression testing on darwin again.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #53 from ienkovich at gcc dot gnu.org --- Author: ienkovich Date: Fri Oct 31 13:30:06 2014 New Revision: 216975 URL: https://gcc.gnu.org/viewcvs?rev=216975root=gccview=rev Log: gcc/ PR target/63534 * config/i386/i386.c (ix86_init_pic_reg): Emit SET_GOT to REAL_PIC_OFFSET_TABLE_REGNUM for mcount profiling. (ix86_save_reg): Save REAL_PIC_OFFSET_TABLE_REGNUM when profiling using mcount in 32bit PIC mode. (ix86_elim_entry_set_got): New. (ix86_expand_prologue): For the mcount profiling emit new SET_GOT in PROLOGUE, delete initial if possible. gcc/testsuite/ PR target/63534 * gcc.target/i386/mcount_pic.c: New. Added: trunk/gcc/testsuite/gcc.target/i386/mcount_pic.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #51 from Dominique d'Humieres dominiq at lps dot ens.fr --- In addition r216154 breaks a lot of asan tests with -m32: see https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html Could you please try following patch? diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c ... The failures are gone with the patch. Thanks.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #52 from Jeffrey A. Law law at redhat dot com --- Igor, can you post the patch from c#50 for official review? Thanks!
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #50 from Igor Zamyatin izamyatin at gmail dot com ---
In addition r216154 breaks a lot of asan tests with -m32: see
https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
Could you please try following patch?
diff --git a/gcc/cfgexpand.c b/gcc/cfgexpand.c
index 5580ea8..508db5d 100644
--- a/gcc/cfgexpand.c
+++ b/gcc/cfgexpand.c
@@ -1715,6 +1715,9 @@ expand_used_vars (void)
-
init_vars_expansion ();
-
+ if (targetm.use_pseudo_pic_reg ())
+pic_offset_table_rtx = gen_reg_rtx (Pmode);
+
hash_maptree, tree ssa_name_decls;
for (i = 0; i SA.map-num_partitions; i++)
{
diff --git a/gcc/function.c b/gcc/function.c
index ee229ad..dab691d 100644
--- a/gcc/function.c
+++ b/gcc/function.c
@@ -3464,11 +3464,6 @@ assign_parms (tree fndecl)
-
fnargs.release ();
-
- /* Initialize pic_offset_table_rtx with a pseudo register
- if required. */
- if (targetm.use_pseudo_pic_reg ())
-pic_offset_table_rtx = gen_reg_rtx (Pmode);
-
/* Output all parameter conversion instructions (possibly including calls)
now that all parameters have been copied out of hard registers. */
emit_insn (all.first_conversion_insn);
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr --- --- Comment #44 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #43) [...] there were at one point this week 4 concurrent bootstrap breaks on dariwn. this PR. the ipa-icf series requiring non-weak aliases -- this is pr63622 and the iconv dep on libcpp.-- AFAICT this should be fixed now In addition r216154 breaks a lot of asan tests with -m32: see https://gcc.gnu.org/ml/gcc-testresults/2014-10/msg02834.html
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #49 from Igor Zamyatin izamyatin at gmail dot com --- Testing a patch to fix asan failures
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added CC||ro at gcc dot gnu.org --- Comment #38 from Rainer Orth ro at gcc dot gnu.org --- What's currently required to get Darwin/x86 to bootstrap again? I'm totally lost in this maze of PRs and patches. I've just tried r216667 plus the patch from PR 63620 on x86_64-apple-darwin14.0.0 and still run into ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 when linking stage1 libstdc++. Rainer
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) What's currently required to get Darwin/x86 to bootstrap again? I'm totally lost in this maze of PRs and patches. I've just tried r216667 plus the patch from PR 63620 on x86_64-apple-darwin14.0.0 and still run into ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 when linking stage1 libstdc++. Rainer You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #40 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) [...] You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html Even with this, the illegal text reloc error remains. May be a Mac OS X 10.10 thing, though? Rainer
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) --- Comment #39 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Rainer Orth from comment #38) [...] You should apply patch from comment 15 as well. It is still under review: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02482.html Even with this, the illegal text reloc error remains. May be a Mac OS X 10.10 thing, though? Rainer That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #42 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #43 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #42) --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer The core thing in comment 34 is patch in comment 33 applied on top of r216304. Most likely after r216304 someone broke darwin bootstrap again. So to test my changes I use revision r216304 with patch from commnet 33.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #44 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #43) (In reply to r...@cebitec.uni-bielefeld.de from comment #42) --- Comment #41 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to r...@cebitec.uni-bielefeld.de from comment #40) [...] That should be not EBX enablig issue as pointed in comments 17 and 35. I'm testing bootstrap like in comment 34 and it passed. Adding --with-arch=core2 --with-cpu=core2 didn't make any difference. Rainer The core thing in comment 34 is patch in comment 33 applied on top of r216304. Most likely after r216304 someone broke darwin bootstrap again. So to test my changes I use revision r216304 with patch from commnet 33. there were at one point this week 4 concurrent bootstrap breaks on dariwn. this PR. the ipa-icf series requiring non-weak aliases and the iconv dep on libcpp. I don't know how many of those have been fixed so far - but I suspect that not all have. Unfortunately, not able to be more explict right now.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #44 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #43) [...] there were at one point this week 4 concurrent bootstrap breaks on dariwn. this PR. the ipa-icf series requiring non-weak aliases and the iconv dep on libcpp. I don't know how many of those have been fixed so far - but I suspect that not all have. Unfortunately, not able to be more explict right now. Thanks for the update. As I said, I'd completely lost track of what's going on here. I'm now testing the rev before Evgeny's patch to check if that bootstraps on 10.10. If not, we may have yet another issue here. Rainer
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #46 from Jeffrey A. Law law at redhat dot com --- Glad I'm not the only one struggling to track everything that's breaking on Darwin!
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #47 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #45 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- [...] I'm now testing the rev before Evgeny's patch to check if that bootstraps on 10.10. If not, we may have yet another issue here. I'm now in stage2 at rev 216153, so there's no 10.10 issue here. Rainer
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #37 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Thu Oct 23 16:52:11 2014 New Revision: 216596 URL: https://gcc.gnu.org/viewcvs?rev=216596root=gccview=rev Log: PR target/63534 PR target/63618 gcc/ * cse.c (delete_trivially_dead_insns): Consider PIC register is used while it is pseudo. * dse.c (deletable_insn_p): Likewise. gcc/testsuite/ * gcc.target/i386/pr63618.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr63618.c Modified: trunk/gcc/ChangeLog trunk/gcc/cse.c trunk/gcc/dce.c trunk/gcc/testsuite/ChangeLog
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #35 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #33) Created attachment 33769 [details] patch includes 3 patches fixing darwin bootstrap Do you have any ideas where darwin can treat the LC0 symbol so? This deserves a proper answer - but I don't have enough context to give one. - can you point me at something specific to build or attach the .i and .s file relevant? Mike - any comments? Please try attached patch (includes all fixes) moving pushtf split earlier. The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of 216304). this worked for me - although we're still hosed by multiple other issues from later commits.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #36 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Iain Sandoe from comment #35) (In reply to Stupachenko Evgeny from comment #33) Created attachment 33769 [details] patch includes 3 patches fixing darwin bootstrap Do you have any ideas where darwin can treat the LC0 symbol so? This deserves a proper answer - but I don't have enough context to give one. - can you point me at something specific to build or attach the .i and .s file relevant? I've created PR63618 and PR63620 with small reproducers. PR63620 is darwin only issue (note that patch from PR63618 should be applied). Mike - any comments? Please try attached patch (includes all fixes) moving pushtf split earlier. The bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of 216304). this worked for me - although we're still hosed by multiple other issues from later commits.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #33 from Stupachenko Evgeny evstupac at gmail dot com ---
Created attachment 33769
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33769action=edit
patch includes 3 patches fixing darwin bootstrap
It looks like data constant LC0 generated from pushtf not treated as GOT
dependent or treated as unchanged (assuming it depends on unchanged ebx) at
darwin reload pass.
RELOAD PASS:
(insn/f 106 8 2 2 (parallel [
(set (reg:SI 0 ax [98])
(unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT))
(clobber (reg:CC 17 flags))
]) 679 {set_got}
(expr_list:REG_EQUIV (unspec:SI [
(const_int 0 [0])
] UNSPEC_SET_GOT)
(expr_list:REG_CFA_FLUSH_QUEUE (nil)
(nil
.
For some reason on darwin AX is set here without spilling previous value.
On Linux AX is spilled and filled in appropriate place.
After that while reading LC0 on darwin we use incorrect GOT register.
(insn 115 41 116 6 (set (reg:SI 0 ax [128])
(plus:SI (reg:SI 0 ax [98])
(const:SI (unspec:SI [
(symbol_ref/u:SI (*LC0) [flags 0x2])
] UNSPEC_MACHOPIC_OFFSET frexpq.c:1319 213 {*leasi}
(expr_list:REG_EQUAL (symbol_ref/u:SI (*LC0) [flags 0x2])
(nil)))
...
Do you have any ideas where darwin can treat the LC0 symbol so?
Please try attached patch (includes all fixes) moving pushtf split earlier. The
bootstrap (c,c++,fortran,lto) on MAC passed (patch applied on top of 216304).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #34 from Dominique d'Humieres dominiq at lps dot ens.fr --- Bootstrap completed with the patch in comment 33 applied on top of r216304 and configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.10p-216304p1 --enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp --with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto --enable-plugin --with-arch=core2 --with-cpu=core2 Thanks for the patch.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #31 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Jeffrey A. Law from comment #29)
I thought we had already dealt with the hidden GOT usages that show up
during reload... Is it IRA that's removing the SET_GOT?
That is not EQUIV related case. SET_GOT is removed by CSE called at IRA.
Here we have insn that don't use GOT register implicitly:
(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
(const_double:TF 2.0769187434139310514121985316880384e+34
[0x0.8p+115])) frexpq.c:1316 121 {*pushtf}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
It appears that there are no other insns using GOT or calls.
Therefore CSE absolutely correct in removing SET_GOT.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #32 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Iain Sandoe from comment #30) FWIW, I built a stage #1 with fortran, objc and ada enabled. libgcc, libstdc++v3, libgomp, libobjc and libada build. libgfortran libquadmath fail (errors as per Dominique's post). We got MAC and are setting up GCC build there to be able to reproduce all issues and publish patch fixing whole bootstrap.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #24 from Stupachenko Evgeny evstupac at gmail dot com ---
We are able to reproduce the bug.
SET_GOT removed as the only use of GOT register was hidden by:
(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
(const_double:TF 2.0769187434139310514121985316880384e+34
[0x0.8p+115])) frexpq.c:1316 121 {*pushtf}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
The solution is not to delete SET_GOT till reload.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #25 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 33746 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33746action=edit RTL dumps This is trunk rev 216304 + change to i386.md. -O2 -m32. For O0/1 the output is created OK. For O2 the picbase is being optimised away. (this was with a stage#1 compiler built -O0 -g3 using a GCC-4.9 bootstrap).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #26 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #24)
We are able to reproduce the bug.
SET_GOT removed as the only use of GOT register was hidden by:
(insn 37 34 38 6 (set (mem:TF (pre_dec:SI (reg/f:SI 7 sp)) [0 S16 A8])
(const_double:TF 2.0769187434139310514121985316880384e+34
[0x0.8p+115])) frexpq.c:1316 121 {*pushtf}
(expr_list:REG_ARGS_SIZE (const_int 16 [0x10])
(nil)))
The solution is not to delete SET_GOT till reload.
cool!
sorry I didn't see that before making my post…
.. are you working up a patch?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #27 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33748 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33748action=edit Fix SET_GOT delete The patch fix the problem. Can you please run darwin bootstrap with it and previous (receivers patterns delete)? x86 is in progress.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #28 from Dominique d'Humieres dominiq at lps dot ens.fr --- With the patches in comments 15 and 27 applied on top of r216304, bootstrap stil fails with libtool: compile: /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -B/opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/bin/ -B/opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/lib/ -isystem /opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/include -isystem /opt/gcc/gcc4.10p-216304p1/x86_64-apple-darwin14.0.0/sys-include -DHAVE_CONFIG_H -I. -I../../../../p_work/libquadmath -I ../../../../p_work/libquadmath/../include -g -O2 -m32 -MT math/remainderq.lo -MD -MP -MF math/.deps/remainderq.Tpo -c ../../../../p_work/libquadmath/math/remainderq.c -fno-common -DPIC -o math/.libs/remainderq.o /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cclKy0QW.s:388:non-relocatable subtraction expression, LC1 minus L1$pb /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cclKy0QW.s:388:symbol: L1$pb can't be undefined in a subtraction expression /var/folders/8q/sh_swgz96r7f5vnn08f7fxr0gn/T//cclKy0QW.s:unknown:Undefined local symbol L1$pb
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #29 from Jeffrey A. Law law at redhat dot com --- I thought we had already dealt with the hidden GOT usages that show up during reload... Is it IRA that's removing the SET_GOT?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #30 from Iain Sandoe iains at gcc dot gnu.org --- FWIW, I built a stage #1 with fortran, objc and ada enabled. libgcc, libstdc++v3, libgomp, libobjc and libada build. libgfortran libquadmath fail (errors as per Dominique's post).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #15 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33733 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33733action=edit patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md).
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #16 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33733 [details] patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md). With the patch bootstrap fails with libtool: link: /opt/gcc/build_w/./gcc/xgcc -shared-libgcc -B/opt/gcc/build_w/./gcc -nostdinc++ -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/bin/ -B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/lib/ -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/include -isystem /opt/gcc/gcc4.10w/x86_64-apple-darwin13.4.0/sys-include-dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib .libs/compatibility.o .libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o .libs/compatibility-condvar.o -Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a -Wl,-force_load,../src/c++98/.libs/libc++98convenience.a -Wl,-force_load,../src/c++11/.libs/libc++11convenience.a -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/libsupc++/.libs -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src -L/opt/gcc/build_w/x86_64-apple-darwin13.4.0/libstdc++-v3/src/.libs -lm -Wl,-single_module -Wl,-exported_symbols_list -Wl,libstdc++-symbols.explist -install_name /opt/gcc/gcc4.10w/lib/libstdc++.6.dylib -compatibility_version 7 -current_version 7.21 -Wl,-single_module ld: warning: cannot export hidden symbol __cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info const*, void**, unsigned int) const from ../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o) ld: warning: cannot export hidden symbol std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::basic_stringbufwchar_t, std::char_traitswchar_t, std::allocatorwchar_t ::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istreamchar, std::char_traitschar -in-std::istrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::ostrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istreamchar, std::char_traitschar -in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_iostreamchar, std::char_traitschar -in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char const*, char const*, char, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctypechar::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctypechar::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld:
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added CC||iains at gcc dot gnu.org --- Comment #17 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #16) Created attachment 33733 [details] patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md). With the patch bootstrap fails with ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 collect2: error: ld returned 1 exit status It's possible that this ^ is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59888 (investigating)… once we get past this .. I suppose someone should try a bootstrap on i686-darwin .. will try to fit that in later.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #18 from Stupachenko Evgeny evstupac at gmail dot com --- Created attachment 33736 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736action=edit patch disabling just nonlocal_goto_receiver split Am I correct that this is 64 bits library link failed? If so it is really strange, because the patch removes patterns under !TARGET_64BIT. Can you please try more conservative patch disabling just nonlocal_goto_receiver split bootstrapping it from scratch?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #19 from Dominique d'Humieres dominiq at lps dot ens.fr --- Can you please try more conservative patch disabling just nonlocal_goto_receiver split bootstrapping it from scratch? It still get the same error/warnings as in comment 16 with the conservative patch.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #20 from Iain Sandoe iains at gcc dot gnu.org --- so I rewound to r216156 and made the change to i386.md (removed the receiver and nonlocal label stuff). So, that succeeds in getting to stage #3 and then fails building [m32] target libs which is much more likley to be fallout from these changes. (Transcript below) Note that there is some PIC register handling in common code for darwin (config/darwin.c) - is it possible that a required change has been missed? meanwhile, I'll try and track down what appears to be a second bootstrap crasher in the same window = libtool: compile: /GCC/ml/gcc-trunk-appleas/./gcc/xgcc -B/GCC/ml/gcc-trunk-appleas/./gcc/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I. -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2 -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c /GCC/gcc-trunk/libquadmath/math/frexpq.c -fno-common -DPIC -o math/.libs/frexpq.o /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non-relocatable subtraction expression, LC0 minus L1$pb /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol: L1$pb can't be undefined in a subtraction expression /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown:Undefined local symbol L1$pb make[6]: *** [math/frexpq.lo] Error 1 make[5]: *** [all] Error 2
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #21 from Igor Zamyatin izamyatin at gmail dot com --- (In reply to Iain Sandoe from comment #20) libtool: compile: /GCC/ml/gcc-trunk-appleas/./gcc/xgcc -B/GCC/ml/gcc-trunk-appleas/./gcc/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/bin/ -B/compilers/gcc-trunk/x86_64-apple-darwin12/lib/ -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/include -isystem /compilers/gcc-trunk/x86_64-apple-darwin12/sys-include -DHAVE_CONFIG_H -I. -I/GCC/gcc-trunk/libquadmath -I /GCC/gcc-trunk/libquadmath/../include -g -O2 -m32 -MT math/frexpq.lo -MD -MP -MF math/.deps/frexpq.Tpo -c /GCC/gcc-trunk/libquadmath/math/frexpq.c -fno-common -DPIC -o math/.libs/frexpq.o /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:non- relocatable subtraction expression, LC0 minus L1$pb /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:68:symbol: L1$pb can't be undefined in a subtraction expression /var/folders/tj/17r7407j14d324dzf67cnvxm000114/T//ccahZ8x6.s:unknown: Undefined local symbol L1$pb make[6]: *** [math/frexpq.lo] Error 1 make[5]: *** [all] Error 2 Can we look at the rtl dumps and probably asm file?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #22 from Iain Sandoe iains at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #17) (In reply to Dominique d'Humieres from comment #16) Created attachment 33733 [details] patch to fix darwin bootstrap With pseudo GOT register we don't need to set GOT register after any jump, and therefore don't need nonlocal_goto_receiver and builtin_setjmp_receiver for i386. Please try attached patch (just removing nonlocal_goto_receiver and builtin_setjmp_receiver from i386.md). With the patch bootstrap fails with ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostreamchar, std::char_traitschar -in-std::strstream' for architecture x86_64 collect2: error: ld returned 1 exit status This fail above ^ is caused by r216305 (which seems to be being investigated elsewhere)
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #23 from Iain Sandoe iains at gcc dot gnu.org --- Created attachment 33741 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33741action=edit asm and .i I built 216304+removing the two sections in i386.md. A stage 1 compiler built with -O0 -g is suffient to show the issue - so it's possible to debug without needing a Darwin box. Attached the .i and .s files for the first file to fail from doing make all-target-libquadmath at stage #1. As you will see there is no picbase being output for the function (there should be a call to a thunk and a label L1$pb0). Will sort out the tree dumps tomorrow ..
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- For -pg, at least for 32-bit -fpic, one way to handle this would be for !targetm.profile_before_prologue () crtl-profile in ix86_init_pic_reg instead of emitting set_got into the pic_offset_table_rtx emit set_got into %ebx hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA that it better should allocate the pic register at the start of the function to %ebx). And then, when emitting prologue, see if the function doesn't start with set_got insn (after optional notes) loading into %ebx, and if it does, move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which final.c emits the _mcount call). That way, there will be just a single set_got, not two. If you don't find it for some reason (e.g. function that doesn't use PIC register otherwise, or something unexpected happened), make sure you treat %ebx as clobbered in the prologue and emit the set_got into %ebx directly right before NOTE_INSN_PROLOGUE_END. For -m64 -fpic -mcmodel=large -pg this will be harder, as init_pic_reg emits multiple instructions.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #9 from Dominique d'Humieres dominiq at lps dot ens.fr ---
r216154 broke bootstrap on x86_64-apple-darwin13 too while building
libstdc++-v3:
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.libs
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32
-I/opt/gcc/p_work/libstdc++-v3/../libgcc
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/x86_64-apple-darwin13.4.0
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include
-I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2 -m32
-std=gnu++11 -c ../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc
-fno-common -DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function
'void {anonymous}::key_init()':
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal
compiler error: in cselib_invalidate_regno, at cselib.c:2146
}
^
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3: internal
compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1plus)
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #10 from Stupachenko Evgeny evstupac at gmail dot com --- (In reply to Jakub Jelinek from comment #8) For -pg, at least for 32-bit -fpic, one way to handle this would be for !targetm.profile_before_prologue () crtl-profile in ix86_init_pic_reg instead of emitting set_got into the pic_offset_table_rtx emit set_got into %ebx hard reg and then copy %ebx to the pic_offset_table_rtx (to strongly hint RA that it better should allocate the pic register at the start of the function to %ebx). And then, when emitting prologue, see if the function doesn't start with set_got insn (after optional notes) loading into %ebx, and if it does, move the set_got insn right before the NOTE_INSN_PROLOGUE_END (on which final.c emits the _mcount call). That way, there will be just a single set_got, not two. If you don't find it for some reason (e.g. function that doesn't use PIC register otherwise, or something unexpected happened), make sure you treat %ebx as clobbered in the prologue and emit the set_got into %ebx directly right before NOTE_INSN_PROLOGUE_END. For -m64 -fpic -mcmodel=large -pg this will be harder, as init_pic_reg emits multiple instructions. Sounds reasonable. I also don't like 2 set_got one-by-one. However, we should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I expect there should be an easier way to do this. And we should refer %ebx for pseudo GOT register in all 32bit cases. Right now we can emit second set_got and file a bug on potential performance improvement in RA. I've measured spec2000 o2 -fporfile-generate execution on train data on Corei7. Even with additional set_got there is: CINT +0,2 CFP +1,4 compared to a compiler before enabling ebx.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #11 from Vladimir Makarov vmakarov at gcc dot gnu.org --- (In reply to Stupachenko Evgeny from comment #10) Sounds reasonable. I also don't like 2 set_got one-by-one. However, we should ask Vladimir on how we can force RA allocate pseudo GOT on %ebx. I expect there should be an easier way to do this. And we should refer %ebx for pseudo GOT register in all 32bit cases. Right now we can emit second set_got and file a bug on potential performance improvement in RA. The modification to IRA to get ebx for GOT pseudo could be not difficult. However it will not work. When I worked on modification RA for this project, I saw that RA gets info that ebx is clobbered by calls. I already wrote about this to Ilya. So this problem should be solved first. When the problem is solved, GOT pseudo will get the best hard reg (most probably ebx) and we will not need to do modification to RA to assign specifically ebx to GOT pseudo. I've measured spec2000 o2 -fporfile-generate execution on train data on Corei7. Even with additional set_got there is: CINT +0,2 CFP +1,4 compared to a compiler before enabling ebx.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #12 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Dominique d'Humieres from comment #9)
r216154 broke bootstrap on x86_64-apple-darwin13 too while building
libstdc++-v3:
libtool: compile: /opt/gcc/p_build/./gcc/xgcc -shared-libgcc
-B/opt/gcc/p_build/./gcc -nostdinc++
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/src/.libs
-L/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/libsupc++/.
libs -B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/bin/
-B/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/lib/ -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/include -isystem
/opt/gcc/gcc4.10p-216154/x86_64-apple-darwin13.4.0/sys-include -m32
-I/opt/gcc/p_work/libstdc++-v3/../libgcc
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include/
x86_64-apple-darwin13.4.0
-I/opt/gcc/p_build/x86_64-apple-darwin13.4.0/i386/libstdc++-v3/include
-I/opt/gcc/p_work/libstdc++-v3/libsupc++ -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi
-fdiagnostics-show-location=once -fvisibility-inlines-hidden
-ffunction-sections -fdata-sections -frandom-seed=atexit_thread.lo -g -O2
-m32 -std=gnu++11 -c
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc -fno-common
-DPIC -D_GLIBCXX_SHARED -o atexit_thread.o
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc: In function
'void {anonymous}::key_init()':
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
internal compiler error: in cselib_invalidate_regno, at cselib.c:2146
}
^
../../../../../p_work/libstdc++-v3/libsupc++/atexit_thread.cc:111:3:
internal compiler error: Abort trap: 6
xgcc: internal compiler error: Abort trap: 6 (program cc1plus)
We are trying to reproduce the issue. Can you please send me/attach rtl dumps
on the fail?
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- Created attachment 33728 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33728action=edit Compressed tar of the files produced with -fdump-rtl-all
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #14 from Igor Zamyatin izamyatin at gmail dot com --- Thanks! That's define_insn_and_split nonlocal_goto_receiver where the issue comes from. Seems now we need to handle this split somewhat similar to the second approach in solving of the profiling issue
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-10-14 Target Milestone|--- |5.0 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It sounds like it would work fine for leaf functions though (really leafs, accounting for things like __morestack or _mcount calls). Confirmed btw.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
Stupachenko Evgeny evstupac at gmail dot com changed:
What|Removed |Added
CC||evstupac at gmail dot com
--- Comment #2 from Stupachenko Evgeny evstupac at gmail dot com ---
Before the changes there were potential bug as morestack call was emitted with
dependency on ebx (which was not set):
(call_insn 28 27 29 3 (call (mem:QI (symbol_ref:SI (__morestack)) [0 S1 A8])
(const_int 4 [0x4])) ../../../../gcc/libgo/runtime/go-assert.c:15 -1
(nil)
(expr_list (use (reg:SI 3 bx))
(nil)))
Treating morestack as SYMBOL_FLAG_LOCAL resolves the issue.
The following patch should fix go bootstrap:
(bootstaped with --enable-languages=c,c++,fortran,lto,go)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a3ca2ed..6235c4f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -11999,7 +11999,10 @@ ix86_expand_split_stack_prologue (void)
REG_BR_PROB_BASE - REG_BR_PROB_BASE / 100);
if (split_stack_fn == NULL_RTX)
-split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, __morestack);
+{
+ split_stack_fn = gen_rtx_SYMBOL_REF (Pmode, __morestack);
+ SYMBOL_REF_FLAGS (split_stack_fn) |= SYMBOL_FLAG_LOCAL;
+}
fn = split_stack_fn;
/* Get more stack space. We pass in the desired stack space and the
@@ -12044,9 +12047,11 @@ ix86_expand_split_stack_prologue (void)
gcc_assert ((args_size 0x) == args_size);
if (split_stack_fn_large == NULL_RTX)
- split_stack_fn_large =
- gen_rtx_SYMBOL_REF (Pmode, __morestack_large_model);
-
+ {
+ split_stack_fn_large =
+ gen_rtx_SYMBOL_REF (Pmode, __morestack_large_model);
+ SYMBOL_REF_FLAGS (split_stack_fn_large) |= SYMBOL_FLAG_LOCAL;
+ }
if (ix86_cmodel == CM_LARGE_PIC)
{
rtx_code_label *label;
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- For -fsplit-stack you are right, __morestack seems to have hidden visibility, so even if gcc emits call __morestack@plt, the linker should transform that into a direct call __morestack which doesn't need %ebx set up. Profiling -fpic code would still remain broken though.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #4 from Stupachenko Evgeny evstupac at gmail dot com ---
Profiling implementation has hard coded %ebx use.
There are at least 2 quick solutions to resolve this:
1. Disable the changes for PIC profiling
Lead to different behavior with and without profiling of code with EBX asm
insertions. However could be applied as temporary solution as there are no EBX
asm insertions right now.
2.
print:
push %ebx
call__x86.get_pc_thunk.bx
addl$_GLOBAL_OFFSET_TABLE_, %ebx
and pop %ebx at the end
Here:
else if (flag_pic)
{
#ifndef NO_PROFILE_COUNTERS
fprintf (file, \tleal\t%sP%d@GOTOFF(%%ebx),%% PROFILE_COUNT_REGISTER
\n,
LPREFIX, labelno);
#endif
fprintf (file, 1:\tcall\t*%s@GOT(%%ebx)\n, mcount_name);
}
Lower profiling performance in PIC mode.
I vote for the second solution and can prepare patch for this.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Double set_got doesn't make sense, if you want to keep the current model, I'd emit a set_got insn forced into %ebx before the mcount call in the prologue and see if early after the prologue isn't a set_got insn, if there is, see if %ebx isn't clobbered in between the second set_got and end of prologue (or the reg in that second set_got), and if it isn't, just replace the second set_got with a move from %ebx to the reg used there (or, if %ebx is clobbered and the second reg isn't, move in the prologue into that register). Keep the double set_got only in uncommon case where you don't find it or both regs are clobbered early.
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 --- Comment #6 from iverbin at gcc dot gnu.org --- Author: iverbin Date: Tue Oct 14 16:26:57 2014 New Revision: 216208 URL: https://gcc.gnu.org/viewcvs?rev=216208root=gccview=rev Log: PR target/63534 gcc/ * config/i386/i386.c (ix86_expand_split_stack_prologue): Make __morestack local. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c
[Bug target/63534] [5 Regression] Bootstrap failure on x86_64/i686-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com --- Comment #7 from Jeffrey A. Law law at redhat dot com --- I'd strongly recommend against option #1 to deal with PIC vs profiling. We don't want to have two distinct implementations for PIC support in 32 bit mode. I've got no strong opinions on Jakub's proposal, or emitting a second set_got after the profiling bits.
