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

[Joseph Myers <joseph at codesourcery dot com>]

On Fri, 3 Jun 2016, Paul E. Murphy wrote:

> I spent some time trying to figure out tgmath.h, and how it might look
> with support for arbitrary types.  It assumes __builtin_types_compatible_p
> and Statement Expr's are supported by GCC (I'm not sure when these were
> added).  These macros might make a good basis for supporting the
> classification macros in math.h.

Assuming that is not a good idea.

(a) We support use of compilers back to GCC 2.7 with glibc headers; 
__builtin_types_compatible_p is more recent than that (GCC 3.1).

(b) Using statement expressions in a macro means it can't be used outside 
of function definitions (in sizeof etc.); while it would be desirable to 
fix that in GCC, compatibility with existing GCC means it's best not to 
add them to these macros if avoidable.

So conditional expressions should be used instead of statement 
expressions, and __builtin_types_compatible_p only when supported (you 
*can* assume it's supported if __float128 is).

> The potential Makefile changes by comparison are rather self-explanatory.

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 
functions you list in gnu-libm-calls are not obsolete functions, and 
several would break the build if you didn't include them for new 
floating-point types.  e_j0F e_j1F e_jnF should be included for new types 
for feature parity with long double; e_rem_pio2F is required for range 
reduction for trigonometric functions; w_j0F w_j1F w_jnF go with e_j0F 
e_j1F e_jnF; s_sincosF s_clog10F should be included as GNU extensions for 
new types just as for existing types; x2y2m1F gamma_productF lgamma_negF 
lgamma_productF are parts of the implementations of other functions and 
are required for all types where those functions are present.

You need to make an actual proposal regarding which functions present in 
the API for long double should or should not have float128 analogues - 
going through all functions in glibc with long double in their prototypes, 
and classifying them appropriately.

Also, the currently documented minimum GNU make version is 3.79.  You're 
using a feature, $(eval), that's new in 3.80.  If you wish to do so, 
you'll need to propose an increase in the minimum version separately.

-- 
Joseph S. Myers
joseph@codesourcery.com