This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC Tests For ARM/Neon
Paul Brook wrote:
On Wednesday 06 August 2008, Joseph S. Myers wrote:
On Wed, 6 Aug 2008, Joel Sherrill wrote:
$ 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.
The compiler generates
.cpu arm7tdmi
.fpu neon
for this example.
Oh, I bet this is a crufty old target that doesn't use the .cpu/.fpu
directives. The gcc driver is almost certainly passing the wrong set of
commandline options to the the assembler. I find it hard to care about
non-eabi targets nowadays.
The binutils version is 2.18 but the target is arm-rtems.
arm-*-rtems* appears to be effectively the same as
arm-*-elf* in binutils and very close in gcc. The
eabi difference in binutils is minor but in gcc, it looks
like a very different configuration.
Mike Stein's arm-elf test results don't show this failure but
I doubt he is adding special CPU arguments when testing and
thus not tripping this.
We chose arm-elf as the starting point years. If we need to
move to arm-eabi as the starting point that is OK. We usually
just chose the CPU-coff or CPU-elf as a starting point
for CPU-rtems.
What is the difference and how will it impact code? I am
worried about our assembly code.
Is there a standard conditional to know the difference if
it matters?
--joel