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

[Joseph Myers <joseph at codesourcery dot com>]

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.)

> to type-{double,ldouble,float}-routines variable (The usage

The question is not so much can it be done in one way or another, as 
what's cleanest.

> of eval can be trivially worked around).

I don't think requiring a GNU make version supporting eval is a *problem* 
- a move to 3.81 (probably) as minimum version just needs to be proposed 
in a separate thread.  (Versions newer than 3.81 would not be suitable to 
require yet; it took a long time for make 4.x to be widely adopted, so 
that e.g. Ubuntu 14.04 has 3.81.)

-- 
Joseph S. Myers
joseph@codesourcery.com