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:28:57 Lennert Buytenhek wrote:

> It does all seem rather confusing w.r.t. options:
> - mhard-float is hard FPA
> - msoft-float is soft FPA
> - no option specified is soft VFP

Yes.  I don't see any other way to be able to choose between the 3
alternatives.  You can of course choose another default, for example:

  -mhard-float --> hard FPA
  -msoft-float --> soft VFP
  no option    --> soft FPA

which seems reasonable, however:

  -mhard-float --> soft FPA
  -msoft-float --> soft VFP
  no option    --> hard FPA

is rather confusing. :)  As I've said in another post to this list, it
would probably be better to simply have 3 explicitly different options
for these floating point models.


> Also, the gcc 3.4.[01] default, when no options are specified, is to
> use FPA on all ELF platforms except NetBSD.  Are you sure you want to
> be changing that?

Well, maybe not, depending on which platform you are targeting.  I
think most ARM hardware out there is used without hardware FPU's,
since that keeps the cost down.  Therefore, using the fastest software
FP by default seems reasonable to me.  And you can always specify
-mhard-float if you're actually targeting a platform with FPU.


> BTW, Why are you forcing mcpu=xscale if no mcpu is specified?  This
> would seem like you're introducing a bug, no?

This is simply copied from Nicolas' original patch, here:
http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-October/006436.html

It seems to only choose -mcpu=xscale if you don't specify a -mcpu
option yourself.  I'm not sure what gcc's default is...


> The gcc/config/arm/t-linux hunk might seem submitworthy, but I don't
> know enough about gcc internals to say anything sensible about that.

In gcc 3.4.x, the ieee754-[ds]f.S files, which contain Nicolas' FP
emulation functions, have been added to gcc/config/arm.  (Previously,
they were included in the softfloat patches.)  However, the functions
they export are never included in any library!  Therefore I modified
the t-linux file to put them in libgcc, so they're linked in whenever
needed.

There also seems to be a possibility to put these in a separate
libfloat.a, but I never found out the proper way to have that
generated, either by the gcc build process or the glibc build process.

Attachment: pgp00000.pgp
Description: PGP signature