On 11/09/2011 10:23 AM, Rainer Orth wrote: > * as doesn't grok the GNU-stack note in config/x86/sjlj.S (likewise osf > as in config/alpha/sjlj.S): > > +#if defined __ELF__ && defined __linux__ > .section .note.GNU-stack, "", @progbits > +#endif
I'll include that in another __ELF__ patch I'm preparing for darwin. > * Sun as apparently cannot handle the branch hints in > config/x86/cacheline.h (jnz,pn): I've just removed them to get further > along fof now, but there needs to be a cleaner way, perhaps an > autoconf test. I should just re-write that in __atomic builtins. > * Even if libitm builds now, all execution tests fail like this: > > ld.so.1: simple-1.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 ] > > If the code ensures at runtime that AVX insns (or SSE for that matter) > are only used if hardware and OS are capable of executing them, one > can deal with this with the equivalent of > gcc/testsuite/gcc.target/i386/clearcap.map when linking libitm.so. Yes, the _M256 entry points will only be used when AVX is used in the compiler. > Besides, we need to make sure that the assembler used is able to > assemble SSE and/or AVX insns before using them. I do worry about building a library version missing symbols though... I suppose we could put them in a different symbol version. If the user's program uses them, they'll include that symbol version and immediately get an ld.so error when moving it to a system that was built incorrectly. That's slightly better than a delayed error at the point that the _M256 gets called and the symbol lookup fails. r~
