[PATCH 0/2] Add minimal code for IEEE 128-bit floating point

[Joseph Myers]

On Mon, 26 Oct 2015, Steven Munroe wrote:

> So even if GLIBC is the master for soft-fp, It is expected that the TF
> to KF rename is only in libgcc?

Yes, I think so.  I don't see a benefit to having it in glibc.

Some files only used in libgcc benefit from being present in glibc's copy 
of soft-fp because that way they naturally get included in global changes 
to internal soft-fp interfaces (conversions involving TImode, for 
example).  But that doesn't seem to apply to this sort of Makefile code.

> And it is Ok for any libm <*>f128
> functions that need to call KF versions of soft-fp will link to those
> functions in libgcc?

Yes.  That's just like the existing long double functions calling TFmode 
functions from libgcc; it's nothing unusual at all.  (There are some cases 
where glibc has its own copies of libgcc functions for one reason or 
another, but I don't see any of those reasons applying here.  glibc should 
never need to care what the names of the KFmode libgcc functions are, just 
relying on GCC to generate calls to them.  It may need to know that the 
mode is called KFmode in order to declare complex functions for GCC 
versions supporting the __float128 built-in typedef but not the _Float128 
keyword, but it should be possible to localize that knowledge to a small 
bits/ header.)

> What about any convert functions between TF and KF types (for example
> __extendkftf2) Do those only exist in the platform specific libgcc
> source or do they need to be included in the soft-fp master source?

Only in platform-specific libgcc source.  They're logically more like the 
existing IBM long double support in libgcc/config/rs6000/ibm-ldouble.c 
than the generic conversions between different IEEE formats in the main 
soft-fp code.

-- 
Joseph S. Myers
joseph@codesourcery.com