This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: ARM Neon Tests Failing on non-Neon Target
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
joseph@codesourcery.com