This is the mail archive of the gcc@gcc.gnu.org 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: 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


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