C floating-point bindings as API sources

[Joseph Myers <joseph at codesourcery dot com>]

C bindings for IEEE 754-2008 floating point are being developed as ISO/IEC 
TS 18661 (in five parts), some or all of which may also end up in future 
revisions of the C standard (to supersede the existing IEEE 754-1985 
support there) after implementation experience.

Part 1: Binary floating-point arithmetic
  Last public draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1778.pdf
Part 2: Decimal floating-point arithmetic
  Last public draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1912.pdf
Part 3: Interchange and extended types
  Last public draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1945.pdf
Part 4: Supplementary functions
  Last public draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1950.pdf
Part 5: Supplementary attributes
  Latest draft: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1974.pdf
  (this part is still under development)

Following up to 
<https://sourceware.org/ml/libc-alpha/2015-11/msg00115.html>, I'd like to 
propose that we consider the binary floating-point APIs from parts 1, 3 
and 4 appropriate for glibc (mostly libm; libc for functions declared in 
headers such as <stdlib.h> for which existing functions go in libc, or 
where the corresponding existing functions for other types are in libc).


In more detail, this applies to the following interfaces from these parts:

* Part 1: all interfaces.  These are substantially analogous to the IEEE 
754-1985 support added in C99.  We currently support issignaling.

* Part 3: all interfaces not relating to decimal floating-point types and 
formats.  That is, (a) a few encoding conversion functions, (b) aliases 
for existing functions for the _FloatN and _FloatNx type names, subject to 
agreement in the GCC context on the correspondence of those type names to 
already-supported formats, (c) new functions for _Float128 where distinct 
from other floating-point types and sufficiently supported by all GCC 
versions for the relevant configuration supported for building glibc 
(possibly under the nonstandard __float128 name), (d) likewise for 
_Float16.

(c) would apply right now only to x86_64, i386 and ia64; it would apply to 
powerpc hard-float once sufficient compiler support is present (likely GCC 
6) *and* we're ready to require an appropriate compiler version for 
building glibc for those configurations.  I'm not sure (d) would apply to 
any configuration at present; certainly __fp16 support for ARM is too 
limited and different from TS 18661-3 to be usable for such functions, but 
I haven't reviewed the details of the limitations of such support for 
AArch64.

This is explicitly intended to supersede 
<https://sourceware.org/ml/libc-alpha/2004-03/msg00326.html> and 
<https://sourceware.org/ml/libc-alpha/2004-05/msg00055.html> as regards 
the principle of supporting such extra types, now there are standard C 
bindings for them.  It does *not* supersede the latter rejection as 
regards the specifics of the patch; there should be no printf/scanf 
support for such types (the TS 18661 approach is the strfrom / strto 
functions) and generally I don't think there's anything in that patch of 
use to a clean implementation of support for *f128 functions in glibc.

* Part 4: all interfaces not relating to decimal floating-point types.  
That is, the defined interfaces, *not* the cr* names reserved for 
correctly-rounded functions, or the c* names added to the reservations for 
complex functions corresponding to real ones added.  We currently support 
exp10 / exp10f / exp10l.

(Everywhere I exclude particular interfaces or parts above, I'm not saying 
they are necessarily inappropriate, simply that they raise different 
issues and would best be considered separately if someone wishes to add 
them to glibc.)


Actually implementing any of the parts would be a substantial amount of 
work and require more detailed proposals to obtain consensus on various 
aspects of the implementation approach before starting the rest of the 
work.  I've no immediate plans to add these functions; this message is 
simply seeking to establish the high-level consensus about the 
appropriateness of these API sets for glibc.  If someone wishes to add 
particular interfaces in isolation because of a use for a particular 
interface in glibc or its tests (as with the addition of issignaling), 
we'd need to consider if the interfaces in question are a sufficiently 
coherent set for this to be appropriate.

-- 
Joseph S. Myers
joseph@codesourcery.com