Default choice of float_t

[Joseph Myers <joseph at codesourcery dot com>]

glibc's bits/mathdef.h (default version for architectures without their 
own) does:

typedef double float_t;         /* `float' expressions are evaluated as
                                   `double'.  */

This is a strange default; normal practice is to evaluate float 
expressions as float, with 32-bit x86 and some m68k processors (pre-68040) 
being the exceptions.

Specifically, this affects microblaze and nios2 which don't have their own 
versions of this header, plus ColdFire and non-SH4 SH as subarchitectures 
using the generic header (architecture variants affecting the installed 
headers is also problematic for multilib toolchain builds).  In addition, 
sysdeps/s390/bits/mathdef.h has the same definition.

In all of the above cases defining float_t to be double, I understand the 
definition to be wrong, in that the underlying floating-point arithmetic 
(sometimes hardware, sometimes software) does not in fact have excess 
range and precision.  In the S/390 case, GCC has

/* This is used by float.h to define the float_t and double_t data
   types.  For historical reasons both are double on s390 what cannot
   be changed anymore.  */
#define TARGET_FLT_EVAL_METHOD 1

meaning that -fexcess-precision=standard would cause excess precision to 
be inserted where none would otherwise be present, so the definition would 
be formally correct in that sense (but otherwise unhelpful; the definition 
of FLT_EVAL_METHOD for S/390 will cause various code in glibc that acts to 
remove excess precision to be active, making libm less efficient given 
that it's not built with -fexcess-precision=standard).

The basis for "cannot be changed anymore" is unclear.  This choice doesn't 
affect any ABIs to glibc functions.  I don't know if any external 
libraries use float_t (or double_t) in their ABIs, but if they do, they'd 
have problems on x86 with -mfpmath=sse, which changes float_t and double_t 
although not generally thought of as an ABI-affecting option.

So my inclination (not during the freeze) would be to change the default 
header to define float_t to float (leaving the question of what to do with 
the dubious S/390 definition to the S/390 maintainers for glibc and GCC).  
That affects microblaze, nios2, ColdFire, non-SH4 SH.  If nios2 wishes to 
avoid any question of an ABI issue here, it could always add its own 
version of the header during the freeze and so avoid having any releases 
with the bogus definition of float_t as double.  If any affected 
architecture wants to keep the existing definition, it could also add its 
own version of the header.

Comments?

-- 
Joseph S. Myers
joseph@codesourcery.com