diff options
author | Joseph Myers <joseph@codesourcery.com> | 2022-09-28 20:09:34 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2022-09-28 20:10:08 +0000 |
commit | 3e5760fcb48528d48deeb60cb885a97bb731160c (patch) | |
tree | 3beb195765876dacdccdc7d8ab451db162029f5f /sysdeps/mips | |
parent | d7f32c995846ba2cd3964076954435cb1a4f76b2 (diff) | |
download | glibc-3e5760fcb48528d48deeb60cb885a97bb731160c.tar.gz glibc-3e5760fcb48528d48deeb60cb885a97bb731160c.tar.xz glibc-3e5760fcb48528d48deeb60cb885a97bb731160c.zip |
Update _FloatN header support for C++ in GCC 13
GCC 13 adds support for _FloatN and _FloatNx types in C++, so breaking the installed glibc headers that assume such support is not present. GCC mostly works around this with fixincludes, but that doesn't help for building glibc and its tests (glibc doesn't itself contain C++ code, but there's C++ code built for tests). Update glibc's bits/floatn-common.h and bits/floatn.h headers to handle the GCC 13 support directly. In general the changes match those made by fixincludes, though I think the ones in sysdeps/powerpc/bits/floatn.h, where the header tests __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing fixincludes patterns. Some places involving special C++ handling in relation to _FloatN support are not changed. There's no need to change the __HAVE_FLOATN_NOT_TYPEDEF definition (also in a form that wouldn't be matched by the fixincludes fixes) because it's only used in relation to macro definitions using features not supported for C++ (__builtin_types_compatible_p and _Generic). And there's no need to change the inline function overloads for issignaling, iszero and iscanonical in C++ because cases where types have the same format but are no longer compatible types are handled automatically by the C++ overload resolution rules. This patch also does not change the overload handling for iseqsig, and there I think changes *are* needed, beyond those in this patch or made by fixincludes. The way that overload is defined, via a template parameter to a structure type, requires overloads whenever the types are incompatible, even if they have the same format. So I think we need to add overloads with GCC 13 for every supported _FloatN and _FloatNx type, rather than just having one for _Float128 when it has a different ABI to long double as at present (but for older GCC, such overloads must not be defined for types that end up defined as typedefs for another type). Tested with build-many-glibcs.py: compilers build for aarch64-linux-gnu ia64-linux-gnu mips64-linux-gnu powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu; glibcs build for aarch64-linux-gnu ia64-linux-gnu i686-linux-gnu mips-linux-gnu mips64-linux-gnu-n32 powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu.
Diffstat (limited to 'sysdeps/mips')
-rw-r--r-- | sysdeps/mips/ieee754/bits/floatn.h | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/sysdeps/mips/ieee754/bits/floatn.h b/sysdeps/mips/ieee754/bits/floatn.h index 1d51db04c7..f0321eb010 100644 --- a/sysdeps/mips/ieee754/bits/floatn.h +++ b/sysdeps/mips/ieee754/bits/floatn.h @@ -55,7 +55,7 @@ /* Defined to concatenate the literal suffix to be used with _Float128 types, if __HAVE_FLOAT128 is 1. */ # if __HAVE_FLOAT128 -# if !__GNUC_PREREQ (7, 0) || defined __cplusplus +# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) /* The literal suffix f128 exists only since GCC 7.0. */ # define __f128(x) x##l # else @@ -65,7 +65,7 @@ /* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1. */ # if __HAVE_FLOAT128 -# if !__GNUC_PREREQ (7, 0) || defined __cplusplus +# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) # define __CFLOAT128 _Complex long double # else # define __CFLOAT128 _Complex _Float128 @@ -76,7 +76,7 @@ # if __HAVE_FLOAT128 /* The type _Float128 exists only since GCC 7.0. */ -# if !__GNUC_PREREQ (7, 0) || defined __cplusplus +# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0)) typedef long double _Float128; # endif |