This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH: Add SSSE3 builtin tests

> Many (all?) of these tests are failing for me on i686-pc-linux-gnu on
> RedHat 4.3, due to the new SSSE3 instructions not being recognized by
> the native assembler, based upon binutils
> /tmp/ccBMbto1.s: Assembler messages:
> /tmp/ccBMbto1.s:66: Error: no such instruction: `pabsd (%eax),%mm0'
> /tmp/ccBMbto1.s:148: Error: no such instruction: `pabsd vals(%ebx),%xmm0'
> FAIL: (test for excess errors)
> We either need to make these compile only tests when assembler support
> isn't available, or do something similar to what we do with
> HAVE_AS_IX86_FFREEP, where the compiler emits .word directives
> for assemblers that don't support the new mnemonics (such as the
> Solaris native assembler and older versions on binutils).

I really don't think hand encoding all those hounders of instructions is
an option. FREEP instruction is a bit special by being missing in x86
ISA specification (as long as I can remember) but being supported by all
CPUs anyway.  So it is sensible to not expect non-GNU assembler to know it.
SSE ISA is however documented and rather complex.

I think we only can declare that for GCC SSExy support an capable
assembler is required.  We can either keep current shape of failing on
unknown instruction (that i think is pretty instructive to end user that
he needs better assembler) in testsuite or arrange HAVE_AS_SSSE3 macro
set by configure that will make __SSSE3___ definition in
TARGET_CPU_CPP_BUILTINS to disappear and conditionalize testsuite tests
on those with friendly #error message within the ???intrin.h header.
Disadvantage of this is that user after discovering that he needs update
on assembler will also need rebuild GCC itself.

H. J., thanks a lot for the tests!  It is great we finally stepped away
from the practice of leaving SSE support almost completely untested.

> I've run into unrelated problems with binutils 2.17, so recommending
> that we force folks to upgrade to a recent binutils purely to run
> these tests might be controversial.
> Is anyone else seeing similar problems?
> Roger
> --

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]