Splitting up bits/mathdef.h

[Joseph Myers <joseph at codesourcery dot com>]

The bits/mathdef.h header has four separate groups of definitions, which 
results in architectures needing their own version if any of the 
definitions for that architecture differ from the default.  I propose to 
split it up into separate headers as follows, so that less duplication is 
needed.  Any comments?

* float_t and double_t, where the default definitions are only right in 
the FLT_EVAL_METHOD == 1 case (TS 18661-3 adds more such typedefs, not 
currently supported in glibc).  I propose a bits/flt-eval-method.h header 
that defines __GLIBC_FLT_EVAL_METHOD (default __FLT_EVAL_METHOD__ if 
defined, otherwise 0), so math.h can then define float_t and double_t 
based on the value of __GLIBC_FLT_EVAL_METHOD.  (I also intend to fix the 
default to correspond to FLT_EVAL_METHOD == 0, changing float_t from 
double to float on CodeFire / MicroBlaze / Nios II / SH3, given the lack 
of objections to 
<https://sourceware.org/ml/libc-alpha/2015-01/msg00499.html> - not in the 
same commit as the refactoring, of course.)

* FP_ILOGB0 and FP_ILOGBNAN (TS 18661-1 adds FP_LLOGB0 and FP_LLOGBNAN).  
I propose a bits/fp-logb.h header that defines __FP_LOGB0_IS_MIN and 
__FP_LOGBNAN_IS_MIN to 1 if the relevant macros have the value INT_MIN 
(respectively LONG_MIN in the LLOGB case), 0 (default) otherwise (-INT_MAX 
and INT_MAX).  Given the C11 / TS 18661-1 constraints on the values of the 
FP_*LOGB* macros, this is sufficient information for math.h to then define 
the public macros appropriately.  The wrong use of unsigned FP_ILOGB0 in 
SH4 bits/mathdef.h (is 0x80000001, should be (-0x7fffffff)) would be fixed 
first.

* FP_FAST_FMA* (TS 18661-1 adds such macros for lots more functions that 
round once to narrower type).  I propose a bits/fp-fast.h header (default 
defining the macros based on the compiler's predefined macros, as in the 
existing default bits/mathdef.h).

* __NO_LONG_DOUBLE_MATH.  Definitions of this are split between 
bits/mathdef.h and bits/wordsize.h (which deals with defining 
__LONG_DOUBLE_MATH_OPTIONAL and also defines __NO_LONG_DOUBLE_MATH in the 
case of optional but not enabled support).  I propose moving definitions 
from both those headers to a bits/long-double.h header.  sys/cdefs.h would 
include bits/long-double.h alongside the existing bits/wordsize.h, so 
headers could always rely on these macros being defined if applicable.  
As this is the only reason bits/mathdef.h needs to allow inclusion by 
complex.h as well as by math.h, all the other new headers would only allow 
inclusion by math.h.

-- 
Joseph S. Myers
joseph@codesourcery.com