Re: armv5b-softfloat with VFP

[Dimitry Andric <dimitry at andric dot com>]

On 2005-04-12 at 17:15:25 J. Scott Merritt wrote:

> - I rebuilt with the gcc-3.4.3-arm-softvfp.patch.bz2 and it eliminated
>      the duplicate copy of the -msoft-float argument.  I've attached the
>      gcc -c -v hello.c output for additional reference.
> - I am still still getting one copy of the -msoft-float argument :(  I'm
>      assuming that this is coming from the gcc spec file, which I
>      have also attached to this message as requested.

I see, indeed the duplicate argument wasn't a problem anyway.  The
spec file looks okay, it should not default to -msoft-float.

However, your "gccverbose" file does not contain the original gcc
command line.  Also, something might be setting CFLAGS or some such
via the environment, etc.  How are you running gcc, from some
Makefile?


> - The arm-vfp.dat file that I am using DURING the crosstool build DOES
>      include the -msoft-float argument, so perhaps that is where it is
>      coming from.  Should -msoft-float be removed from the crosstool
>      build specs as well as from the runtime invocation of gcc ????

I can't find any arm-vfp.dat file in the crosstool distribution, so I
must assume that you made this.  Can you show me the contents?

You should neither specify the -msoft-float option to gcc (via
TARGET_CFLAGS) while building crosstool, nor during a normal
invocation of your target gcc.


> - Yesterday, I reported *LONG* results when attempting to printf 1.0
>       which I assumed meant that I was actually running in vfp format.
>       However, I had the -msoft-float switch set, so I should have
>       been using FPA format.  So why was the printf messing up ???
>       (this was all WITHOUT the glibc fp-byte-ordering patch)

Actually, after researching this further, there is currently no way to
'reverse' the VFP format.  This is because the "-msoft-float" option
doesn't work as I expected... :(

As a result, if you compile with -msoft-float, the following occurs:
+ gcc does assume soft-float, but still *emits* VFP constants
+ gcc passes -mfpu=softvfp to the assembler, so the object files get
  marked with a soft FPA flag
= net result: a soft FPA marked .o file with VFP constants... :/

You can verify this by compiling a .c file with just the following
line (presuming a little endian platform):

  const double test = 1.0;

Compiling with "arm-linux-gcc -S" should result in:

  test:
          .word   0             @ little endian, i.e VFP format
          .word   1072693248

compiling with "arm-linux-gcc -mhard-float -S" should result in:

  test:
          .word   1072693248    @ big endian, i.e FPA format
          .word   0

However, using "arm-linux-gcc -msoft-float -S" should result in the
same output as the first compilation, i.e. VFP format, although the
object file will seem to be soft FPA to the linker.

This situation isn't very okay, and I'll see if I can hack up gcc's
option parsing to fix it, but for now, just *don't* use the
- -msoft-float command line parameter.

Hopefully, the FP format mess should be much clearer with gcc 4.0,
which seems to have a -mfloat-abi=foo option.  I haven't been able to
make time to build a 4.0-based toolchain, however... :/


Difficult to say without more information.  A good way to determine
what your compiler produces is to compile the following with -S
instead of -c (to produce assembly output):


> - When releasing the gcc-3.4.3-arm-softvfp.patch, you said that it
>       needed to be applied AFTER the other 3 patches.  I've just been
>       copying all of the patches to the patch (sub)directory.  Is there
>       some way to force a particular sequence in which they are applied ?

Just rename the patch to zzzz-gcc-3.4.3-arm-softvfp.patch, and hope
your shell sorts the *.patch list. ;)


> - Unfortunately, I'm am under a great deal of schedule pressure and am
>       going to have to drop my quest for a VFP tool chain.  But before
>       doing so, I want to sincerely thank you for all of your help !!!

No problem!  You should always take some time to prepare a toolchain,
as you've just found out. :)  It takes even more to do a full
testsuite afterwards, if you need to satisfy your (or your employer's)
paranoia about the correctness of the result.

Anyway, I'm thinking of doing some toolchain consultancy in the
future, so if you know any good offers... ;)

Cheers,
Dimitry

Attachment: pgp00000.pgp
Description: PGP signature