diff options
author | Joseph Myers <joseph@codesourcery.com> | 2017-11-06 13:26:15 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2017-11-06 13:26:15 +0000 |
commit | 4e2dff67beeb063cb36fe100d9d2b3f2f88d80c6 (patch) | |
tree | 65c970c715d9c841cd9152b7f47a4aaf9e5e1b93 /po | |
parent | a1c7cd3c72e5002739161ba35c90944b3ad05c9f (diff) | |
download | glibc-4e2dff67beeb063cb36fe100d9d2b3f2f88d80c6.tar.gz glibc-4e2dff67beeb063cb36fe100d9d2b3f2f88d80c6.tar.xz glibc-4e2dff67beeb063cb36fe100d9d2b3f2f88d80c6.zip |
Do not declare _Float128 support for powerpc64le -mlong-double-64 (bug 22402).
The powerpc bits/floatn.h declares _Float128 support to be present when the compiler supports it for powerpc64le. However, in the case where -mlong-double-64 is used, __MATH_TG does not actually support _Float128; it only supports _Float128 in the distinct-long-double case. This shows up as a build failure when building glibc mainline with GCC mainline, given the recently added sanity check in math.h for configurations supported by __MATH_TG, as the compat code for -mlong-double-64 fails to build. However, the bug was logically present before that change (including in 2.26), just less visible. This patch fixes the build failure by declaring _Float128 to be unsupported in that case. (Of course this can't actually stop users calling the type-generic macros with _Float128 arguments with -mlong-double-64, just as they could be called with other unsupported types on other platforms, but perhaps makes it less likely by making all the type-specific _Float128 interfaces invisible in that case.) Tested compilation for powerpc64le with build-many-glibcs.py. [BZ #22402] * sysdeps/powerpc/bits/floatn.h: Include <bits/long-double.h>. [__NO_LONG_DOUBLE_MATH] (__HAVE_FLOAT128): Define to 0.
Diffstat (limited to 'po')
0 files changed, 0 insertions, 0 deletions