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
