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
[EMAIL PROTECTED]
--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985
