This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Adding __float128 (i.e TS 18661-3)
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>
- Cc: "libc-alpha at sourceware dot org" <libc-alpha at sourceware dot org>, Steve Munroe <sjmunroe at us dot ibm dot com>
- Date: Thu, 9 Jun 2016 20:35:49 +0000
- Subject: Re: Adding __float128 (i.e TS 18661-3)
- Authentication-results: sourceware.org; auth=none
- References: <572BB6DF dot 7090709 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605052236310 dot 24016 at digraph dot polyomino dot org dot uk> <572CD397 dot 2090405 at linux dot vnet dot ibm dot com> <alpine dot DEB dot 2 dot 20 dot 1605062118090 dot 15027 at digraph dot polyomino dot org dot uk> <c6fdca14-2c5a-4b9a-8dd9-25630c6a100e at linux dot vnet dot ibm dot com>
On Thu, 9 Jun 2016, Paul E. Murphy wrote:
> For any new TS 18661-3 derived type, I propose the
> following new functions and ABI be exposed through
> libm via math.h:
I'd suggest you list the functions consistently, either giving the names
with the f128 included or with some placeholder where it would go.
As-is, you have some listed with "l" and some without it (and in at least
one case, nan, you have it with "f").
> Likewise, the following functions would
> have an equivalent __*_finite ABI entry
> for optimization:
>
> acosh acos asin atan2
> atanh cosh exp10 exp2
> exp fmod hypot j0
> j1 jn log10 log2
> log pow remainder scalb
> sinh sqrt y0 y1
> yn
And lgamma_r. But not scalb, since that's an obsolescent function not
being provided for float128. For tgamma, you have __gammaf128_r_finite
(the interface of providing the sign separately is rather peculiar for
tgamma, but I don't see a strong reason for float128 to be different).
> Macros needing altered in math.h:
>
> From TS 18661-3:
>
> signbit fpclassify isfinite isinf
> isnan
>
> From GNU:
>
> issignaling
Actually, in TS 18661 (that is, in TS 18661-1).
I think the type-generic macros in math.h should work for float128
arguments even if the feature test macros do not enable the *f128 user API
(those in tgmath.h, however, only need to support float128 if the *f128
functions are declared; see the DR in N2029).
Also: macros from complex.h: CMPLX
And tgmath.h updates are needed, remembering that nexttoward needs to stay
working as a type-generic macro for the existing types without breaking
because there are no declarations of nexttowardf128 etc. (as does scalb,
given that we have a type-generic macro for it).
> It is still an open question as to how best to expose this
> API. I think the TS 18661-3 mandated __STDC_WANT_IEC_60559_TYPES_EXT__
> should cover the entire non-GNU API. Likewise, _GNU_SOURCE
With the point to note that __STDC_WANT_IEC_60559_TYPES_EXT__ should
enable visibility of nextupf128, nextdownf128, but the versions of those
functions for float / double / long double require other feature test
macros.
--
Joseph S. Myers
joseph@codesourcery.com