Re: [3.4 patch] Fix PR16314, undefined reference to `__subdf3' forarm-softfloat

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Mon, 2004-08-30 at 16:47, Daniel Jacobowitz wrote:
> On Mon, Aug 30, 2004 at 07:05:04AM -0700, Dan Kegel wrote:
> > This fixes a problem in all 3.4 gcc's up to and including gcc-3.4.2-20040829
> > Could the arm maintainer have a look, and possibly apply (if possible, 
> > before 3.4.2)?
> > I'm not qualified to say whether it's correct, but I will say it gets
> > rid of the problem for my toolchain builds, and doesn't prevent plain old
> > arm toolchains from building.  I use it in http://kegel.com/crosstool
> > Thanks!
> 
> See PR 14352.
> 
> I also have discussed this at length with Richard Earnshaw, and he
> doesn't like adding them - I'll let him explain why not, since I don't
> fully understand the reasons.

And PR 16314 is an excellent example of why we shouldn't just add these
functions as things stand.  The EP9312 has its own floating point
hardware (Maverick Crunch) and uses a hard-float abi similar in style to
that used on the FPA (but with different registers of course). 
Unfortunately, it doesn't have a floating-point division instruction and
we need a library routine to support that.

As things stand the compiler would expect the library routine to return
values in the Maverick floating-point return register.  None of the
existing soft-float support routines do that.  So just dropping them in
would move this problem from a 'can't build' bug to a 'built incorrectly
and misbehaves at runtime' bug.  Of the two, I know which I'd prefer.

If we used the soft-float ABI unconditionally for all libcall support
functions, then we could just drop in the support functions: but, as
I've explained before, we need to do some preliminary work before we can
get to that point.

R.