Re: Adding __float128 (i.e TS 18661-3)

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 9 May 2016, Szabolcs Nagy wrote:

> On 06/05/16 23:03, Joseph Myers wrote:
> > On Fri, 6 May 2016, Paul E. Murphy wrote:
> >> Likewise, should these also expose appropriate *_finite symbols too? Or,
> >> is such even permissible under this standard?
> > 
> > __*_finite are in the implementation namespace.  So it's always fine to 
> > have those aliases.  *But* the principles of ABI minimization (keeping 
> > down the number of shared library exports) mean that if float128 and long 
> > double functions alias each other (on existing platforms where long double 
> > is binary128), those functions should not have two sets of aliases 
> 
> is it acceptable to alias functions with incompatible types?

Yes, if the ABIs are the same.

If both functions are declared, GCC will complain about creating the 
alias.  There are at least two approaches for such aliasing used in glibc 
right now: (a) the approach used for some long double functions, where the 
long double names don't get declared in the installed headers if _LIBC, 
and (b) #defines before including the headers that declare the 
different-type aliases, so that the header declarations use a different 
name (and then #undef before defining the alias).

Right now, this incompatibility is not actually an issue for float128; 
platforms where long double is binary128 don't define a type name 
__float128 at all, so if we export the *f128 functions there the headers 
will inevitably be declaring them with the long double type.  It's only an 
issue given GCC and header support for _Float128, incompatible with long 
double.  (__float128, where it exists, would become a typedef for 
_Float128 when added.)

> > __*l_finite and __*f128_finite.  The design for math-finite.h needs to 
> > allow for that.  (For normal public functions, if we add *f128 API support 
> > when it's the same format as long double - and I think we should, just 
> > like *f32 *f64 *f32x *f64x variants as applicable - then ISO C rules about 
> 
> i assume gcc does not yet support _Float32 and _Float64
> and *f32 and *f64 will only be added once there is support
> for them.

I think the question of API and ABI additions where aliases can be used in 
the implementation is an open one for the present proposal (in particular, 
should we add *f128 aliases now on platforms where that is the long double 
format?).  (What I think clearly should be done is changes so the ldbl-128 
functions always have __*f128 *internal* names, so they can call each 
other under such names to reduce the extent of macroization needed.  __*l 
aliases would be present to deal with calls from elsewhere in libm, and 
care would need to be taken about avoiding *f128 names when the 
ldbl-128ibm implementations of some functions #include the ldbl-128 
implementations.)

If and when such aliases are added, I don't think the header declarations 
should depend on the compiler used supporting names such as _Float64 - 
just as the header declarations should work with __float128 for *f128, not 
require _Float128 support.

[For platforms supported by glibc, I'd expect _Float32x always to have the 
same ABI as _Float64 / double.  _Float64x could be either Intel extended, 
or binary128, depending on the architecture; in either case, it would 
alias the functions for another type.  It could not be m68k extended 
because that doesn't meet the requirements for an extended format 
regarding the relation between minimum and maximum exponents.]

-- 
Joseph S. Myers
joseph@codesourcery.com