Re: RFC: TS 18661-3 and related floating-point interfaces

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 20 Jan 2017, Tulio Magno Quites Machado Filho wrote:

> I believe there is some overlap between what you're discussing here and
> what we already have implemented or is still implementing.
> I would appreciate if we could keep the communication flowing in order to
> avoid duplicated efforts.

If I add support for any such types before the float128 work is in, I'll 
start with aliases for float, double and ldbl-96 functions to minimize 
overlap.  (Although there may still be some areas where overlap is 
unavoidable, e.g. bits/math-finite.h where my current thinking is it might 
be cleanest to make it into a header more like bits/mathcalls.h, included 
once per floating-point type with appropriate macros defined before 
inclusion.)

Actually there are various cleanups to be done first before adding such 
aliases (which are *not* needed for the float128 work, only for types 
whose functions alias those for other types), e.g. making matherr / 
_LIB_VERSION into compat symbols and arranging for various tests not to be 
disabled for long double when long double functions alias double functions 
(just as _Float* functions shoule be tested even when aliases).

> > * At any given time, there is a set of APIs that should be supported
> >   for any such floating-point type.  Roughly, this consists of
> >   non-obsolescent interfaces that are supported for long double (have
> >   explicit long double versions rather than variadic printf / scanf /
> >   strfmon functions) (plus type-generic macros).  For any (ABI, type)
> >   pair, either all such interfaces should be supported, or none of
> >   them should be supported (modulo the ability of some type-generic
> >   macros to work for types otherwise unknown to glibc by using
> >   type-generic GCC built-in functions).  However, support for a given
> >   type may be added in different glibc versions for different ABIs.
> 
> I believe we need some flexibility in this case.
> It does make sense to have this requirement for established interfaces, but
> new interfaces and new types may be developed in parallel.
> I think there is no point in blocking a new type/interface because it lacks
> support for recently added interface/type.
> IMHO, this is the kind of work that can only be completely synchronized during
> the code freeze.

I think for this sort of thing you can have mini-freezes.  That is, if 
support for a new type is completely ready to go in apart from updates for 
a few recently added functions, freeze adding new floating-point functions 
for a day or two so the support for the new type can be updated and go in, 
and likewise the other way round.

Also, my understanding is that the float128 work has a series of patches 
that allow ABIs to add support for the new type, followed by a patch that 
actually enables it for powerpc64le.  While the first series of patches is 
going in, there are no ABIs that have float128 support enabled, so patches 
in that first series may only contain partial support for a subset of 
functions without deviating from the invariant I described; it's only at 
the point where the switch is flipped for powerpc64le that the set of 
float128 functions for powerpc64le should be complete (and if it's not 
complete then I'd expect some tests to fail to build).

-- 
Joseph S. Myers
joseph@codesourcery.com