[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #24 from iains at gcc dot gnu dot org 2010-07-10 19:48 --- AFAIK this has been cleared for some time now. -- iains at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-17 07:25 --- Although it may be unrelated, pr44163 reports intermittent bootstrap failures related to TLS found or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #22 from dominiq at lps dot ens dot fr 2010-05-17 07:21 --- I have open pr44163 for the testsuite failures on ppc-darwin. Since they are fixed by reverting revision 159371, I think pr44163 is related to this one (if not a duplicate). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #21 from hubicka at ucw dot cz 2010-05-16 17:22 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 > > hmmm.. I don't quite understand this.. > the original ld error was: > ld: codegen problem, can't use rel32 to external symbol > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in > ___cxa_get_globals_fast > > is the loader not entitled to place .data and .text wherever it likes in the > 64bit address space? > ... in any event, potentially, further apart than can be reached by a +/- 31 > bits. > .. what happens when the data size passes 2Gb? There -mcmodel=small/medium/large flag to control this. By default compiler assume that your binary is smaller than 2GB. For PIC we make same assumption and we require loader to keep code and data section together to make RIP relative addressing work. Otherwise it would be of no use ;) Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #20 from iains at gcc dot gnu dot org 2010-05-16 15:15 --- (In reply to comment #19) > Subject: Re: r159371 breaks bootstrap on > x86_64-apple-darwin10 > > > --- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 > > --- > > (In reply to comment #16) > > > leaving off the eh and debug stuff look at >> > > > > > > .text > > > __ZN12_GLOBAL__N_110get_globalEv: > > > LFB100: > > > pushq %rbp > > > LCFI0: > > > movq%rsp, %rbp > > > LCFI1: > > > >> reference a variable relative to the instruction pointer > > > >> is this intended?? seems doomed to > > > >> fail at some point > > > leaq > > > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), > > > %rdi > > > > well, clearly, it's intended - non-emutls code does the same thing (when > > compiled m64). > > However, the point remains that a 32bit offset is going to fail to reach > > variables as soon as the total space occupied > 4Gb > > > > it seems maybe we have a code-gen problem ? > > Well, you know that emults will be bound withtin the same DSO, so you are > safe. > This is small PIC model. hmmm.. I don't quite understand this.. the original ld error was: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast is the loader not entitled to place .data and .text wherever it likes in the 64bit address space? ... in any event, potentially, further apart than can be reached by a +/- 31 bits. .. what happens when the data size passes 2Gb? (having said that - I agree that it doesn't make a lot of sense to see this failure when building libstdc++ ...) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #19 from hubicka at ucw dot cz 2010-05-16 15:00 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 > > > --- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 > --- > (In reply to comment #16) > > leaving off the eh and debug stuff look at >> > > > > .text > > __ZN12_GLOBAL__N_110get_globalEv: > > LFB100: > > pushq %rbp > > LCFI0: > > movq%rsp, %rbp > > LCFI1: > > >> reference a variable relative to the instruction pointer is > > >> this intended?? seems doomed to > > >> fail at some point > > leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), > > %rdi > > well, clearly, it's intended - non-emutls code does the same thing (when > compiled m64). > However, the point remains that a 32bit offset is going to fail to reach > variables as soon as the total space occupied > 4Gb > > it seems maybe we have a code-gen problem ? Well, you know that emults will be bound withtin the same DSO, so you are safe. This is small PIC model. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #18 from iains at gcc dot gnu dot org 2010-05-16 14:26 --- (In reply to comment #13) > (In reply to comment #12) > that doesn't really explain why this should be repeatably affected by the > reversion of 159371.. Yesterday (on an initially failing bootstrap) I applied the suggestion @ comment #2 and the problem cleared. However, I then removed this change and the problem still cleared. the next time this happens to any of the interested parties: could you try make clean-target-libstdc++-v3 make all-target -- and see if the phenomenon is essentially randomly dependent on the layout of the code? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #17 from iains at gcc dot gnu dot org 2010-05-16 13:51 --- (In reply to comment #16) > leaving off the eh and debug stuff look at >> > > .text > __ZN12_GLOBAL__N_110get_globalEv: > LFB100: > pushq %rbp > LCFI0: > movq%rsp, %rbp > LCFI1: > >> reference a variable relative to the instruction pointer is > >> this intended?? seems doomed to > >> fail at some point > leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), > %rdi well, clearly, it's intended - non-emutls code does the same thing (when compiled m64). However, the point remains that a 32bit offset is going to fail to reach variables as soon as the total space occupied > 4Gb it seems maybe we have a code-gen problem ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #16 from iains at gcc dot gnu dot org 2010-05-16 12:56 --- leaving off the eh and debug stuff look at >> .text __ZN12_GLOBAL__N_110get_globalEv: LFB100: pushq %rbp LCFI0: movq%rsp, %rbp LCFI1: >> reference a variable relative to the instruction pointer is this >> intended?? seems doomed to >> fail at some point leaq___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global(%rip), %rdi call___emutls_get_address leave LCFI2: ret LFE100: .globl ___cxa_get_globals_fast ___cxa_get_globals_fast: LFB101: pushq %rbp LCFI3: movq%rsp, %rbp LCFI4: call__ZN12_GLOBAL__N_110get_globalEv leave LCFI5: ret LFE101: .globl ___cxa_get_globals ___cxa_get_globals: LFB102: pushq %rbp LCFI6: movq%rsp, %rbp LCFI7: call__ZN12_GLOBAL__N_110get_globalEv leave LCFI8: ret LFE102: .no_dead_strip ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global .data .align 5 ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global: .quad 16 .quad 8 .quad 0 .quad 0 .section __TEXT,__eh_frame,coalesced,no_toc+strip_static_syms+live_support EH_frame1: .set L$set$0,LECIE1-LSCIE1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #15 from iains at gcc dot gnu dot org 2010-05-16 09:32 --- (In reply to comment #13) > (In reply to comment #12) > > 2/ m64 we get this : > mini-02-sno:gcc-4-6-trunk-build $ otool -rv > x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu > 002c True long True BRANCH False ___emutls_get_address > 0024 True long True SIGNED False > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global > 000c True long True BRANCH False ___emutls_get_address > 0004 True long True SIGNED False > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global > > note ^^^ these are long rather than quad. otool -tv : eh-appl-m64.o: (__TEXT,__text) section __ZN12_GLOBAL__N_110get_globalEv: pushq %rbp 0001movq%rsp,%rbp 0004leaq0x(%rip),%rdi 000bcallq 0x0010 0010leave 0011ret ___cxa_get_globals_fast: 0012pushq %rbp 0013movq%rsp,%rbp 0016callq 0x001b 001bleave 001cret ___cxa_get_globals: 001dpushq %rbp 001emovq%rsp,%rbp 0021callq 0x0026 0026leave 0027ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #14 from iains at gcc dot gnu dot org 2010-05-16 00:56 --- in the compilation of eh_globals.cc: the i686-apple-darwin9 compiler does *not* produce any emutls refs (at m32 or m64) - but rather all the thread stuff is handled via pthread interfaces. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #13 from iains at gcc dot gnu dot org 2010-05-16 00:24 --- (In reply to comment #12) > ld: codegen problem, can't use rel32 to external symbol > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in > ___cxa_get_globals_fast > from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) yep - this is the problem child. 1/ there is a difference between m32 and m64 (I guess, because the linker islands capability is assumed for m64 - and the emitted code is different). 2/ m64 we get this : mini-02-sno:gcc-4-6-trunk-build $ otool -rv x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu 002c True long True BRANCH False ___emutls_get_address 0024 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global 000c True long True BRANCH False ___emutls_get_address 0004 True long True SIGNED False ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global note ^^^ these are long rather than quad. mini-02-sno:gcc-4-6-trunk-build $ nm x86_64-apple-darwin10//libstdc++-v3/libsupc++/.libs/libsupc++.a |grep emu nm: no name list nm: no name list U ___emutls_get_address 0b40 d ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global nm: no name list note ... ^ this is a non-exported symbol. Possibly the reason that this fault comes & goes could be that it depends on how the data segment is laid out. that doesn't really explain why this should be repeatably affected by the reversion of 159371.. I'll try and produce some analysis of the non-working case next .. but the day job needs some attention ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #12 from dominiq at lps dot ens dot fr 2010-05-15 21:50 --- I have looked to my logs and the warnings ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/complex_io.o ... are already in my make log for revision 154675. In fact the key error is the same in the failures I have recorded: ld: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #11 from dominiq at lps dot ens dot fr 2010-05-15 19:27 --- (In reply to comment #10) > Suppressed as by reverting r159371 with... Confirmed at revision 159435. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #10 from howarth at nitro dot med dot uc dot edu 2010-05-15 18:48 --- Suppressed as by reverting r159371 with... diff -uNr gcc-4.6-20100514/gcc/varpool.c gcc-4.6-20100514.hubicka/gcc/varpool.c --- gcc-4.6-20100514/gcc/varpool.c 2010-05-14 19:37:24.0 -0400 +++ gcc-4.6-20100514.hubicka/gcc/varpool.c 2010-05-14 19:45:35.0 -0400 @@ -321,6 +321,13 @@ || node->force_output) return true; + /* ??? If the assembler name is set by hand, it is possible to assemble + the name later after finalizing the function and the fact is noticed + in assemble_name then. This is arguably a bug. */ + if (TARGET_MACHO && DECL_ASSEMBLER_NAME_SET_P (decl) + && TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) +return true; + /* Externally visible variables must be output. The exception is COMDAT variables that must be output only when they are needed. */ if (TREE_PUBLIC (decl) to reintroduce this for darwin only. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #9 from dominiq at lps dot ens dot fr 2010-05-15 15:45 --- The failure is back at revision 159433, now with: ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsputn(wchar_t const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(wchar_t*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/sstream-inst.o 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: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #8 from dominiq at lps dot ens dot fr 2010-05-15 09:43 --- > confirmed on an un-patched tree - I think this can be closed. I would prefer to leave it open until the causes of the breakage and the fix are known. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #7 from iains at gcc dot gnu dot org 2010-05-15 09:29 --- (In reply to comment #6) > The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429 > (now building libjava). confirmed on an un-patched tree - I think this can be closed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #6 from dominiq at lps dot ens dot fr 2010-05-15 08:53 --- The bootstrap failure of x86_64-apple-darwin10 seems gone at revision 159429 (now building libjava). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #5 from iains at gcc dot gnu dot org 2010-05-15 08:47 --- (In reply to comment #3) > The actual failure is: > ld: codegen problem, can't use rel32 to external symbol > ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in > ___cxa_get_globals_fast > from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) which (probably) makes this related to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132 (although I note the "codegen problem, can't use rel32 to external symbol" as distinct from a missing symbol - possibly a misleading err msg of course). > Looking at my logs, I noticed that I successfully built revision 159376 with > the Iain's patch in http://gcc.gnu.org/ml/gcc-patches/2010-05/txt00055.txt , > does it make any sense? that patch should make no difference to this problem, and the problem it was addressing was solved by a different mechanism. I am trying to build 159429 on x86_64 and powerpc64 at present... (it bootstraps on i686). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #4 from hubicka at ucw dot cz 2010-05-15 08:41 --- Subject: Re: r159371 breaks bootstrap on x86_64-apple-darwin10 > It appears that only darwin uses the set_user_assembler_name() call so we > ought to be able to restore the previous behavior with... Does this help and if so, does changing the TREE_SYMBOL_REFERENCED set to mark_decl referenced as you proposed earlier work? Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #3 from dominiq at lps dot ens dot fr 2010-05-15 07:36 --- The actual failure is: libtool: compile: /opt/gcc/build_w/./gcc/xgcc -B/opt/gcc/build_w/./gcc/ -B/opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/bin/ -B/opt/gcc/gcc4.6w/x86_64-a pple-darwin10.3.0/lib/ -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/include -isystem /opt/gcc/gcc4.6w/x86_64-apple-darwin10.3.0/sys-include -DHAVE_CONFIG_H -I. -I../../../work/libgfortran -iquote../../../work/libgfortran/io -I../../../work/libgfortran/../gcc -I../../../work/libgfortran/../gcc/config -I../.././gcc -D_GNU_SOURCE -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -MT fbuf.lo -MD -MP -MF .deps/fbuf.Tpo -c ../../../work/libgfortran/io/fbuf.c -fno-common -DPIC -o .libs/fbuf.old: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/comp lex_io.o ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/complex_io.o ld: warning: cannot export hidden symbol std::ctype::do_widen(char) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctype::do_narrow(char, char) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctype::do_narrow(char const*, char const*, char, char*) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::ctype::do_widen(char const*, char const*, char*) const from .libs/ctype.o ld: warning: cannot export hidden symbol std::underflow_error::~underflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::underflow_error::~underflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::overflow_error::~overflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::overflow_error::~overflow_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::range_error::~range_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::range_error::~range_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::out_of_range::~out_of_range() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::out_of_range::~out_of_range() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::length_error::~length_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::length_error::~length_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::invalid_argument::~invalid_argument() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::invalid_argument::~invalid_argument() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::domain_error::~domain_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::domain_error::~domain_error() from .libs/functexcept.o ld: warning: cannot export hidden symbol std::system_error::system_error(std::error_code) from .libs/functexcept.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsputn(char const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(char*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsputn(wchar_t const*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::xsgetn(wchar_t*, long) from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol __gnu_cxx::stdio_sync_filebuf >::~stdio_sync_filebuf() from .libs/misc-inst.o ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/sstream-inst.o ld: warning: cannot export hidden symbol std::basic_stringbuf, std::allocator >::~basic_stringbuf() from .libs/sstream-inst.o 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: codegen problem, can't use rel32 to external symbol ___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global in ___cxa_get_globals_fast from ../libsupc++/.libs/libsupc++convenience.a(eh_globals.o) collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 Looking at my logs, I noticed that I successfully built revision 159376 with the Iain's patch in http://gcc.g
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-05-15 05:16 --- It appears that only darwin uses the set_user_assembler_name() call so we ought to be able to restore the previous behavior with... Index: gcc/varpool.c === --- gcc/varpool.c (revision 159421) +++ gcc/varpool.c (working copy) @@ -321,6 +321,14 @@ || node->force_output) return true; + + /* ??? If the assembler name is set by hand, it is possible to assemble + the name later after finalizing the function and the fact is noticed + in assemble_name then. This is arguably a bug. */ + if (TARGET_MACHO && DECL_ASSEMBLER_NAME_SET_P (decl) + && TREE_SYMBOL_REFERENCED (DECL_ASSEMBLER_NAME (decl))) +return true; + /* Externally visible variables must be output. The exception is COMDAT variables that must be output only when they are needed. */ if (TREE_PUBLIC (decl) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
[Bug bootstrap/44146] r159371 breaks bootstrap on x86_64-apple-darwin10
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-05-15
02:25 ---
I also noticed that in gcc/config/darwin.c that we have...
/* Do what output_addr_const will do when we actually call it. */
if (SYMBOL_REF_DECL (p->symbol))
mark_decl_referenced (SYMBOL_REF_DECL (p->symbol));
in machopic_validate_stub_or_non_lazy_ptr(). We are no longer synchronized
with output_addr_const() so perhaps this should now be...
/* Do what output_addr_const will do when we actually call it. */
if (SYMBOL_REF_DECL (p->symbol)) {
mark_decl_referenced (SYMBOL_REF_DECL (p->symbol));
assemble_external (SYMBOL_REF_DECL (p->symbol));
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44146
