This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: C floating-point bindings as API sources
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Szabolcs Nagy <szabolcs dot nagy at arm dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 9 Nov 2015 15:06:06 +0000
- Subject: Re: C floating-point bindings as API sources
- Authentication-results: sourceware.org; auth=none
- References: <alpine dot DEB dot 2 dot 10 dot 1511091305370 dot 26853 at digraph dot polyomino dot org dot uk> <5640B0D5 dot 8080302 at arm 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