On Wed, Jan 15, 2014 at 08:36:09PM +0000, Charles Baylis wrote:
> Hi James,
>
> This commit (SVN r206045) seems to have introduced a problem when
> compiling multiple source files if a -mcpu option is also present on
> the command line.
>
> This can be reproduced in a arm-unknown-linux-gnueabihf build with any
> source file which use floating point arguments/results. For example
>
> ===== t.c
> float f(void) { return 1.0f;}
> =====
>
> Note that the example command line here specifies t.c twice, although
> any two source files can be used. It is the second compilation which
> triggers the error.
> $
> ~/tools/tools-arm-unknown-linux-gnueabihf-trunk/bin/arm-unknown-linux-gnueabihf-gcc
> -mcpu=cortex-a15 -O2 -c t.c t.c
> t.c: In function âfâ:
> t.c:2:1: sorry, unimplemented: Thumb-1 hard-float VFP ABI
> float f(void) { return 1.0f;}
> ^
Hi Charles,
I can't reproduce exactly the error you see, but I do see a bug
which explains what is happening.
The key can be seen by turning on -v. You will notice that
COLLECT_GCC_OPTIONS for the first invocation of cc1 has a
-mcpu value, but the second invocation does not.
At a guess, your configuration is set with --with-mode=thumb,
and probably has a default architecture of armv4. With the first
invocation of cc1 the -mcpu overrides the default architecture and
you get an armv7-a, hard-float, thumb mode binary. With the
second invocation of cc1 there is no -mcpu and the compiler will try
to build an armv4, hard-float, thumb mode binary - and fail with the
message above.
It should be the case that if we fix BIG_LITTLE_SPEC in
arm.h such that the second invocation of cc1 also gets a -mcpu
value, your issue will be resolved.
I'll work on a fix.
Thanks,
James
