MIPS64 soft-float: missing definition for __floatdidf and friends

[Roger Sayle]

On Wed, 10 May 2006, Richard Sandiford wrote:
> > Because he copied it from ppc64-fp.c which implements floatditf in
> > terms of float*sidf whereas libgcc2 implements it in terms of
> > float*sitf.  But it does not change the fact that we already had a
> > suitable floatditf template in libgcc2 and the patch did not use it.
>
> Then I screwed up.  I'm sorry.

I personally wouldn't be so hasty to condemn the current shift in
philosphy for libgcc.  I've no idea if the GCC project currently
has an official architect for libgcc, but one issue as I see it
is that the current scheme doesn't allow these templates to be used
multiple times, and isn't intuitive as to which symbols will actually
appear in libgcc.a.

So for example, libgcc2.c can't be used to simultaneously define
floatdisf and floatdidf.  The mechanism for probing the host
via libgcc2.h to decide what Wtype and DWtype are once, and then
hoping for the best is fragile.  See PR middle-end/24998.
In a pathological case, a target may require the definitions
of HImode, SImode, DImode and TImode arithmetics, and conversions
to and from HFmode, SFmode, DFmode, TFmode and XFmode.

On possibility is to switch to a scheme similar to the one Ben
used for DFP, where the same source files are compiled multiple
times with different command-line arguments to provide the
customization for different modes.

I think the emerging scheme, which predates my patch, and maybe
even Joseph's before me, leads to a much simpler build system,
similar in philosophy to many FORTRAN applications; with one
function per file, and you compile the files/objects you need.
For one thing, this restructuring may greatly simplifies a
top-level libgcc.


I didn't want to speak previously, as I was hoping that someone with
a clearer vision of what libgcc should be and how it should work would
speak up.  Given noone has, I thought I'd share my thoughts to provoke
folks into giving the problem some thought.  I've no strong vested
interest, I'm just trying to fix bugs in the compiler the best I can.
I'm sure the MIPS maintainers didn't intentionally leave TImode
support out of their backend, and if libgcc worked it wouldn't need
fixing :-)


Does any one have any better or alternative suggestions on how to fix
PRs 24998, 22209, and the current -n64 -msoft-float failures?  To
not like this solution due to its code duplication is perhaps worse
than not having a plan for any other way of fixing these problems.

However, I concede this approach is not ideal.  I'm just truly
curious whether libgcc2.c's original design has reached its limits
or can trivially be tweaked/enhanced to solve these issues.

Roger
--