RFC: TS 18661-4 floating-point interfaces

[Joseph Myers <joseph at codesourcery dot com>]

ISO/IEC TS 18661-4:2015 provides C interfaces for additional 
floating-point operations, mostly from IEEE 754-2008 plus a few additions 
to those.

Building on the provisional consensus from the discussion starting at 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00162.html>, and 
similarly to the proposals for TS 18661-1 
<https://sourceware.org/ml/libc-alpha/2016-06/msg00421.html> and TS 
18661-3 <https://sourceware.org/ml/libc-alpha/2017-01/msg00333.html>, I'd 
like to propose we consider these interfaces appropriate for glibc, as 
follows (which is simpler than the previous proposals because this part of 
the TS only adds functions, not constants or types).  I don't expect to 
implement any of this for glibc 2.27 (I expect to work on the missing 
18661-1 and 18661-3 pieces first).

These features are expected to be proposed for inclusion as optional 
features in C2x (it's only parts 1 and 2 of TS 18661 that are definitely 
intended to be included in C2x, but parts 3, 4 and 5 should at least be 
proposed and considered).

The TS adds the following functions for each supported floating-point 
type.  The proposal is only for these functions, not for anything 
involving decimal floating point, or for the reserved cr* names for 
correctly-rounded functions, or for the reserved c* names for 
corresponding complex functions.

exp2m1 exp10[*] exp10m1 logp1[**] log2p1 log10p1 rsqrt compoundn rootn 
pown powr acospi asinpi atanpi atan2pi cospi sinpi tanpi reduc_sum 
reduc_sumabs reduc_subsq reduc_sumprod scaled_prod scaled_prodsum 
scaled_proddiff

[*] Already in glibc.

[**] Alias of log1p.

Except for reduc_* and scaled_prod* there are also corresponding 
type-generic macros in <tgmath.h>.  (glibc has the exp10 functions but not 
a corresponding type-generic macro.)

All these functions would be defined in libm (including aliases where 
multiple types have the same ABI.)  As usual, when a function is added it 
would be added for all supported floating-point types at the same time 
(and the aliases would be automatic from the use of the common alias 
macros).  In some cases it's likely simple type-generic template versions 
would be used that implement the functions in terms of other functions 
already in libm, with the option for faster and more accurate versions for 
particular types to be added later should someone wish to implement them.

Entries would be added to math/Versions, for all types together, 
notwithstanding that only some glibc configurations support _Float128 or 
_Float64x.  There would be no need to make any special allowance for the 
possibility of some glibc configuration adding support for new types or 
long double formats in future; if any configuration does make such a 
change in future, part of that change would be ensuring it handles all new 
libm functions properly (just as ldbl-opt does not have Versions entries 
for libm functions added since 2.4 and so there would be extra work to do 
for any configuration with long double = double that decides in future to 
add wider long double support).  However, just as with other libm 
functions, there would be libnldbl.a wrappers in ldbl-opt (for compilers 
with 64-bit long double and no __REDIRECT support) unless we've officially 
ceased to support compilers with no __REDIRECT support for using glibc and 
so removed libnldbl.a.

All the usual test and documentation requirements apply for these 
functions.  In the absence of MPFR support for some of the above 
functions, such support would need to be added locally in 
gen-auto-libm-tests (but if present only in a development version of MPFR 
it would be reasonable for gen-auto-libm-tests to depend on such a 
development version; it already depends on a development version of MPC 
for a bug fix not in any released version).

Any comments on this proposal?

-- 
Joseph S. Myers
joseph@codesourcery.com