On Fri, 30 Apr 2010, Joel Sherrill wrote: > This is fairly typical. > > FAIL: gcc.target/arm/neon/vzips8.c (test for excess errors) > Excess errors: > vzips8.s:13: Error: selected processor does not support `fldd d17,[fp,#-40]' [...] > > Would it be better for the arm_neon_ok check to actually put > in an asm for a NEON instruction so it will fail compilation? > I recall us having to do that in a similar situation on another > architecture. > > The root is that we have CPU model CFLAGS which apparently > conflict with neon for this board. So it would be better to make > it fail in arm_neon_ok on a compilation error.
The above errors show that the compiler supports NEON with the given options - they do not conflict with NEON - but that the assembler is out of sync with the compiler. That is, the testcase failures indicate a compiler bug for your target, rather than a testsuite bug: the compiler should be telling the assembler to enable NEON. For EABI, this is done with .cpu, .arch and .fpu directives; for non-EABI you may need to write specs to pass command-line options to the assembler. Creating an arm-rtemseabi or similar target and obsoleting the old-ABI version is what I'd suggest. (Having the target not named *eabi* will make various testcases not run for it; it's unfortunate enough that EABI testcases need to match both arm*-*-*eabi* and arm*-*-symbianelf which is an existing EABI target not matching *eabi*.) -- Joseph S. Myers jos...@codesourcery.com
