Re: C floating-point bindings as API sources

[Szabolcs Nagy <szabolcs dot nagy at arm dot com>]

On 09/11/15 13:36, Joseph Myers wrote:
> 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).

i guess that's ok.

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

i think _Float128 should be provided even if the long double
representation is the same (aarch64).

i'm not sure if __float128 has exactly the same semantics as
_Float128. (it would be problematic to support the library
functions before the compiler has the types.)

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

my first reaction to TS 18661 was that it was big and a lot of
implementation work (but at least the semantics become clearer
in a few places).  and i feel that some of the changes are not
useful for most users (who are not doing numeric computation).

new aliases (for _FloatN and _FloatNx) mean a lot of new symbols
and the new functions (or old ones with stricter semantics) can
add a lot of code size.  embedded systems might not be happy
about this.