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

[Lennert Buytenhek <buytenh at wantstofly dot org>]

On Fri, Aug 13, 2004 at 10:06:56PM +0200, Dimitry Andric 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. :)

I think making all three cases do something different is confusing
enough in itself :)  To me, it would make sense that if you've configured
gcc with --with-float=soft, that passing -msoft-float to the resulting
compiler would then give the same behaviour as passing no soft-float
option at all.

And conversely, with --with-float=hard and -mhard-float.


> 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.

Yeah.  It's better not to have hard-float/soft-float mess with the
float byte ordering.


> > 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.

OK, that makes sense, if you look just at the embedded stuff.

In my case (a port of Fedora Core 2 to the arm/xscale), what would
be the best option, hard-float or soft-float?  I'm inclined to go
for hard-float.  (But that then gives me ICEs when I try to build the
compiler with itself, aiiieee.)


> > 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...

gcc's default would be not to output v5 and v5e and thumb instructions,
I guess.  Right now it will output them even if no mcpu= is specified,
which means that if I build with an arm-unknown-linux-gnu compiler, I
will get armv5 instructions.

Can we just take that bit out?


> > 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.

I see.  Makes sense.  But do you want these files in libgcc also if
you're using hardfloat, or does your patch only add them to libgcc
if softfloat is being used?


thanks,
Lennert

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com