Re: [RFC] tgmath.h and math/Makefile refactor

["Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>]

On 06/06/2016 09:22 AM, Joseph Myers wrote:
> On Fri, 3 Jun 2016, Joseph Myers wrote:
> 
>> I don't think the division into ts-18661-calls and others is a good idea 
>> at all.  It may make sense to have a separate variable for obsolete 
>> functions that should not be added for new types, but most of the
> 
> To expand further on this:
> 
> Even where a function should not be exported for new types, there's still 
> the issue of providing a version of it for long double if you support an 
> alternative long double type.
> 
> For example, say you support long double being binary128 on powerpc64le 
> (my understanding being that that's considered a desirable subsequent step 
> after the support for explicit *f128 APIs is done).  Then the headers 
> would remap calls to long double functions to call the *f128 functions 
> instead[*].  And while for example scalb, taking two floating-point 
> arguments, is obsolescent and so no scalbf128 explicit API should be 
> provided, scalbl is still a supported API so should be provided for the 
> new long double variant - meaning that in that case you do still need to 
> build a version of scalb for binary128, just export it under a name such 
> as __scalbf128, not with a public scalbf128 name at API or ABI level.

So should we be asking what functions that exist for the C99 types
should *not* be exported for float128.  Looking at the current
ABI, the existing functions fall into a small set of categories:

Functions defined by TS 18661-3 which are already included within
glibc: 

	acosh acos asinh asin
	atan2 atanh atan cabs
	cacosh cacos carg casinh
	casin catanh catan cbrt
	ccosh ccos ceil cexp
	cimag clog conj copysign
	cosh cos cpow cproj
	creal csinh csin csqrt
	ctanh ctan erfc erf
	exp2 exp expm1 fabs
	fdim floor fma fmax
	fmin fmod frexp hypot
	ilogb ldexp lgamma llrint
	llround log10 log1p log2
	logb log lrint lround
	modf nanf nearbyint nextafter
	pow remainder remquo rint
	round scalbln scalbn significand
	sinh sin sqrt tanh
	tan tgamma trunc

Likewise, GNU specific ABI/API which is used to support the
above which should be exported and guarded with _GNU_SOURCE:

	exp10 clog10 j0l j1l
	jnl lgamma?_r pow10
	sincos y0 y1 yn

Likewise, helper functions for the classification macros,
and likely support macros for transitioning long double:

	__finite __fpclassify
	__signbit __issignaling

Likewise, the following would have a matching
__*_finite ABI:

	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

Leaving us with a very small set of ABI/API which should
neither be defined nor exported as is, but may be
exposed in some capacity to support format transitions
of existing types:

	drem nexttoward scalb finite gamma


> There are still some files that are never useful for new types even when 
> those types are used as long double variants, e.g. w_lgamma_compat.  But 
> maybe it's just that one, in which case perhaps it makes more sense just 
> to have an empty version of that file used for new types rather than 
> splitting things in the Makefile (and for other files such as scalb that 
> are conditionally used to have files with appropriate #if conditions 
> determining whether they generate any code).

Assuming there is little objection to the mechanism I've
suggested for adding new types, these outliers can be added
to type-{double,ldouble,float}-routines variable (The usage
of eval can be trivially worked around).

> 
> 
> [*] Strictly ISO C would require the remapping to go to __*f128 names with 
> those being exported as well, to stay within the ISO C namespace; 
> something to consider later.
> 

Yes, though I think that work should happen after we get the
initial float128 work done.  That transition is going be
substantially more complex than adding float128.