This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug math/20855] Default bits/mathdef.h has inappropriate float_t
- From: "cvs-commit at gcc dot gnu.org" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Wed, 23 Nov 2016 00:29:56 +0000
- Subject: [Bug math/20855] Default bits/mathdef.h has inappropriate float_t
- Auto-submitted: auto-generated
- References: <bug-20855-131@http.sourceware.org/bugzilla/>
https://sourceware.org/bugzilla/show_bug.cgi?id=20855
--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project "GNU C Library master sources".
The branch, master has been updated
via b0216d3e4d98a3528bad428c22ff96fcbcc102a4 (commit)
from 510abe7b945ddab6f4497e7c097cff677286bb4d (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=b0216d3e4d98a3528bad428c22ff96fcbcc102a4
commit b0216d3e4d98a3528bad428c22ff96fcbcc102a4
Author: Joseph Myers <joseph@codesourcery.com>
Date: Wed Nov 23 00:28:30 2016 +0000
Fix default float_t definition (bug 20855).
The default (top-level) version of bits/mathdef.h defines float_t to
double. It is used on ColdFire, MicroBlaze, Nios II and SH3, all of
which define FLT_EVAL_METHOD to 0, so float_t should be float (and C11
requires a certain correspondence between these typedefs and
FLT_EVAL_METHOD values).
I proposed fixing this default in
<https://sourceware.org/ml/libc-alpha/2015-01/msg00499.html>, with no
objections from architecture maintainers, and this patch makes that
fix. As noted in the NEWS entry added, this might affect the ABIs of
non-glibc libraries (ImageMagick has been mentioned in gcc-patches
discussion of the S/390 case - which is unaffected by this patch), but
as noted in my previous message, affected libraries would have
problems with -mfpmath=sse anyway on 32-bit x86.
A (compilation) testcase is added to verify the required
correspondence of typedefs to FLT_EVAL_METHOD values. This test is
built with -fexcess-precision=standard to avoid any issues with GCC 7
on S/390 providing a more accurate FLT_EVAL_METHOD definition in the
default (no excess precision) mode. (This will also be usable to test
a fix for the recently reported bug about these typedefs on x86_64
-mfpmath=387, as architecture-specific tests can be added that
It is entirely possible that the fixed default makes some
architecture-specific versions of bits/mathdef.h semantically
equivalent to the default version and so no longer required. I don't
intend to investigate that separately from the refactoring I proposed
in <https://sourceware.org/ml/libc-alpha/2016-11/msg00745.html>, which
will create as few header variants as possible for each group of
definitions.
Tested (compilation only) with build-many-glibcs.py.
[BZ #20855]
* bits/mathdef.h (float_t): Define to float.
* math/test-flt-eval-method.c: New file.
* math/Makefile (tests): Add test-flt-eval-method.
(CFLAGS-test-flt-eval-method.c): New variable.
-----------------------------------------------------------------------
Summary of changes:
ChangeLog | 8 +++++
NEWS | 5 +++
bits/mathdef.h | 8 ++--
math/Makefile | 3 +-
math/test-flt-eval-method.c | 65 +++++++++++++++++++++++++++++++++++++++++++
5 files changed, 84 insertions(+), 5 deletions(-)
create mode 100644 math/test-flt-eval-method.c
--
You are receiving this mail because:
You are on the CC list for the bug.