This is the mail archive of the
mailing list for the glibc project.
RFC: TS 18661-4 floating-point interfaces
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Wed, 6 Dec 2017 17:44:54 +0000
- Subject: RFC: TS 18661-4 floating-point interfaces
- Authentication-results: sourceware.org; auth=none
ISO/IEC TS 18661-4:2015 provides C interfaces for additional
floating-point operations, mostly from IEEE 754-2008 plus a few additions
Building on the provisional consensus from the discussion starting at
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
[*] 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