This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Default choice of float_t
- From: Joseph Myers <joseph at codesourcery dot com>
- To: <libc-alpha at sourceware dot org>
- Cc: <david dot holsgrove at xilinx dot com>, <cltang at codesourcery dot com>, <kkojima at rr dot iij4u dot or dot jp>, <stli at linux dot vnet dot ibm dot com>, <schwab at linux-m68k dot org>, <Andreas dot Krebbel at de dot ibm dot com>
- Date: Sun, 25 Jan 2015 16:10:18 +0000
- Subject: Default choice of float_t
- Authentication-results: sourceware.org; auth=none
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