Re: problem with crosstool 0.28-pre28 supplied patch for gcc 3.3.[23] softfloat on ARM

[Dimitry Andric <dimitry at andric dot com>]

On 2004-08-10 at 11:16:49 Lennert Buytenhek wrote:

>> > - -mhard-float would give the same behaviour as before the patch
>> > - -msoft-float would give FPA behaviour
>> > - no option would give VFP
[...]
> This is more-or-less the same patch that I submitted to Dan a number
> of times in the past, except that I didn't mess with the multilib
> defaults.

Well, I modified that, since I didn't want the multilib defaults to be
either -msoft-float or -mhard-float.


>> > +%{mapcs-float:-mfloat} %{msoft-float:-mfpu=softfpa -mfpu=softvfp}"
[...]
> Yeah, that's what I experienced.

Unfortunately, there doesn't seem to be any syntax for gcc's spec file
to specify "IF msoft-float THEN -mfpu=softfpa ELSE -mfpu=softvfp".  I
think Nicolas tried this with this hunk:

+#define SUBTARGET_EXTRA_ASM_SPEC "%{!mcpu=*:-mcpu=xscale} \
+  %{mhard-float:-mfpu=fpa} \
+  %{!mhard-float: %{msoft-float:-mfpu=softfpa;:-mfpu=softvfp}}"

But the ;: syntax doesn't work, and isn't documented anywhere in gcc's
sources, AFAICS.


> My concern is this: if I distribute a gcc 3.3.3 that uses softvfp, and
> people then upgrade to gcc 3.4.[01] vanilla, nothing will work anymore
> because gcc 3.4.[01] defaults to FPA on all ELF platforms except
> NetBSD.  Right?

Unless you also patch the gcc 3.4.x distribution to generate softvfp
by default, of course.  Again, this depends on which platform you're
targeting.  If it should be as generic as possible, then you should
probably always use (hardware) FPA, since that is what is historically
used -- a nice "de facto" standard. :)

Note that I'm personally somewhat sceptical about "generic" ARM
toolkits, since there's so much variation in this CPU's world.  You've
got different endiannesses, various different cores, instruction sets,
coprocessors, etc etc.  Since glibc doesn't seem to support multilib,
it seems nearly impossible to create one toolchain that supports it
all.  And even if you could generate multilibs, you can have a *lot*
of permutations!


> In my case, I'm trying to port Fedora Core 2 to a big endian XScale in
> the form of an Intel IXP2400.  I used VFP for the port, and was then
> debating whether I should have used FPA, and now I'm wondering whether
> I should have used hardfloat.

If there are versions of this platform which have FPU hardware, you
should probably go for hard FPA format by default.  If there's no
FPU hardware at all, soft VFP will be a lot faster (for the platform
I've worked with, about a factor 6).


> (This <http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00642.html> page
> seems to suggest that the combinations (fpa,hardfloat) and (vfp,hardfloat)
> also make sense.  So even when I use hardfloat I still have the problem
> of whether to choose FPA of VFP... ?)

In this message, they seem to propose having -mhard-float or
-msoft-float refer to the ABI (i.e passing floats through FPU
registers, as opposed to passing through normal registers or the
stack), and having a separate -mfpu= option for specifying only the
float format, NOT the ABI.

In that case "softvfp", as I used it above, would then be split in
-mfpu=vfp, for the format, and -msoft-float, for the ABI.  I'm not
sure if that would simplify things...

Attachment: pgp00000.pgp
Description: PGP signature