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 04/30/2010 09:37 AM, Joseph S. Myers wrote:
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.
OK.  Sounds like another reason to move RTEMS to be based
upon arm-eabi not arm-elf. :)

I think effort would be better spent doing that.


  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*.)


Is there any reason to stick with arm-elf as the basis for arm-rtems? It looks like arm-eabi is more generally used and thus more tested and better supported.

--
Joel Sherrill, Ph.D.             Director of Research&  Development
joel.sherrill@OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available             (256) 722-9985



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