This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Adding __float128 (i.e TS 18661-3)

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 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]