Re: GCC Tests For ARM/Neon

[Joel Sherrill <joel dot sherrill at oarcorp dot com>]

Joseph S. Myers wrote:
> On Wed, 6 Aug 2008, Joel Sherrill wrote:
>
>   
> > I see the code for arm_neon_ok.  If I can make that test fail,
> > we are in business.  I tried the cpp part of the following code
> > and it doesn't trip for:
> >
> > arm-rtems4.9-gcc -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c
> >
> > But when I added the "neon_code" function with the
> > assembly code gas didn't like in one of the tests, I
> > get a compilation error.
> >
> > Do you have any better suggestion on how to make
> > arm_neon_ok fail?  Or is this OK to add to the
> > macro?
> >     
>
> You should not need to add the assembly code.  If NEON is not in fact
> effectively enabled then the preprocessor macro should not be defined.
>   

I think GAS is doing the right thing and gcc is sending confusing
information.  Try the test code I posted with an arm compiler.

$ arm-rtems4.9-gcc  -mfpu=neon -mfloat-abi=softfp -mcpu=arm7tdmi -c test_neon.c 
/tmp/ccBzigjD.s: Assembler messages:
/tmp/ccBzigjD.s:13: Error: selected processor does not support `vldr d18,[fp,#-32]'


So with that combination of options gcc defines __ARM_NEON__.
And gas ends up knowing the instructions are invalid.

FWIW with my addition to the arm_neon_ok, it went down to
78 unexpected failures.

http://gcc.gnu.org/ml/gcc-testresults/2008-08/msg00623.html

> --
> Joseph S. Myers
> joseph@codesourcery.com
>   


--
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