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

[Joseph Myers <joseph at codesourcery dot com>]

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.

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


[*] 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.

-- 
Joseph S. Myers
joseph@codesourcery.com