r216154 broke bootstrap on x86_64-linux and i686-linux for me, pretty much everything in libgo ICEs, including as simple testcases as: void foo (void) {} with -m32 -fsplit-stack -fpic (with or without -O?). Seems the pro_and_epilogue pass adds insn like: (insn 14 13 15 3 (set (reg:SI 3 bx) (reg:SI 83)) g2.i:3 90 {*movsi_internal} (nil)) before a call to __morestack added during the prologue expansion, which of course isn't right, this is after reload and using a pseudo is not allowed. Also, looking at a simple testcase like: void foo (void) { bar (); bar (); } I see wrong-code for -m32 -O2 -fpic -p: there is call *mcount@GOT(%ebx) before set_got is invoked, so if e.g. the routine is called from executable, where %ebx can contain pretty much anything, it will crash, or if it is called from a different shared library, it will access unrelated pointer in that other shared library's got rather than current library's got. And lastly, I'm seeing on the same testcase significant code quality regression with just -m32 -O2 -fpic: .cfi_startproc - pushl %ebx + pushl %esi .cfi_def_cfa_offset 8 - .cfi_offset 3, -8 - call __x86.get_pc_thunk.bx - addl $_GLOBAL_OFFSET_TABLE_, %ebx - subl $8, %esp + .cfi_offset 6, -8 + pushl %ebx + .cfi_def_cfa_offset 12 + .cfi_offset 3, -12 + call __x86.get_pc_thunk.si + addl $_GLOBAL_OFFSET_TABLE_, %esi + subl $4, %esp .cfi_def_cfa_offset 16 + movl %esi, %ebx call bar@PLT call bar@PLT - addl $8, %esp - .cfi_def_cfa_offset 8 + addl $4, %esp + .cfi_def_cfa_offset 12 popl %ebx .cfi_restore 3 + .cfi_def_cfa_offset 8 + popl %esi + .cfi_restore 6 .cfi_def_cfa_offset 4 ret .cfi_endproc Here, the register allocator makes a bad decision (load the got into %esi rather than %ebx, both are call saved registers, but we need it in %ebx), and nothing after LRA fixes it up (postreload, etc.). Can the problematic commit be reverted and all these issues analyzed and fixed before it is reapplied?
It sounds like it would work fine for leaf functions though (really leafs, accounting for things like __morestack or _mcount calls). Confirmed btw.
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 & 0xffffffff) == 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;
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.
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.
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.
Author: iverbin Date: Tue Oct 14 16:26:57 2014 New Revision: 216208 URL: https://gcc.gnu.org/viewcvs?rev=216208&root=gcc&view=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
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.
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.
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)
(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".
(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".
(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?
Created attachment 33728 [details] Compressed tar of the files produced with -fdump-rtl-all
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
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).
> 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_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++98/.libs/libc++98convenience.a(complex_io.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype.o) ld: warning: cannot export hidden symbol std::ctype<char>::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::ctype<char>::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_istream<char, std::char_traits<char> >-in-std::istrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::ostrstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<char, std::char_traits<char> >-in-std::strstream from ../src/c++98/.libs/libc++98convenience.a(strstream.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(ctype_members.o) ld: warning: cannot export hidden symbol std::ctype<char>::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::ctype<char>::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::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char const*, char const*, char*) const from ../src/c++98/.libs/libc++98convenience.a(locale-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++98/.libs/libc++98convenience.a(misc-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::~stdio_sync_filebuf() from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::xsgetn(wchar_t*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<wchar_t, std::char_traits<wchar_t> >::xsputn(wchar_t const*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::xsputn(char const*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf<char, std::char_traits<char> >::xsgetn(char*, long) from ../src/c++11/.libs/libc++11convenience.a(ext11-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(ios-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_narrow(char, char) const from ../src/c++11/.libs/libc++11convenience.a(ios-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(istream-inst.o) ld: warning: cannot export hidden symbol std::ctype<char>::do_widen(char) const from ../src/c++11/.libs/libc++11convenience.a(ostream-inst.o) ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol std::basic_stringbuf<char, std::char_traits<char>, std::allocator<char> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol std::basic_stringbuf<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >::~basic_stringbuf() from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::basic_istringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::basic_ostringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<char, std::char_traits<char> >-in-std::basic_stringstream<char, std::char_traits<char>, std::allocator<char> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_istringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_ostringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_ostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_istream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: warning: cannot export hidden symbol construction vtable for std::basic_iostream<wchar_t, std::char_traits<wchar_t> >-in-std::basic_stringstream<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> > from ../src/c++11/.libs/libc++11convenience.a(sstream-inst.o) ld: illegal text reloc in 'std::strstream::strstream()' to 'construction vtable for std::basic_ostream<char, std::char_traits<char> >-in-std::strstream' for architecture x86_64 collect2: error: ld returned 1 exit status
(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_ostream<char, std::char_traits<char> > >-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.
Created attachment 33736 [details] 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?
> 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.
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 ====
(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?
(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_ostream<char, std::char_traits<char> > > >-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)
Created attachment 33741 [details] 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 ..
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.
Created attachment 33746 [details] 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).
(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?
Created attachment 33748 [details] 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.
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_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:388:non-relocatable subtraction expression, "LC1" minus "L1$pb" /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:388:symbol: "L1$pb" can't be undefined in a subtraction expression /var/folders/8q/sh_swgz96r7f5vnn08f7fxr00000gn/T//cclKy0QW.s:unknown:Undefined local symbol L1$pb
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?
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).
(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.
(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.
Created attachment 33769 [details] 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).
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.
(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.
(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.
Author: iverbin Date: Thu Oct 23 16:52:11 2014 New Revision: 216596 URL: https://gcc.gnu.org/viewcvs?rev=216596&root=gcc&view=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
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_ostream<char, std::char_traits<char> >-in-std::strstream' for architecture x86_64 when linking stage1 libstdc++. Rainer
(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_ostream<char, std::char_traits<char> > >-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
> --- 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
(In reply to ro@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.
> --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> --- > (In reply to ro@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
(In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42) > > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> --- > > (In reply to ro@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.
(In reply to Stupachenko Evgeny from comment #43) > (In reply to ro@CeBiTec.Uni-Bielefeld.DE from comment #42) > > > --- Comment #41 from Stupachenko Evgeny <evstupac at gmail dot com> --- > > > (In reply to ro@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.
> --- 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
Glad I'm not the only one struggling to track everything that's breaking on Darwin!
> --- 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
> --- 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
Testing a patch to fix asan failures
> 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_map<tree, 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);
> > 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.
Igor, can you post the patch from c#50 for official review? Thanks!
Author: ienkovich Date: Fri Oct 31 13:30:06 2014 New Revision: 216975 URL: https://gcc.gnu.org/viewcvs?rev=216975&root=gcc&view=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
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=33736&action=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.
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=33736&action=diff in this PR, > the bootstrap failure shifts to... > Please try attached patch instead of "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=diff"
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
(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=33736&action=diff in this PR, > > the bootstrap failure shifts to... > > > Please try attached patch instead of > "https://gcc.gnu.org/bugzilla/attachment.cgi?id=33736&action=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.
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
(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 passes 46508 # of unexpected failures 16 # of expected failures 52 # of unsupported tests 214 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: 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/-m64 === # of expected passes 46797 # of unexpected failures 14 # of expected failures 52 # of unsupported tests 76 === gfortran Summary === # of expected passes 93305 # of unexpected failures 30 # of expected failures 104 # of unsupported tests 290 /sw/src/fink.build/gcc50-5.0.0-1000/darwin_objdir/gcc/testsuite/gfortran/../../gfortran version 5.0.0 20141106 (experimental) (GCC) I suspect these regressions may be fixed by adding in the proposed patch from... https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534#c50 which I am currently testing.
> 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.
(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?
(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.
> 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.
(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.
Author: kyukhin Date: Fri Nov 7 20:42:36 2014 New Revision: 217237 URL: https://gcc.gnu.org/viewcvs?rev=217237&root=gcc&view=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
(In reply to Jeffrey A. Law from comment #52) > Igor, can you post the patch from c#50 for official review? Thanks! ping?
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
(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?
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).
(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.
Actually closing.
Author: hjl Date: Tue Nov 25 21:07:43 2014 New Revision: 218062 URL: https://gcc.gnu.org/viewcvs?rev=218062&root=gcc&view=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