------- 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
0000002c True long True BRANCH False ___emutls_get_address
00000024 True long True SIGNED False
___emutls_v._ZZN12_GLOBAL__N_110get_globalEvE6global
0000000c True long True BRANCH False ___emutls_get_address
00000004 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
0000000000000b40 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
