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

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

On 06/06/2016 05:50 PM, Joseph Myers wrote:
> On Mon, 6 Jun 2016, Paul E. Murphy wrote:
> 
>> 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:
> 
> You need to consider libc functions as well....  Some get __float128 
> versions although not in TS 18661-3 (e.g. strtold_l), some don't (e.g. 
> qecvt etc. - obsolescent functions that would still need building for a 
> different long double format).

This list is exclusive to libm.  I'm more concerned with what should
go in initially for float128.  It is much easier to add functions than
remove them.  I don't think there is value in enumerating all functions
which won't get a float128 analogue.

By tacit agreement, the community does not object to adding support for
new types and functioned outlined by TS 18661.  For practical reasons,
we can only support a subset of it.  Likewise, we might support a few
functions outside of TS 18661 where it eases support for standardized
functions, or attempts to resolve a deficiency of the standard.

Transitioning long double presents a unique set of challenges.  We
shouldn't make it any more challenging for us.  Any obvious changes
made to ease this work should be done upfront.  But, we also want this
support in a reasonable timeframe.

> 
>> Functions defined by TS 18661-3 which are already included within
>> glibc: 
> 
>> 	round scalbln scalbn significand
> 
> significand is not a TS 18661-3 function, and my inclination would be to 
> consider it among the obsolescent functions not added for new 
> floating-point types.

Oops. Yes, that belongs with drem and friends.

> 
>> 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
> 
> I think pow10 should be considered an obsolete name for exp10, and not 
> exported for new types.

Ok, it moves alongside drem.

> 
>> Likewise, helper functions for the classification macros,
>> and likely support macros for transitioning long double:
>>
>> 	__finite __fpclassify
>> 	__signbit __issignaling
> 
> Plus some others that are in libc rather than libm (__isinf, __isnan).
> 
> __finite and __signbit are in both libraries.  It's not clear that being 
> exported from both libraries rather than just one is desirable for new 
> types.
>

Is the intent to avoid linking libm when using the classification
macros on a compiler without a builtin, a side effect of their usage
in std* functions, or something else?

Would there be a problem defining these as static inlined functions
to avoid the ABI?
 
>> 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
> 
> Where drem and gamma are obviously aliases for other functions that *are* 
> exported for the new types, so supporting dreml and gammal for long double 
> = binary128 doesn't require building extra code (and as aliases, they 
> don't affect the makefiles either).  Likewise finitel (alias for 
> __finitef128).  And indeed nexttowardl (alias for nextafterf128) - but 
> nexttoward would instead need separate variants for float and double 
> paired with the new long double type, much like the existing variants for 
> long double = double.  scalbl would involve building new code for the new 
> type when used as long double, that wouldn't be built when used only as 
> __float128; likewise significandl, if moved to this group of functions.
> 
> (Note that where functions are being considered obsolete, we should make 
> sure the manual documents them as such and says what API is preferred 
> instead.  As I previously noted, it needs to be made to document 
> remainder, not drem, as the primary name for that function.)

Yes, those will need to be addressed when transitioning the long double
type.  The aliasing appears like it will get messy. Thinking out loud
here, is it possible to isolate the mapping of the local symbols to
public symbols to their own file/header?

Ideally, libc additions should be minimal, for each type:

>From TS 18661-3:

	strto strfrom

>From GNU, keeping symmetry with

	strfrom*_l strto*_l wscto wscto*_l
	wcsfrom wscfrom*_l

Depending on what is possible, the support ABI for the
classification macros may end up in libc too.

Likewise, after the next round of feedback, I will reply to
https://sourceware.org/ml/libc-alpha/2016-05/msg00090.html with
the updated list.