This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
C floating-point bindings as API sources
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Date: Mon, 9 Nov 2015 13:36:32 +0000
- Subject: C floating-point bindings as API sources
- Authentication-results: sourceware.org; auth=none
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