Re: C floating-point bindings as API sources

[Joseph Myers <joseph at codesourcery dot com>]

On Mon, 9 Nov 2015, Szabolcs Nagy wrote:

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

That's item (b) (along with corresponding GCC support, which is a separate 
matter).

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

The semantics are near enough that I do not think supporting the functions 
in glibc should be problematic using __float128.  Yes, a full solution 
involves significant GCC work to have proper _Float128 support (including 
<float.h>, constants ending f128, etc.).  This proposal is about the 
principle of the APIs being appropriate for glibc rather than the detailed 
implementation design.

> in a few places).  and i feel that some of the changes are not
> useful for most users (who are not doing numeric computation).

That's the case for most functions - they are of use to users in a 
particular area.

I should note that I have reviewed the function specifications, and, more 
generally, all parts of TS 18661, in detail during the standardization 
process, as a result of which many problems were fixed (although no doubt 
more issues might show up in the course of implementation work - something 
important to watch out for and raise with WG14 when found).  This is a set 
of APIs that has already had a lot of attention to it with an eye to 
possible implementation issues.

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

Well, most embedded architectures have long double the same as double and 
no __float128 support and would no doubt continue that way with just float 
(= _Float32) and double (= _Float32x = _Float64) support, no _Float128 / 
_Float64x functions at all.  I don't expect _Float128x support anywhere.  
I don't expect most new functions (outside of the full *f128 set where 
those aren't aliases - libquadmath is about 250kB text size on x86_64 so 
one might expect *f128 to add up to a similar amount) to be that large.

-- 
Joseph S. Myers
joseph@codesourcery.com