Adding __float128 (i.e TS 18661-3)

Adding __float128 (i.e TS 18661-3)

[Paul E. Murphy]

This is a big change. First and foremost, any changes *must* not change
any of the artifacts of the build process, or reduce the effectiveness
of testing. As a corollary, nothing should be exposed until we have
sufficient testing in place to ensure a good, maintainable user
experience.

As Joseph pointed out earlier in [1] and [2] we can't hack and slash our
way into supporting this, but IMO, the consensus driven model doesn't
encourage a large upfront design, as interested parties only seem to
show up at the tail end (during patch submissions). I think we need
consensus on what the end result will look like, and what steps will
get us there.

In addition, I would like to narrow the focus of the discussion to switch
the PPC64 long double type [3] to the more immediate goal of supporting
__float128 in glibc. Arguably, it is the first step towards the larger
goal of changing the underlying implementation of long double on PPC64.
And, other architectures could benefit from having a better supported
binary128 type.

For the initial support, I want to focus on math.h. I suggest the
following should be the minimal set of libm/c functions required to
enable a new TS 18661-3 type:

copysign modf scalbn frexp ldexp sin cos ceil erf expm1 fabs
floor log1p logb nextafter rint scalbln tan tanh fmax fmin fdim trunc
remquo round lround llround nextup nextdown acos acosh asin asinh
atan2 atanh cosh exp exp10 fmod hypot log log2 log10 pow scalbn ilogb
exp2 lgamma_r lgamma

likewise for libc:

strto strto*_l wcsto wcsto*_l strfrom strfrom*_l wcsfrom wcsfrom*_l

Note that the _l suffixed and wcs prefixed functions are not called out
by TS 18661-3, but for the sake of completeness and API symmetry they
ought to be included as gnu extensions.

math.h will add support for the type generic classification macros, and
expose the above if the user defines __STDC_WANT_IEC_60559_TYPES_EXT__
and builds with C11 support. I.e

#define __C11_GENEN(t,f)  \
           t: f,         \
  const    t: f,         \
  volatile t: f,         \
  volatile const t: f,

# if __GNUC_PREREQ (4,6) && !defined __SUPPORT_SNAN__                        \
     && !defined __OPTIMIZE_SIZE__
#  define fpclassify(x) __builtin_fpclassify (FP_NAN, FP_INFINITE,           \
     FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)
# else
#  define fpclassify(x) _Generic( (x),                 \
       __C11_GENEN (float, __fpclassifyf)              \
       __C11_GENEN (double, __fpclassify)              \
       __C11_GENFLT128 (__fpclassifyf128)              \
       default: __FPCLASSIFYL) (x)                     \
# endif

Where __C11_GENFLT128(x) is defined to __C11_GENEN(__float128,x) or
nothing depending on what is supported. This seems slightly better than
extending the existing macros with a GNU specific test.


TS 18661-3 also calls out a number of macros which should be included by
float.h, which would need to be added through GCC. Would adding a new
public header like float-ts18661.h be permissible or should such
definitions be held in private headers for internal usage in the meantime?


I consider the build changes as including the test fixtures. How
exactly the test fixtures are extended is less important, it just needs
to work, and should be easily expandable to future formats.

My proposed design for source structure is:
* sysdeps/ieee754/f128/ holds all the __float128
  (e.g sysdeps/ieee754/f64x-ibm for a _Float64x type based off ibm128)
* sysdeps/ieee754/f128/Makeconfig which defines
  f128-fcts := yes
* sysdeps/{arch}/Makeconfig can optionally declare
  f128-CFLAGS to add extra build options for these files
* matherr and other legacy behavior should stick around.
  Why? This should enable trivial mapping between similar
  ldbl and f128 symbols, saving a little codespace.
* stdio/ and wcsmbs/ will hold analogues to the various
  libc functions called out above, there are a number
  of them.
* Arches desiring the new type would add the new directory
  to their respective Implies file.
* Use the macro __STDC_WANT_IEC_60559_TYPES_EXT__ to control
  enablement of these features inside glibc.

As for source, we should avoid duplication of non-trivial assets, and
that requires refactoring most of the ldbl-128 sources. I'd rather
not use Makefile/script tricks to generate the files. The only truly
ugly thing I've encountered thus far is using a macro to add the
correct suffix (L for long double, Q for __float128).

I.e slip in a header defining something like:

#ifdef __STDC_WANT_IEC_60559_TYPES_EXT__
  /* build ldbl-128 file as a f128 file.  */
  #define GET_F128_MSW64 GET_FLOAT128_MSW64
  #define GET_F128_LSW64 GET_FLOAT128_LSW64
  #define GET_F128_WORDS64 GET_FLOAT128_WORDS64
  #define SET_F128_WORDS64 SET_FLOAT128_WORDS64
  #define F128(_x) _x ## Q
  #define F128_NAME(_n) _n ## f128
  #define weak_alias_f128(_t, _f) weak_alias(_t ## f128, _f ## f128)
  typedef __float128 F128;
#else
  /* build ldbl-128 file normally (as long double).  */
  #define GET_F128_MSW64 GET_LDOUBLE_MSW64
  #define GET_F128_LSW64 GET_LDOUBLE_LSW64
  #define GET_F128_WORDS64 GET_LDOUBLE_WORDS64
  #define SET_F128_WORDS64 SET_LDOUBLE_WORDS64
  #define F128(_x) _x ## L
  #define F128_NAME(_n) _n ## l
  #define weak_alias_f128(_t, _f) weak_alias(_t ## l, _f ## l)
  typedef long double F128;
#endif

And make the necessary changes to the shared lbdl-128 files. Such
changes will be verbose, a little more intrusive, but less
haphazard. Such a strategy could be adopted for future transition
(e.g _Float64x). Likewise, where ldbl is already binary128, the
__float128 symbols can just be aliased to their ldbl analogues.

Thanks,
Paul

[1] https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html
[2] https://sourceware.org/ml/libc-alpha/2015-11/msg00390.html
[3] https://sourceware.org/ml/libc-alpha/2016-04/msg00466.html

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

[Joseph Myers]

On Thu, 5 May 2016, Paul E. Murphy wrote:

> As Joseph pointed out earlier in [1] and [2] we can't hack and slash our
> way into supporting this, but IMO, the consensus driven model doesn't
> encourage a large upfront design, as interested parties only seem to
> show up at the tail end (during patch submissions). I think we need
> consensus on what the end result will look like, and what steps will
> get us there.

A lot of the maybe 50 (rough guess, could be more, unlikely to be much 
less) preparatory patches could actually be justified directly on their 
own merits without the full design - for example, refactoring a particular 
testcase to be easier to instantiate for all floating-point types, thereby 
improving test coverage right now by making that testcase cover all three 
current types rather than just one.

It's true that some of the trickier and larger pieces can only really be 
justified by later patches showing that (for example) a particular 
refactoring is in fact adequate to enable some functionality to be 
extended to more types.  And so it may be easier to produce an up-front 
list of 50 patches that will be needed, than to identify the precise 
internal APIs that patch 28 should contain in order to enable patch 46 to 
extend some functionality to more types (or to submit some such patches 
without submitting a lot of later patches at the same time).

> For the initial support, I want to focus on math.h. I suggest the
> following should be the minimal set of libm/c functions required to
> enable a new TS 18661-3 type:
> 
> copysign modf scalbn frexp ldexp sin cos ceil erf expm1 fabs
> floor log1p logb nextafter rint scalbln tan tanh fmax fmin fdim trunc
> remquo round lround llround nextup nextdown acos acosh asin asinh
> atan2 atanh cosh exp exp10 fmod hypot log log2 log10 pow scalbn ilogb
> exp2 lgamma_r lgamma

I don't know where this list came from, but it's missing, for example, 
sinh and remainder.

In the case of remainder, one of the many preparatory patches would be to 
change the documentation to express that remainder is the primary name and 
drem is a legacy alias, since it presently describes drem as the main 
name.  (drem should *not* get a dremf128 version, remainderf128 is 
sufficient.)

I think the starting point is:

* All functions that both (a) exist for long double in glibc at present, 
and (b) exist for _Float128 in TS 18661-3, should have versions for 
_Float128.  This includes the <complex.h> functions, which you omitted 
from your list (and <tgmath.h> support would be updated for both real and 
complex functions).  (Some preparatory changes would refactor the existing 
complex function implementations so that float / double / long double 
share most of the code, included with different macros defined.  This is 
the sort of thing that's a good idea anyway, independent of adding new 
types, simply to make the functions easier to maintain.)

* All functions that exist for long double in glibc at present, but do not 
exist for _Float128 in TS 18661-3, need a careful analysis.  Some should 
be added for _Float128 (e.g. lgammaf128_r, strtof128_l, as in your list, 
and the Bessel functions, missing from your list).  Some should not (e.g. 
legacy aliases such as drem and gamma should not get _Float128 versions; 
nor should other legacy functions such as scalb even though they would 
need versions added to support it as an alternative long double type).

* The minimum set of new functions from TS 18661-1 that should be added to 
get _Float128 versions is, I think, nextup nextdown strfrom (all on your 
list).  Of course that means earlier patches in the series would add such 
functions (with test coverage, documentation etc.) for all existing 
floating-point types / formats on all architectures, before the _Float128 
versions are added later.  [Other functions that are new in TS 18661 can 
be ignored.]

* Internal functions need careful consideration - but in general, a few 
such functions as __isinff128 will need adding as backing for macros in 
standard headers.  And where we have __*l_finite, I think consistency 
probably means adding __*f128_finite (and working out a clean way to 
handle this in bits/math-finite.h).

* If a function is internal, or if its type involves some standard header 
typedef, then in the case where __float128 and long double have the same 
representation it should *not* get an additional ABI exported from the 
shared libraries as an alias.

Working out the exact set of additions to the ABI and the API is the most 
critical thing to get consensus on.

> #define __C11_GENEN(t,f)  \
>            t: f,         \
>   const    t: f,         \
>   volatile t: f,         \
>   volatile const t: f,

WG14 consensus is that qualifiers are not needed with _Generic (the 
relevant type is always the unqualified type), so they should not be 
included here.  If you want backwards compatibility with non-GCC compilers 
predating that consensus, using unary + in the _Generic call is a much 
less intrusive way of removing qualifiers.

> # if __GNUC_PREREQ (4,6) && !defined __SUPPORT_SNAN__                        \
>      && !defined __OPTIMIZE_SIZE__
> #  define fpclassify(x) __builtin_fpclassify (FP_NAN, FP_INFINITE,           \
>      FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)
> # else
> #  define fpclassify(x) _Generic( (x),                 \

You need to keep supporting compilers without _Generic (although you might 
choose not to have type-generic macros support __float128 with such 
compilers).

> TS 18661-3 also calls out a number of macros which should be included by
> float.h, which would need to be added through GCC. Would adding a new
> public header like float-ts18661.h be permissible or should such
> definitions be held in private headers for internal usage in the meantime?

I think such definitions belong in glibc's internal include/float.h 
(doesn't exist at present), wrapping GCC's float.h and adding any required 
definitions it's missing (possibly via including architecture-specific 
headers).

> I consider the build changes as including the test fixtures. How
> exactly the test fixtures are extended is less important, it just needs
> to work, and should be easily expandable to future formats.

In general, all tests for functions that exist for different 
floating-point types need to be adapted to be type-generic - meaning that 
now they would run for all three types (many such functions are only 
well-tested for one type) and later could run for more.

> My proposed design for source structure is:
> * sysdeps/ieee754/f128/ holds all the __float128
>   (e.g sysdeps/ieee754/f64x-ibm for a _Float64x type based off ibm128)

_Float64x cannot be based on ibm128; it must have IEEE semantics.  It 
could be an alias for __float128, or for x86 extended (I don't see any 
circumstances in which it would be anything else).

> * matherr and other legacy behavior should stick around.
>   Why? This should enable trivial mapping between similar
>   ldbl and f128 symbols, saving a little codespace.

I don't think it should be present for the new functions; that would mean 
e.g. extending legacy __kernel_standard code, which otherwise could remain 
untouched, to handle more types.  I think there's a strong case for 
several of the preliminary patches to deal with deprecation of matherr and 
setting up a new set of macroized wrappers that don't use 
__kernel_standard but handle errno setting directly without reference to 
_LIB_VERSION (on most architectures for existing types maybe they'd only 
be used in static libm unless we decide to add new symbol versions for 
many libm functions, for new architectures and new types they'd be used in 
both shared and static libm).

Given appropriate obsoletion of matherr support for new binaries (meaning 
matherr and _LIB_VERSION become compat symbols, so that in new links libm 
will never refer to the program's copy of them), then of course future 
support for long double on powerpc64le being __float128 would have the 
long double functions not supporting matherr at all (this wouldn't be any 
sort of problematic inconsistency between types for users, because no 
newly linked program could use matherr for any type).

> As for source, we should avoid duplication of non-trivial assets, and
> that requires refactoring most of the ldbl-128 sources. I'd rather
> not use Makefile/script tricks to generate the files. The only truly
> ugly thing I've encountered thus far is using a macro to add the
> correct suffix (L for long double, Q for __float128).

I think macros like that are indeed needed.  It's critical that the 
conversion is scripted, as reviewability of the conversion will mean that 
what's reviewed must be a small clean script that does the conversion and 
maybe a small subsequent fix-up patch, not an enormous patch with massive 
semi-automatic source changes which are effectively unreviewable.  (Of 
course it should also be tested that such a conversion does not change the 
generated code for some existing configuration using ldbl-128.)

There is one way in which the extent of macro use can be reduced.  Given 
that we want to support these APIs, there's a clear case for them existing 
on architectures where long double has binary128 representation, as 
aliases for the long double functions (with the usual issues about 
defining aliases between functions with incompatible types).  What that 
indicates to me is:

* sysdeps/ieee754/float128 (for example) is the primary location of the 
sources for these functions, whenever these functions are present.  It 
defines e.g. __ieee754_<func>f128 or __<func>f128 (depending on the 
function) as internal names, with appropriate *f128 aliases as exported 
names.

* sysdeps/ieee754/ldbl-128 then appears in sysdeps only in the case where 
this format is long double.  It somehow causes the functions to be built 
with additional long double aliases, in the case where this format is long 
double.  Either through lots of small wrappers (in which case 
sysdeps/ieee754/float128 does *not* appear in sysdeps unless it's a 
separate type), or through an alternative implementation of a header that 
gets included by the main implementations (in which case both directories 
would appear in sysdeps, but *l.c files wouldn't get built in that case 
because *f128.c build the *l aliases).  Or some other such approach.

* The functions can then call e.g. __ieee754_logf128 directly; there's no 
need to macroize calls to internal function names, because the internal 
names always use *f128 on all platforms.  Similarly, they can refer 
directly to FLT128_MAX instead of needing to macroize a choice between 
that and LDBL_MAX.  (Some care is still needed about built-in function 
calls, e.g. using __builtin_fabsq versus fabsl, since it's best to get 
that inlined even for __float128, which requires using the __builtin_fabsq 
name in the case - note that's one of the handful of built-in functions 
that should be present in any compiler supported for building glibc with 
float128 support.)  [Eventually, if GCC were to get support for _Float128 
with *f128 constants on all relevant platforms, once a sufficiently recent 
GCC version is required to build glibc everywhere the code could get the 
macros around constants removed and just use *f128 constants directly.  
But that would be several years down the line; for a long time, the code 
will clearly need to use macros for all constants that might be long 
double or __float128, while being made more readable by just using 
unsuffixed constants for at least small integers, maybe cases like 0.5 as 
well.]

* In the case where four versions of functions need to be built, rather 
than extending math/Makefile's existing settings such as

long-m-routines = $(patsubst %_rl,%l_r,$(libm-calls:=l))

I think it would be better to chamge libm-calls to list patterns with a % 
in them, that then get instantiated for any number of suffices (for 
example, it would contain e_lgamma%_r, so removing the need for the 
special %_rl adjustment to be repeated for every format).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

On Thu, 5 May 2016, Joseph Myers wrote:

> Working out the exact set of additions to the ABI and the API is the most 
> critical thing to get consensus on.

I should add: it's also the thing where it's most important to get views 
from a range of glibc developers in the discussion, not simply to rely on 
my views as libm maintainer of appropriate interfaces.  New interfaces, 
especially large sets of new interfaces as here, are an area where a wider 
consensus is desirable than just agreement of the relevant subsystem 
maintainer with lack of specific objections stated by anyone else.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Paul E. Murphy]

On 05/05/2016 06:35 PM, Joseph Myers wrote:
> On Thu, 5 May 2016, Paul E. Murphy wrote:
>> For the initial support, I want to focus on math.h. I suggest the
>> following should be the minimal set of libm/c functions required to
>> enable a new TS 18661-3 type:
>>
>> copysign modf scalbn frexp ldexp sin cos ceil erf expm1 fabs
>> floor log1p logb nextafter rint scalbln tan tanh fmax fmin fdim trunc
>> remquo round lround llround nextup nextdown acos acosh asin asinh
>> atan2 atanh cosh exp exp10 fmod hypot log log2 log10 pow scalbn ilogb
>> exp2 lgamma_r lgamma
> 
> I don't know where this list came from, but it's missing, for example, 
> sinh and remainder.
> 
> In the case of remainder, one of the many preparatory patches would be to 
> change the documentation to express that remainder is the primary name and 
> drem is a legacy alias, since it presently describes drem as the main 
> name.  (drem should *not* get a dremf128 version, remainderf128 is 
> sufficient.)
> 
> I think the starting point is:
> 
> * All functions that both (a) exist for long double in glibc at present, 
> and (b) exist for _Float128 in TS 18661-3, should have versions for 
> _Float128.  This includes the <complex.h> functions, which you omitted 
> from your list (and <tgmath.h> support would be updated for both real and 
> complex functions).  (Some preparatory changes would refactor the existing 
> complex function implementations so that float / double / long double 
> share most of the code, included with different macros defined.  This is 
> the sort of thing that's a good idea anyway, independent of adding new 
> types, simply to make the functions easier to maintain.)

Admittedly, the list was my imperfect attempt to list those functions
which TS 18661-3 declares for which there is a mathematically equivalent
long double function already implemented in libm,.

Likewise, we should implement those which diverge from the base C11
standard in an attempt to improve the removed function. Such functions
may demand more discussion. Anyhow, str{to,from} and their GNU
derivatives must be included with the preliminary support. Likewise
for next{up,down}.

Do you think it is beneficial to exhaustively list each function? 

I intentionally omitted tgmath and complex as I view them as an isolated
chunk of work at this time. They broaden the the scope of the initial
work too much.

I hope to gain consensus that the additions to math.h and stdlib.h,
and their respective ABI in lib{c,m} is sufficient for initial
support of TS 18661.

Likewise, that we can defer work on complex and tgmath while we work
on the base enablement.

> 
> * All functions that exist for long double in glibc at present, but do not 
> exist for _Float128 in TS 18661-3, need a careful analysis.  Some should 
> be added for _Float128 (e.g. lgammaf128_r, strtof128_l, as in your list, 
> and the Bessel functions, missing from your list).  Some should not (e.g. 
> legacy aliases such as drem and gamma should not get _Float128 versions; 
> nor should other legacy functions such as scalb even though they would 
> need versions added to support it as an alternative long double type).
> 
> * The minimum set of new functions from TS 18661-1 that should be added to 
> get _Float128 versions is, I think, nextup nextdown strfrom (all on your 
> list).  Of course that means earlier patches in the series would add such 
> functions (with test coverage, documentation etc.) for all existing 
> floating-point types / formats on all architectures, before the _Float128 
> versions are added later.  [Other functions that are new in TS 18661 can 
> be ignored.]
> 
> * Internal functions need careful consideration - but in general, a few 
> such functions as __isinff128 will need adding as backing for macros in 
> standard headers.  And where we have __*l_finite, I think consistency 
> probably means adding __*f128_finite (and working out a clean way to 
> handle this in bits/math-finite.h).
> 
> * If a function is internal, or if its type involves some standard header 
> typedef, then in the case where __float128 and long double have the same 
> representation it should *not* get an additional ABI exported from the 
> shared libraries as an alias.
> 
> Working out the exact set of additions to the ABI and the API is the most 
> critical thing to get consensus on.
> 
>> #define __C11_GENEN(t,f)  \
>>            t: f,         \
>>   const    t: f,         \
>>   volatile t: f,         \
>>   volatile const t: f,
> 
> WG14 consensus is that qualifiers are not needed with _Generic (the 
> relevant type is always the unqualified type), so they should not be 
> included here.  If you want backwards compatibility with non-GCC compilers 
> predating that consensus, using unary + in the _Generic call is a much 
> less intrusive way of removing qualifiers.

That is an interesting observation.

> 
>> # if __GNUC_PREREQ (4,6) && !defined __SUPPORT_SNAN__                        \
>>      && !defined __OPTIMIZE_SIZE__
>> #  define fpclassify(x) __builtin_fpclassify (FP_NAN, FP_INFINITE,           \
>>      FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)
>> # else
>> #  define fpclassify(x) _Generic( (x),                 \
> 
> You need to keep supporting compilers without _Generic (although you might 
> choose not to have type-generic macros support __float128 with such 
> compilers).

Is it possible to determine if a compiler supports it? GCC enabled some
C11 support in 4.6, but _Generic was added in 4.9. Anyhow, if my history
is correct, GCC supported __float128 in 4.8, so a third alternative is
needed anyways.

Where do we draw the line for TS 18661 support? Must the compiler support
_Generic and __STDC_IEC_60559_TYPES__ >= 201506L, or must it be a GCC
compiler of some minimum version when a user defines 
__STDC_WANT_IEC_60559_TYPES_EXT__?

Let's say glibc + GCC on a given platform supports a hypothetical _Float128
and _Float16 type, and exposes some subset of TS 18661 functionality for
both types. Someone attempts to use a compiler which only supports _Float128,
is there a standards compliant mechanism to prevent exposing the _Float16
machinery without including float.h?


>> My proposed design for source structure is:
>> * sysdeps/ieee754/f128/ holds all the __float128
>>   (e.g sysdeps/ieee754/f64x-ibm for a _Float64x type based off ibm128)
> 
> _Float64x cannot be based on ibm128; it must have IEEE semantics.  It 
> could be an alias for __float128, or for x86 extended (I don't see any 
> circumstances in which it would be anything else).
> 
>> * matherr and other legacy behavior should stick around.
>>   Why? This should enable trivial mapping between similar
>>   ldbl and f128 symbols, saving a little codespace.
> 
> I don't think it should be present for the new functions; that would mean 
> e.g. extending legacy __kernel_standard code, which otherwise could remain 
> untouched, to handle more types.  I think there's a strong case for 
> several of the preliminary patches to deal with deprecation of matherr and 
> setting up a new set of macroized wrappers that don't use 
> __kernel_standard but handle errno setting directly without reference to 
> _LIB_VERSION (on most architectures for existing types maybe they'd only 
> be used in static libm unless we decide to add new symbol versions for 
> many libm functions, for new architectures and new types they'd be used in 
> both shared and static libm).

Those macros only appear to be used by the wrapper functions, so
removing them for the new variants shouldn't be too convoluted without
adding too much bloat to the library?

> 
> Given appropriate obsoletion of matherr support for new binaries (meaning 
> matherr and _LIB_VERSION become compat symbols, so that in new links libm 
> will never refer to the program's copy of them), then of course future 
> support for long double on powerpc64le being __float128 would have the 
> long double functions not supporting matherr at all (this wouldn't be any 
> sort of problematic inconsistency between types for users, because no 
> newly linked program could use matherr for any type).

Would that require versioning all the existing wrappers? It might save
a little space on platforms with a binary128 ldbl. Though, such a change
sounds quite complex by itself.

> 
>> As for source, we should avoid duplication of non-trivial assets, and
>> that requires refactoring most of the ldbl-128 sources. I'd rather
>> not use Makefile/script tricks to generate the files. The only truly
>> ugly thing I've encountered thus far is using a macro to add the
>> correct suffix (L for long double, Q for __float128).
> 
> I think macros like that are indeed needed.  It's critical that the 
> conversion is scripted, as reviewability of the conversion will mean that 
> what's reviewed must be a small clean script that does the conversion and 
> maybe a small subsequent fix-up patch, not an enormous patch with massive 
> semi-automatic source changes which are effectively unreviewable.  (Of 
> course it should also be tested that such a conversion does not change the 
> generated code for some existing configuration using ldbl-128.)
> 
> There is one way in which the extent of macro use can be reduced.  Given 
> that we want to support these APIs, there's a clear case for them existing 
> on architectures where long double has binary128 representation, as 
> aliases for the long double functions (with the usual issues about 
> defining aliases between functions with incompatible types).  What that 
> indicates to me is:
> 
> * sysdeps/ieee754/float128 (for example) is the primary location of the 
> sources for these functions, whenever these functions are present.  It 
> defines e.g. __ieee754_<func>f128 or __<func>f128 (depending on the 
> function) as internal names, with appropriate *f128 aliases as exported 
> names.

Ideally, such a change seems sensible, but ultimately is it not a trivial
naming change which carries a more intensive verification?

Likewise, should these also expose appropriate *_finite symbols too? Or,
is such even permissible under this standard?

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

[Joseph Myers]

On Fri, 6 May 2016, Paul E. Murphy wrote:

> > * All functions that both (a) exist for long double in glibc at present, 
> > and (b) exist for _Float128 in TS 18661-3, should have versions for 
> > _Float128.  This includes the <complex.h> functions, which you omitted 
> > from your list (and <tgmath.h> support would be updated for both real and 
> > complex functions).  (Some preparatory changes would refactor the existing 
> > complex function implementations so that float / double / long double 
> > share most of the code, included with different macros defined.  This is 
> > the sort of thing that's a good idea anyway, independent of adding new 
> > types, simply to make the functions easier to maintain.)
> 
> Admittedly, the list was my imperfect attempt to list those functions
> which TS 18661-3 declares for which there is a mathematically equivalent
> long double function already implemented in libm,.
> 
> Likewise, we should implement those which diverge from the base C11
> standard in an attempt to improve the removed function. Such functions
> may demand more discussion. Anyhow, str{to,from} and their GNU
> derivatives must be included with the preliminary support. Likewise
> for next{up,down}.
> 
> Do you think it is beneficial to exhaustively list each function? 

For the glibc functions (both public API, and internal functions forming 
part of the public ABI because of use from macros etc.) that include long 
double in their interface (so qualify under (a) above), but do not qualify 
under (b) above, I think they should be listed exhaustively, with the 
rationale for whether for each function it is proposed to have a float128 
version.  (That is, functions where long double is involved in the return 
type or a declared argument type.  Not printf / scanf / strfmon functions 
where it's only involved through formats for variable arguments, because 
the TS 18661-3 direction is that no new formats are added for the new 
types; string conversions for such types should be handled through the 
strto* and strfrom* functions.)

Much the same applies to non-function interfaces.  For example, the M_*l 
constants (a GNU extension, whereas the double versions are in POSIX).  
Clearly M_*f128 are needed for internal use in glibc (at least M_PIl is 
used in ldbl-128 code, and more are used in the complex function 
implementations), and I think they should form part of the public API as 
well (for _GNU_SOURCE, on platforms where float128 is supported).

Naturally, non-function interfaces that are in TS 18661-3 and whose long 
double versions are in glibc should all be added and don't need individual 
enumeration for that reason.  That covers at least HUGE_VAL_F128, and 
FP_FAST_FMAF128 if the fused operation is fast.  HUGE_VAL_F128 should be 
defined to (__builtin_huge_valq ()) (given the minimal set of built-in 
functions __builtin_infq, __builtin_huge_valq, __builtin_fabsq, 
__builtin_copysignq, that should be added for powerpc as previously 
discussed to match the set available for x86).

> I intentionally omitted tgmath and complex as I view them as an isolated
> chunk of work at this time. They broaden the the scope of the initial
> work too much.

I think they should be included to provide the most logical coverage of 
float128 support.  (That is, included in the same patch series and 
entering glibc in the same release.  No doubt in separate patches from 
other features, but that's simply a convenience for review of such a big 
patch series.)

tgmath is fiddly, but an early step should be a careful analysis of all 
the various type-generic floating-point macros in glibc, whether in 
<math.h>, <tgmath.h> or internal such as fabs_tg, min_of_type in 
math_private.h.  I suspect it should be possible to produce some common 
infrastructure for use by all such macros, that will handle all the 
different cases of what types and compiler features are available, at 
which point tgmath support for float128 may become more straightforward.  
(Of course, you need to keep watching for WG14 resolution of the issues 
with feature test macros.  The resolution proposed in N2029, to require 
feature test macros to be consistent between header inclusions without 
requiring any diagnostic if they are not, is certainly simpler to 
implement than other versions previously proposed.)

I don't think the complex functions are a particularly hard part, compared 
to the overall complexity of systematically eliminating assumptions 
everywhere about there being three floating-point types that have been 
there since the start of glibc; they could do with being macroized anyway 
to make bug fixes across the three existing types less repetitive.

> >> # if __GNUC_PREREQ (4,6) && !defined __SUPPORT_SNAN__                        \
> >>      && !defined __OPTIMIZE_SIZE__
> >> #  define fpclassify(x) __builtin_fpclassify (FP_NAN, FP_INFINITE,           \
> >>      FP_NORMAL, FP_SUBNORMAL, FP_ZERO, x)
> >> # else
> >> #  define fpclassify(x) _Generic( (x),                 \
> > 
> > You need to keep supporting compilers without _Generic (although you might 
> > choose not to have type-generic macros support __float128 with such 
> > compilers).
> 
> Is it possible to determine if a compiler supports it? GCC enabled some

You'll need conditions in sys/cdefs.h that check __GNUC_PREREQ, and any 
appropriate conditions for other compilers, falling back to 
__STDC_VERSION__ for unknown compilers or those where it implies the 
support is present.

> C11 support in 4.6, but _Generic was added in 4.9. Anyhow, if my history
> is correct, GCC supported __float128 in 4.8, so a third alternative is
> needed anyways.

For powerpc64le, we can take 6.1 as the minimum __float128 version, with 
any support in older versions not being usable.  (For x86_64 it's 4.3, for 
ia64 and 32-bit x86 it's 4.4, but my understanding is you're starting with 
powerpc64le so don't need alternatives only relevant to x86_64 / x86 / 
ia64.  Anyway, __builtin_types_compatible_p and __builtin_choose_expr are 
in all GCC versions supporting __float128 on those platforms, so support 
for handling __float128 there shouldn't be hard when needed.)

[6.1 of course does not have the complex support or the built-in functions 
I listed.  Let's assume they are added for 6.2, and 6.1 may still be good 
enough for compiling programs only using __float128 and not the complex 
type or HUGE_VAL_F128, although not good enough for compiling glibc 
itself.  Really I wouldn't be surprised if existing GCC versions have 
serious bugs in their __float128 support - until glibc is being built with 
float128 support, and testcases run for it, it's hard to have much 
confidence in the robustness of the support when applied to nontrivial 
code.]

> Where do we draw the line for TS 18661 support? Must the compiler support
> _Generic and __STDC_IEC_60559_TYPES__ >= 201506L, or must it be a GCC
> compiler of some minimum version when a user defines 
> __STDC_WANT_IEC_60559_TYPES_EXT__?

Clearly we can't rely on __STDC_IEC_60559_TYPES__.  That would rule out 
all currently existing GCC versions on all platforms.  [I think it would 
be desirable to have proper TS 18661-3 support in GCC - meaning support 
for the new keywords and constant suffixes and float.h macros, etc., 
complete with various subtleties such as keywords existing even if the 
types don't and e.g. _Float32 not being promoted to binary64 in variable 
arguments - and indeed support on a par with existing types - meaning lots 
more including making all the built-in functions have variants for the new 
types for optimization for constant arguments etc. and adapting various 
optimizations that currently assume only three types.  But that's not 
something that could sensibly gate the glibc support, and it's not 
suitable for backporting to GCC 6 branch unlike the minimal complex 
support and the handful of built-in functions I listed.]

So, the functions need to be supported in cases when __float128 is 
supported, but not _Float128 (and given the WANT macro is defined when the 
relevant headers are included, or _GNU_SOURCE is defined before including 
any standard header - feature test macro handling is another thing needing 
careful consideration and design).  Doing so also helps for C++ support.  
It's not clear what shape standard C++ support for such types might take, 
but for decimal floating point it involved classes rather than built-in 
types, with special compiler support to make them ABI-compatible.  So 
__float128 is something available for C++, where as a keyword _Float128 
might not be even when supported for C.

> Let's say glibc + GCC on a given platform supports a hypothetical _Float128
> and _Float16 type, and exposes some subset of TS 18661 functionality for
> both types. Someone attempts to use a compiler which only supports _Float128,
> is there a standards compliant mechanism to prevent exposing the _Float16
> machinery without including float.h?

We need a bits/*.h header (installed) giving information about the formats 
available with the compiler used to build code against the glibc header, 
and the type names (such as long double, __float128 or _Float128) 
corresponding to those formats, where those formats have corresponding 
glibc functions (there's no need for it to describe any formats without 
glibc functions).  Practically, this header might start with just the 
information relevant to __float128 and long double possibly being 
equivalent thereto; it might be hard to design something fully general and 
be confident in it without actually having the compiler support.

> >> * matherr and other legacy behavior should stick around.
> >>   Why? This should enable trivial mapping between similar
> >>   ldbl and f128 symbols, saving a little codespace.
> > 
> > I don't think it should be present for the new functions; that would mean 
> > e.g. extending legacy __kernel_standard code, which otherwise could remain 
> > untouched, to handle more types.  I think there's a strong case for 
> > several of the preliminary patches to deal with deprecation of matherr and 
> > setting up a new set of macroized wrappers that don't use 
> > __kernel_standard but handle errno setting directly without reference to 
> > _LIB_VERSION (on most architectures for existing types maybe they'd only 
> > be used in static libm unless we decide to add new symbol versions for 
> > many libm functions, for new architectures and new types they'd be used in 
> > both shared and static libm).
> 
> Those macros only appear to be used by the wrapper functions, so
> removing them for the new variants shouldn't be too convoluted without
> adding too much bloat to the library?

I don't think new wrapper variants should be complicated.  If the approach 
is that new variants are only used for new formats, new ports and static 
linking, so shared libm never contains both old and new wrappers for the 
same functions, maybe the new variants (appropriately macroized to reduce 
duplication) would #include the old ones under some SHLIB_COMPAT 
conditionals.

> > Given appropriate obsoletion of matherr support for new binaries (meaning 
> > matherr and _LIB_VERSION become compat symbols, so that in new links libm 
> > will never refer to the program's copy of them), then of course future 
> > support for long double on powerpc64le being __float128 would have the 
> > long double functions not supporting matherr at all (this wouldn't be any 
> > sort of problematic inconsistency between types for users, because no 
> > newly linked program could use matherr for any type).
> 
> Would that require versioning all the existing wrappers? It might save
> a little space on platforms with a binary128 ldbl. Though, such a change
> sounds quite complex by itself.

Any symbol versioning for existing wrappers would need careful 
consideration as part of the discussion of the design for obsoleting 
matherr support.  But my inclination is not to add new symbol versions for 
existing functions in existing platforms, as the performance cost of the 
_LIB_VERSION checks and calling __kernel_standard should be fairly small.

> > * sysdeps/ieee754/float128 (for example) is the primary location of the 
> > sources for these functions, whenever these functions are present.  It 
> > defines e.g. __ieee754_<func>f128 or __<func>f128 (depending on the 
> > function) as internal names, with appropriate *f128 aliases as exported 
> > names.
> 
> Ideally, such a change seems sensible, but ultimately is it not a trivial
> naming change which carries a more intensive verification?

Readability and maintainability of source code are important.  That means 
keeping the macroization of these functions down to the unavoidable 
minimum, and thinking carefully about what the optimal arrangements for 
the source code are.

> 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 
__*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 
when you can declare a function yourself mean that most functions 
unavoidably do need duplicate shared library exports.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Florian Weimer]

On 05/06/2016 01:55 AM, Joseph Myers wrote:
> On Thu, 5 May 2016, Joseph Myers wrote:
>
>> Working out the exact set of additions to the ABI and the API is the most
>> critical thing to get consensus on.
>
> I should add: it's also the thing where it's most important to get views
> from a range of glibc developers in the discussion, not simply to rely on
> my views as libm maintainer of appropriate interfaces.  New interfaces,
> especially large sets of new interfaces as here, are an area where a wider
> consensus is desirable than just agreement of the relevant subsystem
> maintainer with lack of specific objections stated by anyone else.

I find it very difficult to comment on this because I don't know how the 
existing ldbl framework works.

I assume it is used to implement a C version of C++ function templates 
such as

   template <class LongDoubleType> int
   vfprintf (FILE *s, const CHAR_T *format, va_list ap);
22
calling other function templates like

   template <class LongDoubleType> int
   __printf_fp_l (FILE *fp, locale_t loc,
                  const struct printf_info *info,
                  const void *const *args);

with a matching LongDoubleType argument.  But I don't know how it works 
in detail, and how unintended spillover between different copies is 
prevented.  (C++ has name mangling for that.)

Florian

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

[Szabolcs Nagy]

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?

> __*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.

> when you can declare a function yourself mean that most functions 
> unavoidably do need duplicate shared library exports.)
> 

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

[Joseph Myers]

On Mon, 9 May 2016, Florian Weimer wrote:

> I assume it is used to implement a C version of C++ function templates such as
> 
>   template <class LongDoubleType> int
>   vfprintf (FILE *s, const CHAR_T *format, va_list ap);

printf/scanf/strfmon-like functions are not part of the present proposal.  
They would need to be added for any subsequent changes that add the option 
for long double being binary128 on powerpc64le.  But the present proposal 
is only about explicit interfaces for binary128.  And since TS 18661-3 
does not have explicit-binary128 variants of printf/scanf, the present 
proposal doesn't either.  (Rather, one preparatory change would add the 
strfrom* functions from TS 18661-1 for the existing floating-point types, 
while later changes would add functions such as strtof128 and strfrom128 
(and ones such as wcstof128 corresponding to wcstold and strtof128_l, 
etc., to be listed in detail as part of the proposal).)

(Similarly, adding a new long double type would mean adding additional 
copies of obsolescent functions such as qecvt and scalbl to handle the new 
type - since those functions are part of the glibc API, supported for new 
links - but those should not get versions that explicitly take float128 
arguments because of their obsolescent nature.)

> with a matching LongDoubleType argument.  But I don't know how it works in
> detail, and how unintended spillover between different copies is prevented.
> (C++ has name mangling for that.)

The existing support for long double being either binary64 or ibm128, on 
powerpc, or either binary64 or binary128, on some other platforms where 
the format changed in the past, involves the wrappers for long double = 
double setting a TLS variable __no_long_double (see 
sysdeps/ieee754/ldbl-opt/nldbl-compat.c).

This has obvious problems, in that it adds to the cases when functions 
such as dprintf are not AS-safe when we'd like them to be AS-safe unless 
dynamic allocation is needed.  It may not be a good design for adding a 
third long double variant.  But it doesn't need addressing for the present 
proposal.

It is *also* the case that, as I previously noted, the 2004-6 changes 
appear to have missed out such compatibility support for the printf-like 
functions in argp.h, err.h and error.h.  A lot of care will be needed to 
make sure the *complete* set of relevant functions is handled in any 
future support for a third long double type.  Again, something for 
followup changes dealing with different long double types, not now.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

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

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

[Steven Munroe]

On Thu, 2016-05-05 at 23:35 +0000, Joseph Myers wrote:
> On Thu, 5 May 2016, Paul E. Murphy wrote:
> 
> > As Joseph pointed out earlier in [1] and [2] we can't hack and slash our
> > way into supporting this, but IMO, the consensus driven model doesn't
> > encourage a large upfront design, as interested parties only seem to
> > show up at the tail end (during patch submissions). I think we need
> > consensus on what the end result will look like, and what steps will
> > get us there.
> 
snip...
>  and later could run for more.
> 
> > My proposed design for source structure is:
> > * sysdeps/ieee754/f128/ holds all the __float128
> >   (e.g sysdeps/ieee754/f64x-ibm for a _Float64x type based off ibm128)
> 
> _Float64x cannot be based on ibm128; it must have IEEE semantics.  It 
> could be an alias for __float128, or for x86 extended (I don't see any 
> circumstances in which it would be anything else).
> 
Yes it seems that _Float64x are specifically defined to enclusively
cover x86 80-bit and seems to exclude the IBM long double.

I assume that you object to using a standard "extented" type in a none
standard way.

How about using an "extendable" type unique to IBM long double.

Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:
https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Floating-Types.html#Floating-Types


Is this acceptable?

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

[Joseph Myers]

On Tue, 7 Jun 2016, Steven Munroe wrote:

> Yes it seems that _Float64x are specifically defined to enclusively
> cover x86 80-bit and seems to exclude the IBM long double.

(And in fact it excludes the m68k variant of ldbl-96 as well, because of 
the required relation between minimum and maximum exponents, although 
otherwise the values of that type follow IEEE semantics.)

> I assume that you object to using a standard "extented" type in a none
> standard way.
> 
> How about using an "extendable" type unique to IBM long double.

That's not what's meant by "extendable" in IEEE 754.  Extendable means 
something like _Float<113, 16383> with IEEE semantics but user control 
over precision and range.  None of the parts of TS 18661 will include any 
support for extendable formats.  I don't envisage any support for such 
formats in GCC or glibc.

> Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:
> https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Floating-Types.html#Floating-Types
> 
> 
> Is this acceptable?

I don't see a need for explicit APIs (i.e., new function, constant etc. 
names) for __ibm128.  Functions for __ibm128 can be accessed by using 
"long double" with -mabi=ibmlongdouble (or whatever option is supported 
for selecting that long double choice) or with a compiler where that is 
the default.  Functions for __float128 can be accessed both with the 
explicit *f128 names associated with that type, and with "long double" for 
a compiler using -mabi=ieeelongdouble or where that is the default (once 
the support is added for __float128 as long double, that is, which will be 
a separate series of changes after the support for *f128 APIs is done).

(Of course, the __ibm128 type name might be used internally where 
necessary in glibc in the implementation of code handling both types.  
E.g., the implementation of type-generic macros such as isinf, in the 
cases where it ends up calling a function, would need to know that 
__ibm128 uses __isinfl while __float128 uses __isinff128, and might well 
use both those type names explicitly.  There's an open question of the 
extent to which type-generic macros should support __ibm128 in the case 
where it's not long double.)

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Steven Munroe]

On Tue, 2016-06-07 at 21:21 +0000, Joseph Myers wrote:
> On Tue, 7 Jun 2016, Steven Munroe wrote:
> 
> > Yes it seems that _Float64x are specifically defined to enclusively
> > cover x86 80-bit and seems to exclude the IBM long double.
> 
> (And in fact it excludes the m68k variant of ldbl-96 as well, because of 
> the required relation between minimum and maximum exponents, although 
> otherwise the values of that type follow IEEE semantics.)
> 
> > I assume that you object to using a standard "extented" type in a none
> > standard way.
> > 
> > How about using an "extendable" type unique to IBM long double.
> 
> That's not what's meant by "extendable" in IEEE 754.  Extendable means 
> something like _Float<113, 16383> with IEEE semantics but user control 
> over precision and range.  None of the parts of TS 18661 will include any 
> support for extendable formats.  I don't envisage any support for such 
> formats in GCC or glibc.
> 
I was thinking primarily of the internals of glibc.

I was not suggesting this would fit under TS 18661 or IEC 60559 or be a
public API. But the mechanics of concurrently building both 128-bit
types are simplified with it.

We will also need alternative (to 'l') file suffixes that we can alias
to for verioning of the old (IBM) long double API.

> > Thankfully Mike Meissner enable both __float128 and __ibm128 in GCC-6.1:
> > https://gcc.gnu.org/onlinedocs/gcc-6.1.0/gcc/Floating-Types.html#Floating-Types
> > 
> > 
> > Is this acceptable?
> 
> I don't see a need for explicit APIs (i.e., new function, constant etc. 
> names) for __ibm128.  Functions for __ibm128 can be accessed by using 
> "long double" with -mabi=ibmlongdouble (or whatever option is supported 
> for selecting that long double choice) or with a compiler where that is 
> the default.  Functions for __float128 can be accessed both with the 
> explicit *f128 names associated with that type, and with "long double" for 
> a compiler using -mabi=ieeelongdouble or where that is the default (once 
> the support is added for __float128 as long double, that is, which will be 
> a separate series of changes after the support for *f128 APIs is done).
> 
My concern is this may work for source files for compile but is awkward
at best for externs and inlined in header files. Either would be
extremely fragile. 

I also have to think about other projects beyond glibc (like boost).

Having a explicit type that always maps to TFmode and another type that
always maps to KFmode simplify things immensely. 


> (Of course, the __ibm128 type name might be used internally where 
> necessary in glibc in the implementation of code handling both types.  
> E.g., the implementation of type-generic macros such as isinf, in the 
> cases where it ends up calling a function, would need to know that 
> __ibm128 uses __isinfl while __float128 uses __isinff128, and might well 
> use both those type names explicitly.  There's an open question of the 
> extent to which type-generic macros should support __ibm128 in the case 
> where it's not long double.)
> 

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

[Joseph Myers]

On Tue, 7 Jun 2016, Steven Munroe wrote:

> We will also need alternative (to 'l') file suffixes that we can alias
> to for verioning of the old (IBM) long double API.

Given that the *l symbols will be for the old API and *f128 symbols for 
the new API (possibly with __*f128 as well for namespace reasons), one 
approach might well be to keep the *l suffixes for the IBM long double 
files.  (This is speculation rather than a definitive design.)

> Having a explicit type that always maps to TFmode and another type that
> always maps to KFmode simplify things immensely. 

Well, you have those types, and you have the ABIs (functions exported from 
libraries) - the question is about corresponding APIs.

For printf/scanf/strfmon-like functions, there are no format strings 
explicitly associated with __ibm128 or __float128, and no APIs explicitly 
associated with a particular choice of long double (in line with the 
choice made in TS 18661 about using strto/strfrom functions) - building 
with the desired choice of long double is the only option.  (There are 
already separate ABIs for these functions for long double = double, except 
for those I identified as having been missed there.)

For other functions, where long double is part of the prototype, we have I 
think consensus on adding explicit __float128 variant APIs for 
non-obsolescent functions (subject to getting detailed consensus on the 
exact list).  I don't think we have consensus on such an API set for 
__ibm128.  A large set of platform-specific APIs like that would be very 
different from any other API sets added to glibc and so would need 
particularly careful consideration by the community.  (Although since such 
APIs wouldn't need extra ABIs, it would be possible for a header outside 
of glibc to provide them for anything that needs them - it just needs a 
series of declarations like "__ibm128 sinibm128 (__ibm128) __asm__ 
("sinl");", to map those APIs to existing entry points.)

I haven't considered the details of what e.g. libstdc++ support should 
look like at the implementation level, but the high level idea of what 
full libstdc++ support for a type should provide the user is 
<https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622>.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Steven Munroe]

On Tue, 2016-06-07 at 22:30 +0000, Joseph Myers wrote:
> On Tue, 7 Jun 2016, Steven Munroe wrote:
> 
> > We will also need alternative (to 'l') file suffixes that we can alias
> > to for verioning of the old (IBM) long double API.
> 
> Given that the *l symbols will be for the old API and *f128 symbols for 
> the new API (possibly with __*f128 as well for namespace reasons), one 
> approach might well be to keep the *l suffixes for the IBM long double 
> files.  (This is speculation rather than a definitive design.)
> 
> > Having a explicit type that always maps to TFmode and another type that
> > always maps to KFmode simplify things immensely. 
> 
> Well, you have those types, and you have the ABIs (functions exported from 
> libraries) - the question is about corresponding APIs.
> 
> For printf/scanf/strfmon-like functions, there are no format strings 
> explicitly associated with __ibm128 or __float128, and no APIs explicitly 
> associated with a particular choice of long double (in line with the 
> choice made in TS 18661 about using strto/strfrom functions) - building 
> with the desired choice of long double is the only option.  (There are 
> already separate ABIs for these functions for long double = double, except 
> for those I identified as having been missed there.)
> 
Again I am primarily concerned with internal glibc interfaces (like
where libm functions internally call other libm functions.

Obviously we have to insure that the __ibm128 functions can call the
appropriate internal API for supporting __ibm128 functions. And the
__float128 functions can call the appropriate internal API for
__float128.

And we would like to avoid compile errors due to missing compiler
options and associated type randomization.

Separately we do use the printf plugin API to support _Decimal Float and
vector printf and provide these to Linux on Power customers. It is fair
to assume that we would provide a 'Q' format plugin for early adopters
of __float128. 

While this does not directly involve glibc, having both types and a
common naming structure is helpful. Here I am looking at a larger
context then glibc and the emerging standards.

> For other functions, where long double is part of the prototype, we have I 
> think consensus on adding explicit __float128 variant APIs for 
> non-obsolescent functions (subject to getting detailed consensus on the 
> exact list).  I don't think we have consensus on such an API set for 
> __ibm128.  A large set of platform-specific APIs like that would be very 
> different from any other API sets added to glibc and so would need 
> particularly careful consideration by the community.  (Although since such 
> APIs wouldn't need extra ABIs, it would be possible for a header outside 
> of glibc to provide them for anything that needs them - it just needs a 
> series of declarations like "__ibm128 sinibm128 (__ibm128) __asm__ 
> ("sinl");", to map those APIs to existing entry points.)
> 
> I haven't considered the details of what e.g. libstdc++ support should 
> look like at the implementation level, but the high level idea of what 
> full libstdc++ support for a type should provide the user is 
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43622>.
> 

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

[Joseph Myers]

On Tue, 7 Jun 2016, Steven Munroe wrote:

> And we would like to avoid compile errors due to missing compiler
> options and associated type randomization.

Compile errors are fine - they make the problem obvious.  What should be 
avoided is cases where code quietly gets built with the wrong type without 
producing errors, but does the wrong thing at runtime.  (And there are a 
range of possible solutions to avoid that, including e.g. #error for the 
wrong long double format in a header used in the ldbl-128ibm code.)

> Separately we do use the printf plugin API to support _Decimal Float and
> vector printf and provide these to Linux on Power customers. It is fair
> to assume that we would provide a 'Q' format plugin for early adopters
> of __float128. 

Sure, and if people want to use scanf like that I think it would be 
reasonable to add scanf hooks support similar to the printf hooks support.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Steven Munroe]

On Wed, 2016-06-08 at 12:33 +0000, Joseph Myers wrote:
> On Tue, 7 Jun 2016, Steven Munroe wrote:
> 
> > And we would like to avoid compile errors due to missing compiler
> > options and associated type randomization.
> 
> Compile errors are fine - they make the problem obvious.  What should be 
> avoided is cases where code quietly gets built with the wrong type without 
> producing errors, but does the wrong thing at runtime.  (And there are a 
> range of possible solutions to avoid that, including e.g. #error for the 
> wrong long double format in a header used in the ldbl-128ibm code.)
> 
There are cases were the compiler will silently convert types (at great
expense in performance) and not tell you anything.

The only way to find these is to look at the generated code. I found
several of these in my early prototypes for this work.

> > Separately we do use the printf plugin API to support _Decimal Float and
> > vector printf and provide these to Linux on Power customers. It is fair
> > to assume that we would provide a 'Q' format plugin for early adopters
> > of __float128. 
> 
> Sure, and if people want to use scanf like that I think it would be 
> reasonable to add scanf hooks support similar to the printf hooks support.
> 

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

[Paul E. Murphy]

Picking up here as a reasonable place to continue the
discussion on ABI and API for float128 (or any future
TS 18661-3 derived type).


For any new TS 18661-3 derived type, I propose the
following new functions and ABI be exposed through
libm via math.h:

	From TS 18661-3:

	acosh acos asinh asin
	atan2 atanh atan cabs
	cacosh cacos carg casinh
	casin catanh catan cbrt
	ccosh ccos ceil cexp
	cimag clog conj copysign
	cosh cos cpow cproj
	creal csinh csin csqrt
	ctanh ctan erfc erf
	exp2 exp expm1 fabs
	fdim floor fma fmax
	fmin fmod frexp hypot
	ilogb ldexp lgamma llrint
	llround log10 log1p log2
	logb log lrint lround
	modf nanf nearbyint nextafter
	pow remainder remquo rint
	round scalbln scalbn 
	sinh sin sqrt tanh
	tan tgamma trunc nextup
	nextdown.

	From GNU:

	exp10 clog10 j0l j1l
	jnl lgamma?_r sincos
	y0 y1 yn

	Implementation support for the ISO C11 7.12.3
	classification macros:

	__finite __fpclassify
	__signbit __issignaling
	__isinf __isnan

	Likewise, the following functions would
	have an equivalent __*_finite ABI entry
	for optimization:

	acosh acos asin atan2
	atanh cosh exp10 exp2
	exp fmod hypot j0
	j1 jn log10 log2
	log pow remainder scalb
	sinh sqrt y0 y1
	yn

Likewise, through libc via stdlib.h:

	From TS 18661-3:

	strto strfrom

	GNU variants for symmetry with both wide
	character strings and existing locale
	support:

	strfrom*_l strto*_l wscto wscto*_l
	wcsfrom wscfrom*_l

Macros needing altered in math.h:

	From TS 18661-3:

	signbit fpclassify isfinite isinf
	isnan

	From GNU:

	issignaling

Macros added via math.h

	From TS 18661-3:
	
	FP_FAST_FMA HUGE_VAL

	From GNU:

	M_E M_LOG2E M_LOG10E M_LN2 
	M_LN10 M_PI M_PI_2 M_PI_4
	M_1_PI M_2_PI M_2_SQRTPI M_SQRT2
	M_SQRT1_2

typedefs via math.h:

	From TS 18661-3:

	_Float128_t


Note, the helper functions for classification macros
would *not* be exported through libc.

Likewise, matherr and _LIB_VERSION would not be supported
on these types. (Yes, this has long double transition
implications)

TS 18661-3 defines a number of new macros which should be
added to float.h.  This is a compiler header, we should
avoid injecting any of these macros into a user compilation.

It is still an open question as to how best to expose this
API.  I think the TS 18661-3 mandated __STDC_WANT_IEC_60559_TYPES_EXT__
should cover the entire non-GNU API. Likewise, _GNU_SOURCE
should only drive inclusion when used with a proper compiler
on a supported platform.

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

[Paul E. Murphy]

On 06/09/2016 03:00 PM, Paul E. Murphy wrote:
> 
> Picking up here as a reasonable place to continue the
> discussion on ABI and API for float128 (or any future
> TS 18661-3 derived type).
> 
> 
> For any new TS 18661-3 derived type, I propose the
> following new functions and ABI be exposed through
> libm via math.h:
> 
> 	From TS 18661-3:
> 
> 	acosh acos asinh asin
> 	atan2 atanh atan cabs
> 	cacosh cacos carg casinh
> 	casin catanh catan cbrt
> 	ccosh ccos ceil cexp
> 	cimag clog conj copysign
> 	cosh cos cpow cproj
> 	creal csinh csin csqrt
> 	ctanh ctan erfc erf
> 	exp2 exp expm1 fabs
> 	fdim floor fma fmax
> 	fmin fmod frexp hypot
> 	ilogb ldexp lgamma llrint
> 	llround log10 log1p log2
> 	logb log lrint lround
> 	modf nanf nearbyint nextafter
> 	pow remainder remquo rint
> 	round scalbln scalbn 
> 	sinh sin sqrt tanh
> 	tan tgamma trunc nextup
> 	nextdown.
> 
> 	From GNU:
> 
> 	exp10 clog10 j0l j1l
> 	jnl lgamma?_r sincos
> 	y0 y1 yn
>

Err, anything taking a _Complex _FloatN argument should only
be declared via complex.h.

Likewise tgmath.h needs updated to correctly select
__float128 functions.

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

[Joseph Myers]

On Thu, 9 Jun 2016, Paul E. Murphy wrote:

> For any new TS 18661-3 derived type, I propose the
> following new functions and ABI be exposed through
> libm via math.h:

I'd suggest you list the functions consistently, either giving the names 
with the f128 included or with some placeholder where it would go.  
As-is, you have some listed with "l" and some without it (and in at least 
one case, nan, you have it with "f").

> 	Likewise, the following functions would
> 	have an equivalent __*_finite ABI entry
> 	for optimization:
> 
> 	acosh acos asin atan2
> 	atanh cosh exp10 exp2
> 	exp fmod hypot j0
> 	j1 jn log10 log2
> 	log pow remainder scalb
> 	sinh sqrt y0 y1
> 	yn

And lgamma_r.  But not scalb, since that's an obsolescent function not 
being provided for float128.  For tgamma, you have __gammaf128_r_finite 
(the interface of providing the sign separately is rather peculiar for 
tgamma, but I don't see a strong reason for float128 to be different).

> Macros needing altered in math.h:
> 
> 	From TS 18661-3:
> 
> 	signbit fpclassify isfinite isinf
> 	isnan
> 
> 	From GNU:
> 
> 	issignaling

Actually, in TS 18661 (that is, in TS 18661-1).

I think the type-generic macros in math.h should work for float128 
arguments even if the feature test macros do not enable the *f128 user API 
(those in tgmath.h, however, only need to support float128 if the *f128 
functions are declared; see the DR in N2029).

Also: macros from complex.h: CMPLX

And tgmath.h updates are needed, remembering that nexttoward needs to stay 
working as a type-generic macro for the existing types without breaking 
because there are no declarations of nexttowardf128 etc. (as does scalb, 
given that we have a type-generic macro for it).

> It is still an open question as to how best to expose this
> API.  I think the TS 18661-3 mandated __STDC_WANT_IEC_60559_TYPES_EXT__
> should cover the entire non-GNU API. Likewise, _GNU_SOURCE

With the point to note that __STDC_WANT_IEC_60559_TYPES_EXT__ should 
enable visibility of nextupf128, nextdownf128, but the versions of those 
functions for float / double / long double require other feature test 
macros.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

On Thu, 9 Jun 2016, Paul E. Murphy wrote:

> Macros added via math.h
> 
> 	From TS 18661-3:
> 	
> 	FP_FAST_FMA HUGE_VAL

I should take this opportunity to give a reminder:

A handful of GCC built-in functions should be added for float128 support, 
and are not currently present in the powerpc port.  You should add 
__builtin_infq __builtin_huge_valq __builtin_fabsq __builtin_copysignq as 
on x86 (or if you wish, use *f128 names instead of *q - *f128 may be 
better as in line with TS 18661-3 naming), plus __builtin_nan* 
__builtin_nans* which I noted in GCC bugs 71241 and 71242 are missing for 
x86 / ia64.

HUGE_VALF128 can then be defined as (__builtin_hugevalf128 ()).

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Paul E. Murphy]

The second draft for a minimum API/ABI for including
new TS 18661-3 derived typed. treat F as a stand-in
for the appropriate suffix of a declaration (i.e F ->
f128 for __float128), and f for macros.


For any new TS 18661-3 derived type, I propose the
following new functions and ABI be exposed through
libm via math.h:

	From TS 18661-3:

        acosF           [1]
        acoshF          [1]
        asinF           [1]
        asinhF
        atan2F          [1]
        atanF
        atanhF          [1]
        copysignF
        cosF
        coshF           [1]
        erfF
        erfcF
        exp2F           [1]
        expF            [1]
        expm1F
        fabsF
        fdimF
        floorF
        fmaF
        fmaxF
        fminF
        fmodF           [1]
        frexpF
        hypotF          [1]
        ilogbF
        ldexpF
        lgammaF         [2]
        llrintF
        llroundF
        log10F          [1]
        log1pF
        log2F           [1]
        logF            [1]
        logbF
        lrintF
        lroundF
        modfF
        nanF
        nearbyintF
        nextafterF
        nextdownF       [3]
        nextupF         [3]
        powF            [1]
        remainderF      [1]
        remquoF
        rintF
        roundF
        scalblnF
        scalbnF
        sinF
        sinhF           [1]
        sqrtF           [1]
        tanF
        tanhF
        tgammaF         [2]
        truncF


	From GNU:

	exp10F		[1]
	j0F		[1]
	j1F		[1]
	jnF		[1]
	lgammaF_r	[1]
	sincosF
	y0F		[1]
	y1F		[1]
	ynF		[1]

	Implementation support for the ISO C11 7.12.3
	classification macros:

        __finiteF
        __fpclassifyF
        __isinfF
        __isnanF
        __issignalingF
        __signbitF


	[1] Likewise, the following functions would
	have an equivalent __*_finite ABI entry
	for optimization:

	[2] like [1] but using inline trickery to
	redirect the call to respective _r version
	of the function to avoid exporting an extra
	symbol.  tgamma will map to
	__gammaF_r_finite to help out future long
	double transitionary work.

	[3] The float, double, and long double
	variants fall under a different feature
	test per TS 18661-1.

Likewise, through libm via complex.h:

	From TS 18661-3:

        cabsF
        cacosF
        cacoshF
        cargF
        casinF
        casinhF
        catanF
        catanhF
        cbrtF
        ccosF
        ccoshF
        ceilF
        cexpF
        cimagF
        clogF
        conjF
        cprojF
        crealF
        csinF
        csinhF
        csqrtF
        ctanF
        ctanhF
        cpowF


	From GNU:

	clog10F

Likewise, through libc via stdlib.h:

	From TS 18661-3:

	strfromF	[4]
	strtoF		[4]


	GNU variants for symmetry with both wide
	character strings and existing locale
	support:

	strfromF_l
	strtoF_l
	wsctoF
	wsctoF_l
	wcsfromF
	wscfromF_l


	[4] The float, double, and long double
	variants fall under a different feature
	test per TS 18661-1.

Macros needing altered in math.h:

	From TS 18661-3:

        fpclassify
        isfinite
        isinf
        isnan
        issignaling     [5]
        signbit


	[5] This macro is defined by TS 18661-1.
	It could be included under a slightly
	different feature test.

Macros added via math.h:

	From TS 18661-3:
	
	FP_FAST_FMAf
	HUGE_VALf


	From GNU:

        M_1_PIf
        M_2_PIf
        M_2_SQRTPIf
        M_Ef
        M_LN10f
        M_LN2f
        M_LOG10Ef
        M_LOG2Ef
        M_PIf
        M_PI_2f
        M_PI_4f
        M_SQRT1_2f
        M_SQRT2f

typedefs via math.h:

	From TS 18661-3:

	_FloatF_t	[6]

	[6] It may be obvious, but only the
	second F is a place holder.

Finally, macros via complex.h:

	From TS 18661-3:

	CMPLXf [7]

	[7] This is called out as a function
	by TS 18661-3, but ISO C11 explicitly
	names their C11 analogues as macros.

Note, the helper functions for classification macros
would *not* be exported through libc.

Likewise, matherr and _LIB_VERSION would not be supported
on these types. (Yes, this has long double transition
implications)

Likewise, tgmath.h will need updated. The selection logic
is implementation defined.  As Joseph points out, some
functions have no TS 18661-3 analogue.  I interpret the
standard to mean such macros retain their behavior prior
to TS 18661. [8]

TS 18661-3 defines a number of new macros which should be
added to float.h.  This is a compiler header, we should
avoid injecting any of these macros into a user
compilation.

It is still an open question as to how best to expose
this API.  I think the TS 18661-3 mandated __STDC_WANT_IEC_60559_TYPES_EXT__
should cover the entire non-GNU API. Likewise,
_GNU_SOURCE should only drive inclusion when used with a
proper compiler on a supported platform.


[8] Does this imply a case whereby
__STDC_WANT_IEC_60559_TYPES_EXT__ is defined, but not __STDC_WANT_IEC_60559_BFP_EXT__ within tgmath.h which
would result in next{up,down}F being declared but not
next{up,down}{f,,l} when using the next{up,down} macros?

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

[Joseph Myers]

On Fri, 10 Jun 2016, Paul E. Murphy wrote:

> 	Implementation support for the ISO C11 7.12.3
> 	classification macros:
> 
>         __finiteF
>         __fpclassifyF
>         __isinfF
>         __isnanF
>         __issignalingF
>         __signbitF

Noting that, if we add support for _FloatN / _FloatNx APIs in future in 
cases where those types are ABI-compatible with another type that already 
has such __* functions, exported aliases are *not* added for those 
internal functions.  For example, if a platform where long double is 
binary128 gains *f128 API support, then the public functions would get 
public *f128 aliases (so they can be used without including system 
headers, as allowed by ISO C), but there would be no __finitef128 alias, 
etc. (and the same would apply to __*_finite in that case).  (Cf. how in 
the case where long double = double, such functions only have *l aliases 
as compat symbols if LDBL_CLASSIFY_COMPAT because they were unnecessarily 
exported on some platforms but new platforms should not have those 
aliases.)

> Likewise, through libm via complex.h:
> 
>         cbrtF
>         ceilF

These are math.h functions, not complex.h functions.

> Macros needing altered in math.h:

>         signbit

Remark on signbit: in GCC 6, __builtin_signbit is type-generic and works 
with sNaNs.  So with GCC 6, you don't actually need __signbitF backing 
functions.  But (a) there would still need to be a new __GNUC_PREREQ (6, 
0) definition of signbit in math.h using type-generic __builtin_signbit 
and (b) __signbitF might still be relevant for working with any non-GNU 
compilers without type-generic __builtin_signbit but with __float128 
support.

> [8] Does this imply a case whereby __STDC_WANT_IEC_60559_TYPES_EXT__ is 
> defined, but not __STDC_WANT_IEC_60559_BFP_EXT__ within tgmath.h which 
> would result in next{up,down}F being declared but not 
> next{up,down}{f,,l} when using the next{up,down} macros?

If __STDC_WANT_IEC_60559_BFP_EXT__ is not defined, <tgmath.h> does not 
define nextup and nextdown macros at all.  See where TS 18661-1 says 
"After 7.25#1, insert the paragraph: [1a] The following identifiers are 
defined as type-generic macros only if __STDC_WANT_IEC_60559_BFP_EXT__ is 
defined as a macro at the point in the source file where <tgmath.h> is 
first included:".  TS 18661-2 modifies this to define some of those macros 
also if __STDC_WANT_IEC_60559_DFP_EXT__ is defined, but that's not 
relevant to glibc; TS 18661-3 does not modify it further, so if you define 
__STDC_WANT_IEC_60559_TYPES_EXT__ but neither 
__STDC_WANT_IEC_60559_BFP_EXT__ nor __STDC_WANT_IEC_60559_DFP_EXT__ then 
you get nextup for the new types but not the old ones, and no nextup 
type-generic macro.

-- 
Joseph S. Myers
joseph@codesourcery.com

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

[Joseph Myers]

On Fri, 10 Jun 2016, Paul E. Murphy wrote:

> TS 18661-3 defines a number of new macros which should be
> added to float.h.  This is a compiler header, we should
> avoid injecting any of these macros into a user
> compilation.

Once my patch <https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01481.html> 
is in GCC, users can get those macros from <float.h> by using GCC 7 or 
later (and defining __STDC_WANT_IEC_60559_TYPES_EXT__ before including 
<float.h>).

I think it's fairly clear what glibc should do for internal use of such 
macros: have an internal-only wrapper include/float.h along the lines of:

#ifndef _ISOMAC
# define __STDC_WANT_IEC_60559_TYPES_EXT__
#endif
#include_next <float.h>
#ifndef _ISOMAC
# include <features.h>
# if !__GNUC_PREREQ (7, 0)
/* Define whatever macros such as FLT128_MAX are needed when building
   glibc, if on a platform where those macros are needed.  */
# endif
#endif

(and the final part would be removed once GCC 7 or later can be presumed 
for building glibc).

(Similarly, everything else in the glibc float128 support should be 
written on the basis that _Float128 type names, f128 constant suffixes 
etc. are the preferred form to use, with __float128, q suffixes etc. being 
fallbacks for older compilers.)

-- 
Joseph S. Myers
joseph@codesourcery.com