Richard Henderson <r...@redhat.com> writes:
> On 11/21/2011 05:53 AM, Rainer Orth wrote:
>> The libitm execution tests are currently failing on Solaris 10 and up
>> with Sun as/ld:
>>
>> ld.so.1: cancel.exe: fatal:
>> /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/./libitm/.libs/libitm.so.0:
>> hardware capability (CA_SUNW_HW_1) unsupported: 0x20000000 [ AVX ]
>> FAIL: libitm.c/cancel.c execution test
>>
>> This is the same issue solved by
>> gcc/testsuite/gcc.target/i386/clearcap.map, and the following patch
>> adresses it in the same way:
>>
>> * Detect if the linker used supports -M <map file>.
>>
>> * Use it when linking libitm.so.
>>
>> Right now, it is only possible to clear the hardware capabilities
>> completely, while the new v2 mapfile syntax supports selectively adding
>> and removing capabilities. It is only available in Solaris 11 and
>> Solaris 10 Update 10, though, so I'm restricting us to the v1 syntax for
>> now.
>
> This is only ok if the compiler and library are build with default options.
> If you use --with-arch=corei7-avx then we may well use AVX insns all through
> the library, not just in the one interface that will only be used if the
> user of the library is using avx.
>
> Can you auto-foo this based on CC+CFLAGS? E.g. compile-time tests for the
> various __SSE__ / __AVX__ macros?
My first attempt was to apply the equivalent of ld -r -M clearcap.map to
x86_avx.lo and x86_sse.lo. While this works fine if calling ld -r
directly, you need to get this through libtool and this is where things
start breaking in all sorts of ways:
I tried
$ libtool --mode=link --tag=CC gcc -r -Wl,-M,clearcap.map -o x86_nhc.lo
x86_sse.lo
libtool: link: collect-ld -r -o x86_nhc.o .libs/x86_sse.o
libtool: link: collect-ld -r -o x86_nhc.lo .libs/x86_sse.o
This is of no use at all since -Wl,-M,clearcap.map is lost completely
and I've found no way to get this through libtool at all. This beast
tries to be smart and messes everything up completely. But even if I
could get that part to work, what happens is still wrong: the .lo file
is a real object file now, not the usual text file, so once I try to
link the shared lib, libtool rightly complains. While the libtool docs
claim that this relinking (.lo -> .lo) should work, it obviously does
not, even with libtool 2.2.4 ;-(
So unless I'm overlooking something, I'll have to go the route you
outlined above and check for __SSE__/__AVX__ to make the decision.
Rainer
--
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University
