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 Tue, Aug 10, 2004 at 01:38:27AM +0200, Dimitry Andric wrote:

> > This is what I understood of Nicolas' intention:
> > - -mhard-float would give the same behaviour as before the patch
> > - -msoft-float would give FPA behaviour
> > - no option would give VFP
> 
> Yes again.  However, the patch he posted doesn't actually have that
> effect. :)  Please read the comments I added to:
> http://www.andric.com/cross/patches/gcc-3.3.2-arm-softfloat.patch.bz2
> for more information.  Dan already included part of this patch in
> crosstool, but not the -m* options behaviour.

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.  But now I'm having doubts about this, see below.


> > -%{mapcs-float:-mfloat} %{msoft-float:-mno-fpu}"
> > +%{mapcs-float:-mfloat} %{msoft-float:-mfpu=softfpa -mfpu=softvfp}"
> [...]
> > But it didn't seem right to me -- it would seem that when -msoft-float
> > is specified, it evaluates to "-mfpu=softfpa -mfpu=softvfp" (essentially
> > specifying two conflicting options) and otherwise to "", no?
> 
> Indeed this patch doesn't work, because then the assembler will get
> passed 2 different fpu options, and will NOT complain, but only the
> latter (softvfp) will take effect.

Yeah, that's what I experienced.


> > No mention of VFP.  So I guess that FPA is the official cast-in-stone-now
> > standard float ordering format on Linux/ARM.  And perhaps crosstool should
> > indeed generate FPA binaries, if only because of backward compatibility and
> > ABI stuff.  I guess I should have used FPA also from the start.
> 
> That entirely depends on which ARM platform you're targeting.  If you
> want to target some generic distro, it's probably best to simply use
> hardfloat, and let the kernel's FPU emulator handle it, if necessary.
> 
> But if you want maximum floating point performance on a target without
> an FPU, use softvfp.  If you have an existing distro using softfpa,
> use that.

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?

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.

(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... ?)


cheers,
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