On 16 Sep 2003, Ian Lance Taylor wrote:

> Ben Harris <bjh21@NetBSD.org> writes:
>
> > Oops.  Serves me right for not checking.  In that case, something in the
> > main program used __fixunsdfsi, which uses __fixdfsi, which pulls in
> > softfloat.o from libc, which tries to redefine __fixunsdfsi, which causes
> > doom.
>
> That may be a gcc misconfiguration.  libgcc is normally complete with
> respect to math operations.  Normally when using soft floating point
> gcc will provide its own soft floating point routines which are then
> included in libgcc.  In this case it seems that it did not.
>
> The gcc/config/sh/t-sh file does include the soft floating point
> support (fp-bit.c).  I don't know which t-* files are being used here,
> though.

Oh.  I hadn't known that GCC came with it's own soft float library.  If
I'd known that I wouldn't have bothered integrating a new version of
SoftFloat into libc.  I kind of assumed that gcc.info's comments about the
need to provide one's own floating-point implementation when using
-msoft-float on ARM were actually true.

Of course, the GCC library doesn't provide rounding-mode control or
exceptions, so it's arguable that our implementation is (temporarily)
better.  Also, we still need SoftFloat for sparc64 "long double" support,
I think.

Of course, using the libgcc version would lose the "no unresolved
references in libc" property.  How much does this matter?

-- 
Ben Harris                                                   <bjh21@NetBSD.org>
Portmaster, NetBSD/acorn26           <URL:http://www.NetBSD.org/Ports/acorn26/>