| Message ID | 4EBC0600.70009@redhat.com |
|---|---|
| State | New |
| Headers | show |
On 10 Nov 2011, at 17:12, Richard Henderson wrote: > On 11/10/2011 12:16 AM, Jakub Jelinek wrote: >> On Wed, Nov 09, 2011 at 04:32:58PM -0800, Richard Henderson wrote: >>> Not pretty at all. But given the corresponding irritation in >>> writing assembler >>> wrapper functions, it seems like it's about a wash. >>> >>> Tested with and without HAVE_AS_AVX on x86_64-linux. >> Shouldn't -mavx be also not passed in that case? Then you wouldn't >> need >> to undef __AVX__ and we wouldn't risk gcc doesn't decide to >> optimize memcpy >> or something similar using AVX instructions... >> > You are correct. Thanks for noticing this; I was a bit frazzled > after fighting with autofoo for so long yesterday. > > Tested on x86_64-linux, with avx and with avx forcibly disabled. As of r181262 things are looking much better; all the files build ... ... we now have the following failure linking the library on i686- darwin9 and x86-64-darwin10: libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc -B/GCC/gcc-4-7- trunk-build/./gcc/ -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ -B/ GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-7- install/i686-apple-darwin9/include -isystem /GCC/gcc-4-7-install/i686- apple-darwin9/sys-include -m64 -dynamiclib -Wl,-undefined - Wl,dynamic_lookup -o .libs/libitm.0.dylib .libs/aatree.o .libs/ alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/ beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/ query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/ util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method- gl.o .libs/x86_sse.o .libs/x86_avx.o -m64 -pthread -pthread -m64 - m64 -pthread -install_name /GCC/gcc-4-7-install/lib/gcc/i686-apple- darwin9/4.7.0/x86_64/libitm.0.dylib -compatibility_version 1 - current_version 1.0 -Wl,-single_module ld: codegen problem, can't use rel32 to external symbol in __ITM_malloc from .libs/alloc_c.o collect2: error: ld returned 1 exit status (I think the symbol in question is an __emutls var) ... the objects appear to be correctly x86-64 and the link line has "- m64" ... so there's a codegen issue somewhere, will try an investigate tomorrow. -- The m32 version builds OK on i686-darwin9 (haven't been able to try on Darwin10 .. machine is busy) Iain
On 11/10/2011 03:25 PM, Iain Sandoe wrote: > libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc > -B/GCC/gcc-4-7-trunk-build/./gcc/ > -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ > -B/GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem > /GCC/gcc-4-7-install/i686-apple-darwin9/include -isystem > /GCC/gcc-4-7-install/i686-apple-darwin9/sys-include -m64 -dynamiclib > -Wl,-undefined -Wl,dynamic_lookup -o .libs/libitm.0.dylib .libs/aatree.o > .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o > .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o > .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o > .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o > .libs/method-gl.o .libs/x86_sse.o .libs/x86_avx.o -m64 -pthread -pthread > -m64 -m64 -pthread -install_name > /GCC/gcc-4-7-install/lib/gcc/i686-apple-darwin9/4.7.0/x86_64/libitm.0.dylib > -compatibility_version 1 -current_version 1.0 -Wl,-single_module > ld: codegen problem, can't use rel32 to external symbol in __ITM_malloc > from .libs/alloc_c.o > collect2: error: ld returned 1 exit status > > (I think the symbol in question is an __emutls var) The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _ before the _ITM_malloc? Patrick.
On 10 Nov 2011, at 20:33, Patrick Marlier wrote: > On 11/10/2011 03:25 PM, Iain Sandoe wrote: >> libtool: link: /GCC/gcc-4-7-trunk-build/./gcc/xgcc >> -B/GCC/gcc-4-7-trunk-build/./gcc/ >> -B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ >> -B/GCC/gcc-4-7-install/i686-apple-darwin9/lib/ -isystem >> /GCC/gcc-4-7-install/i686-apple-darwin9/include -isystem >> /GCC/gcc-4-7-install/i686-apple-darwin9/sys-include -m64 -dynamiclib >> -Wl,-undefined -Wl,dynamic_lookup -o .libs/libitm.0.dylib .libs/ >> aatree.o >> .libs/alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o >> .libs/beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o >> .libs/query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o >> .libs/util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o >> .libs/method-gl.o .libs/x86_sse.o .libs/x86_avx.o -m64 -pthread - >> pthread >> -m64 -m64 -pthread -install_name >> /GCC/gcc-4-7-install/lib/gcc/i686-apple-darwin9/4.7.0/x86_64/libitm. >> 0.dylib >> -compatibility_version 1 -current_version 1.0 -Wl,-single_module >> ld: codegen problem, can't use rel32 to external symbol in >> __ITM_malloc >> from .libs/alloc_c.o >> collect2: error: ld returned 1 exit status >> >> (I think the symbol in question is an __emutls var) > > The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _ > before the _ITM_malloc? Actually, I think the missing symbol is ___emutls_v._ZN3GTM12_gtm_thr_tlsE and (although the m32 lib builds OK - the symbol is also missing there). The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup in combination with the missing var. the m32 build succeed - but none of the testsuite runs, because the emutls var is missing (not resolved at load). ---- ... I strongly suspect it might be another manifestation of: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 Has anyone succeeded in building libitm on an emutls target? Iain
On 10 Nov 2011, at 20:43, Iain Sandoe wrote: >> The symbol _ITM_malloc is in libitm. Maybe the problem is an extra >> _ before the _ITM_malloc? > > Actually, I think the missing symbol is > ___emutls_v._ZN3GTM12_gtm_thr_tlsE > and (although the m32 lib builds OK - the symbol is also missing > there). > > The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup FAOD, Is there some reason that this library needs to resolve symbols from some external source at load time? > in combination with the missing var. > the m32 build succeed - but none of the testsuite runs, because the > emutls var is missing (not resolved at load). > > ---- > > ... I strongly suspect it might be another manifestation of: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 This is confirmed - if I hack around that bug, the library builds. There are two other issues I can see so far: 1/ the symbols generated in sjlj.S are not getting their extra "_" (I patched that up temporarily manually) ... which allows some of the testsuite to pass. 2/ The section .tm_clone_table doesn't exist for Darwin leading to assembler errors because ".tm_clone_table" is not a complete section spec for Darwin (that's not too hard to fix - but too late for tonight). Iain
On Thu, Nov 10, 2011 at 11:29:35PM +0000, Iain Sandoe wrote: > > On 10 Nov 2011, at 20:43, Iain Sandoe wrote: >>> The symbol _ITM_malloc is in libitm. Maybe the problem is an extra _ >>> before the _ITM_malloc? >> >> Actually, I think the missing symbol is >> ___emutls_v._ZN3GTM12_gtm_thr_tlsE >> and (although the m32 lib builds OK - the symbol is also missing >> there). >> >> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup > > FAOD, Is there some reason that this library needs to resolve symbols > from some external source at load time? > >> in combination with the missing var. >> the m32 build succeed - but none of the testsuite runs, because the >> emutls var is missing (not resolved at load). >> >> ---- >> >> ... I strongly suspect it might be another manifestation of: >> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50598 > > This is confirmed - if I hack around that bug, the library builds. Iain, I can confirm on x86_64-apple-darwin11 that if I revert r179429... * cgraphunit.c (ipa_passes): Remove unrechable nodes. * lto-streamer-out.c (produce_symtab): Skip unused extern declarations. * ipa.c (cgraph_remove_unreachable_nodes): Do not assume that external functions are reachable when address is taken. * ipa-inline-analysis.c (reset_inline_edge_summary): New * gcc.dg/ipa/ctor-empty-1.c: Update dump file. the linker crash is eliminated when libitm.dylib is linked. Jack > > There are two other issues I can see so far: > > 1/ the symbols generated in sjlj.S are not getting their extra "_" (I > patched that up temporarily manually) ... which allows some of the > testsuite to pass. > > 2/ The section .tm_clone_table doesn't exist for Darwin leading to > assembler errors because ".tm_clone_table" is not a complete section > spec for Darwin > (that's not too hard to fix - but too late for tonight). > > Iain
On 11/10/2011 03:29 PM, Iain Sandoe wrote: >> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup > > FAOD, Is there some reason that this library needs to resolve symbols > from some external source at load time? Not that I know of. I think that's generic libtool giving you that. r~
An update .. in case anyone is following... On 11 Nov 2011, at 00:21, Richard Henderson wrote: > On 11/10/2011 03:29 PM, Iain Sandoe wrote: >>> The m64 build fails because of the -Wl,-undefined -Wl,dynamic_lookup >> >> FAOD, Is there some reason that this library needs to resolve symbols >> from some external source at load time? > > Not that I know of. I think that's generic libtool giving you that. hmmm. Some things are not stacking up. If I: a) patch around PR50596. b) patch sjls.S to include the leading "_" on _ITM_beginTransaction and GTM_longjmp. c) patch varasm to use "__DATA,__tm_clone_table" for the tm_clone_table section name. most of the test-suite runs on x86-64-darwin10 (with fails on clone, memcpy, memset). mem{cpy,set} are caused by a different naming for MAP_ANON (vs. MAP_ANONYMOUS). however, most of the suite fails on darwin9 - with an undefined reference to delete(void*). This is all puzzling me - because the Makefile.am contains # Force link with C, not C++. For now, while we're using C++ we don't # want or need libstdc++. libitm_la_LINK = $(LINK) libitm_la_LDFLAGS = $(libitm_version_info) $(libitm_version_script) \ -no-undefined === however, if I hack the libtool to remove the -Wl,-undefined - Wl,dynamic_lookup ... ... I get : /GCC/gcc-4-7-trunk-build/./gcc/xgcc -B/GCC/gcc-4-7-trunk-build/./gcc/ - B/GCC/gcc-4-7-install/i686-apple-darwin9/bin/ -B/GCC/gcc-4-7-install/ i686-apple-darwin9/lib/ -isystem /GCC/gcc-4-7-install/i686-apple- darwin9/include -isystem /GCC/gcc-4-7-install/i686-apple-darwin9/sys- include -dynamiclib -o .libs/libitm.0.dylib .libs/aatree.o .libs/ alloc.o .libs/alloc_c.o .libs/alloc_cpp.o .libs/barrier.o .libs/ beginend.o .libs/clone.o .libs/eh_cpp.o .libs/local.o .libs/ query.o .libs/retry.o .libs/rwlock.o .libs/useraction.o .libs/ util.o .libs/sjlj.o .libs/tls.o .libs/method-serial.o .libs/method- gl.o .libs/x86_sse.o .libs/x86_avx.o -march=i486 -mtune=i686 - pthread -install_name /GCC/gcc-4-7-install/lib/gcc/i686-apple- darwin9/4.7.0/libitm.0.dylib -compatibility_version 1 -current_version 1.0 -Wl,-single_module Undefined symbols: "operator delete(void*, std::nothrow_t const&)", referenced from: _del_opnt in alloc_cpp.o "operator delete(void*)", referenced from: __ZdlPv$non_lazy_ptr in alloc_cpp.o "___cxa_tm_cleanup", referenced from: GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*) in eh_cpp.o GTM::gtm_thread::revert_cpp_exceptions(GTM::gtm_transaction_cp*) in eh_cpp.o "operator new[](unsigned long)", referenced from: transaction clone for operator new[](unsigned long) in alloc_cpp.o "operator delete[](void*)", referenced from: __ZdaPv$non_lazy_ptr in alloc_cpp.o "___cxa_begin_catch", referenced from: __ITM_cxa_begin_catch in eh_cpp.o "operator delete[](void*, std::nothrow_t const&)", referenced from: _del_opvnt in alloc_cpp.o "operator new[](unsigned long, std::nothrow_t const&)", referenced from: transaction clone for operator new[](unsigned long, std::nothrow_t const&) in alloc_cpp.o "operator new(unsigned long, std::nothrow_t const&)", referenced from: transaction clone for operator new(unsigned long, std::nothrow_t const&) in alloc_cpp.o "operator new(unsigned long)", referenced from: transaction clone for operator new(unsigned long) in alloc_cpp.o "___cxa_allocate_exception", referenced from: __ITM_cxa_allocate_exception in eh_cpp.o "___cxa_throw", referenced from: __ITM_cxa_throw in eh_cpp.o "___cxa_end_catch", referenced from: __ITM_cxa_end_catch in eh_cpp.o ld: symbol(s) not found i.e. a bunch of undefined c++ symbols... (have to do some other stuff for a while.. will try to get back o this later). Iain
Iain Sandoe <developer@sandoe-acoustics.co.uk> writes: > however, most of the suite fails on darwin9 - with an undefined reference > to delete(void*). Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack of weakdef support? http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01426.html At least my weakdef.c testcase also fails to link on i386-apple-darwin9.8.0. Rainer
On 11 Nov 2011, at 14:33, Rainer Orth wrote: > Iain Sandoe <developer@sandoe-acoustics.co.uk> writes: > >> however, most of the suite fails on darwin9 - with an undefined >> reference >> to delete(void*). > > Could this be the same issue I've been seeing on Tru64 UNIX, i.e. lack > of weakdef support? > > http://gcc.gnu.org/ml/gcc-patches/2011-11/msg01426.html > > At least my weakdef.c testcase also fails to link on > i386-apple-darwin9.8.0. It certainly looks similar to point 2 Having discussed this with Mike and tried out some experiments. For Darwin, the symbol can be absent at runtime (and will compare to NULL as per the elf case). However, a) (with two-level namespace) it can't be absent at link time - so there has to be a dummy provided there. b) (If you force flat_namespace ... which IMO would be a Very Bad Thing for the compiler) you can do -flat_namespace -undefined suppress ... ... see the discussion in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51059 - so I think that is quite similar to what your quoted page is saying? However, ... it doesn't explain why x86-64 Darwin10 does NOT seem to experience this (there should be no change in weak semantics AFAIK between 9 and 10) . .. and i686-darwin9 does (unless there's a tool bug in Darwin 9 that this is exposing). ... and the comment stands that the Makefile.am explicitly says "we don't want or need libstdc++" but the missing symbols (in darwin9) seem to be from there. cheers Iain
diff --git a/libitm/ChangeLog b/libitm/ChangeLog index 8aeb589..4fb699e 100644 --- a/libitm/ChangeLog +++ b/libitm/ChangeLog @@ -1,3 +1,10 @@ +2011-11-10 Richard Henderson <rth@redhat.com> + + * config/x86/x86_avx.cc: Remove #undef __AVX__ hack. Tidy comments. + * Makefile.am (x86_avx.lo): Only add -mavx if ARCH_X86_AVX. + * configure.ac (ARCH_X86_AVX): New conditional. + * Makefile.in, configure: Rebuild. + 2011-11-09 Richard Henderson <rth@redhat.com> * acinclude.m4 (LIBITM_CHECK_AS_AVX): New. diff --git a/libitm/Makefile.am b/libitm/Makefile.am index 4578986..b4674a5 100644 --- a/libitm/Makefile.am +++ b/libitm/Makefile.am @@ -48,6 +48,8 @@ libitm_la_SOURCES = \ if ARCH_X86 libitm_la_SOURCES += x86_sse.cc x86_avx.cc x86_sse.lo : XCFLAGS += -msse +endif +if ARCH_X86_AVX x86_avx.lo : XCFLAGS += -mavx endif diff --git a/libitm/Makefile.in b/libitm/Makefile.in index 8816580..7426146 100644 --- a/libitm/Makefile.in +++ b/libitm/Makefile.in @@ -1259,7 +1259,7 @@ uninstall-am: uninstall-dvi-am uninstall-html-am uninstall-info-am \ vpath % $(strip $(search_path)) @ARCH_X86_TRUE@x86_sse.lo : XCFLAGS += -msse -@ARCH_X86_TRUE@x86_avx.lo : XCFLAGS += -mavx +@ARCH_X86_AVX_TRUE@x86_avx.lo : XCFLAGS += -mavx all-local: $(STAMP_GENINSRC) diff --git a/libitm/config/x86/x86_avx.cc b/libitm/config/x86/x86_avx.cc index cd20fe2..6a5e297 100644 --- a/libitm/config/x86/x86_avx.cc +++ b/libitm/config/x86/x86_avx.cc @@ -24,24 +24,20 @@ #include "config.h" -// ??? This is pretty gross, but we're going to frob types of the functions. -// Is this better or worse than just admitting we need to do this in pure -// assembly? - -#ifndef HAVE_AS_AVX -#undef __AVX__ -#endif - #include "libitm_i.h" #include "dispatch.h" extern "C" { #ifndef HAVE_AS_AVX +// If we don't have an AVX capable assembler, we didn't set -mavx on the +// command-line either, which means that libitm.h defined neither this type +// nor the functions in this file. Define the type and unconditionally +// wrap the file in extern "C" to make up for the lack of pre-declaration. typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); #endif -// ??? Re-define the memcpy implementations so that we can frob the +// Re-define the memcpy implementations so that we can frob the // interface to deal with possibly missing AVX instruction set support. #ifdef HAVE_AS_AVX @@ -52,10 +48,10 @@ typedef float _ITM_TYPE_M256 __attribute__((vector_size(32), may_alias)); #else /* Emit vmovaps (%rax),%ymm0. */ #define RETURN(X) \ - asm volatile(".byte 0xc5,0xfc,0x28,0x00" : "=m"(X) : "a"(&X)); + asm volatile(".byte 0xc5,0xfc,0x28,0x00" : "=m"(X) : "a"(&X)) /* Emit vmovaps %ymm0,(%rax); vzeroupper. */ #define STORE(X,Y) \ - asm volatile(".byte 0xc5,0xfc,0x29,0x00,0xc5,0xf8,0x77" : "=m"(X) : "a"(&X)); + asm volatile(".byte 0xc5,0xfc,0x29,0x00,0xc5,0xf8,0x77" : "=m"(X) : "a"(&X)) #define OUTPUT(T) void #define INPUT(T,X) #endif @@ -92,4 +88,4 @@ _ITM_LM256 (const _ITM_TYPE_M256 *ptr) GTM::GTM_LB (ptr, sizeof (*ptr)); } -} +} // extern "C" diff --git a/libitm/configure b/libitm/configure index b30ced1..c0317cc 100644 --- a/libitm/configure +++ b/libitm/configure @@ -603,6 +603,8 @@ LTLIBOBJS LIBOBJS ARCH_FUTEX_FALSE ARCH_FUTEX_TRUE +ARCH_X86_AVX_FALSE +ARCH_X86_AVX_TRUE ARCH_X86_FALSE ARCH_X86_TRUE link_itm @@ -11714,7 +11716,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11717 "configure" +#line 11719 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -11820,7 +11822,7 @@ else lt_dlunknown=0; lt_dlno_uscore=1; lt_dlneed_uscore=2 lt_status=$lt_dlunknown cat > conftest.$ac_ext <<_LT_EOF -#line 11823 "configure" +#line 11825 "configure" #include "confdefs.h" #if HAVE_DLFCN_H @@ -17265,6 +17267,14 @@ else ARCH_X86_FALSE= fi + if test "$libitm_cv_as_avx" = yes; then + ARCH_X86_AVX_TRUE= + ARCH_X86_AVX_FALSE='#' +else + ARCH_X86_AVX_TRUE='#' + ARCH_X86_AVX_FALSE= +fi + if test $enable_linux_futex = yes; then ARCH_FUTEX_TRUE= ARCH_FUTEX_FALSE='#' @@ -17418,6 +17428,10 @@ if test -z "${ARCH_X86_TRUE}" && test -z "${ARCH_X86_FALSE}"; then as_fn_error "conditional \"ARCH_X86\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 fi +if test -z "${ARCH_X86_AVX_TRUE}" && test -z "${ARCH_X86_AVX_FALSE}"; then + as_fn_error "conditional \"ARCH_X86_AVX\" was never defined. +Usually this means the macro was only invoked conditionally." "$LINENO" 5 +fi if test -z "${ARCH_FUTEX_TRUE}" && test -z "${ARCH_FUTEX_FALSE}"; then as_fn_error "conditional \"ARCH_FUTEX\" was never defined. Usually this means the macro was only invoked conditionally." "$LINENO" 5 diff --git a/libitm/configure.ac b/libitm/configure.ac index 7de5cbe..672b712 100644 --- a/libitm/configure.ac +++ b/libitm/configure.ac @@ -272,6 +272,7 @@ fi AC_SUBST(link_itm) AM_CONDITIONAL([ARCH_X86], [test "$ARCH" = x86]) +AM_CONDITIONAL([ARCH_X86_AVX], [test "$libitm_cv_as_avx" = yes]) AM_CONDITIONAL([ARCH_FUTEX], [test $enable_linux_futex = yes]) AC_CONFIG_FILES(Makefile testsuite/Makefile libitm.spec)