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

[Steven Munroe <munroesj at linux dot vnet dot ibm dot com>]

On Mon, 2016-06-06 at 22:50 +0000, 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).
> 
> > 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.
> 
> > 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.
> 
> > 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.
> 
> > 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.)
> 
> > > 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
> 
> I'm not convinced the mechanism is sufficiently coherently defined yet.  I 
> think any division of the list of functions into different classes, or 
> mechanism for sysdeps to add extra types, really needs justifying via 
> having a subsequent patch that builds on it to add working *f128 support.  
> (As opposed to refactoring how libm-calls is defined to avoid the special 
> %_rl -> %l_r hack, or reducing duplication of code between types in 
> math/Makefile, which can more readily be justified as cleanups on their 
> own merits.)

I am not sure what you are saying here. The introduction of a new
standard is a complex task requiring interpretation, iteration and time.
Introducing a new type for the existing standards and implementation is
more straightforward effort.

I don't see a requirement for perfection in these early efforts for
enabling the new standards, because all of our understandings will
involve. 

I also don't see a reason to hold up the effort to enable the addition
of new types (like _float128) and implementing the current API using
that type. The steps required to transition our platform to new (IEEE
standard) long double is already complex enough.

I would like to see a separation of concerns so that we can work both
efforts in parallel and also involve the larger community in the new
standards effort.