2017-10-21 05:42:51 +08:00
|
|
|
/* Macros to control TS 18661-3 glibc features where the same
|
|
|
|
|
definitions are appropriate for all platforms.
|
2023-01-07 05:08:04 +08:00
|
|
|
Copyright (C) 2017-2023 Free Software Foundation, Inc.
|
2017-10-21 05:42:51 +08:00
|
|
|
This file is part of the GNU C Library.
|
|
|
|
|
|
|
|
|
|
The GNU C Library is free software; you can redistribute it and/or
|
|
|
|
|
modify it under the terms of the GNU Lesser General Public
|
|
|
|
|
License as published by the Free Software Foundation; either
|
|
|
|
|
version 2.1 of the License, or (at your option) any later version.
|
|
|
|
|
|
|
|
|
|
The GNU C Library is distributed in the hope that it will be useful,
|
|
|
|
|
but WITHOUT ANY WARRANTY; without even the implied warranty of
|
|
|
|
|
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
|
|
|
|
|
Lesser General Public License for more details.
|
|
|
|
|
|
|
|
|
|
You should have received a copy of the GNU Lesser General Public
|
|
|
|
|
License along with the GNU C Library; if not, see
|
Prefer https to http for gnu.org and fsf.org URLs
Also, change sources.redhat.com to sourceware.org.
This patch was automatically generated by running the following shell
script, which uses GNU sed, and which avoids modifying files imported
from upstream:
sed -ri '
s,(http|ftp)(://(.*\.)?(gnu|fsf|sourceware)\.org($|[^.]|\.[^a-z])),https\2,g
s,(http|ftp)(://(.*\.)?)sources\.redhat\.com($|[^.]|\.[^a-z]),https\2sourceware.org\4,g
' \
$(find $(git ls-files) -prune -type f \
! -name '*.po' \
! -name 'ChangeLog*' \
! -path COPYING ! -path COPYING.LIB \
! -path manual/fdl-1.3.texi ! -path manual/lgpl-2.1.texi \
! -path manual/texinfo.tex ! -path scripts/config.guess \
! -path scripts/config.sub ! -path scripts/install-sh \
! -path scripts/mkinstalldirs ! -path scripts/move-if-change \
! -path INSTALL ! -path locale/programs/charmap-kw.h \
! -path po/libc.pot ! -path sysdeps/gnu/errlist.c \
! '(' -name configure \
-execdir test -f configure.ac -o -f configure.in ';' ')' \
! '(' -name preconfigure \
-execdir test -f preconfigure.ac ';' ')' \
-print)
and then by running 'make dist-prepare' to regenerate files built
from the altered files, and then executing the following to cleanup:
chmod a+x sysdeps/unix/sysv/linux/riscv/configure
# Omit irrelevant whitespace and comment-only changes,
# perhaps from a slightly-different Autoconf version.
git checkout -f \
sysdeps/csky/configure \
sysdeps/hppa/configure \
sysdeps/riscv/configure \
sysdeps/unix/sysv/linux/csky/configure
# Omit changes that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/powerpc/powerpc64/ppc-mcount.S: trailing lines
git checkout -f \
sysdeps/powerpc/powerpc64/ppc-mcount.S \
sysdeps/unix/sysv/linux/s390/s390-64/syscall.S
# Omit change that caused a pre-commit check to fail like this:
# remote: *** error: sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S: last line does not end in newline
git checkout -f sysdeps/sparc/sparc64/multiarch/memcpy-ultra3.S
2019-09-07 13:40:42 +08:00
|
|
|
<https://www.gnu.org/licenses/>. */
|
2017-10-21 05:42:51 +08:00
|
|
|
|
|
|
|
|
#ifndef _BITS_FLOATN_COMMON_H
|
|
|
|
|
#define _BITS_FLOATN_COMMON_H
|
|
|
|
|
|
|
|
|
|
#include <features.h>
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
#include <bits/long-double.h>
|
2017-10-21 05:42:51 +08:00
|
|
|
|
|
|
|
|
/* This header should be included at the bottom of each bits/floatn.h.
|
|
|
|
|
It defines the following macros for each _FloatN and _FloatNx type,
|
|
|
|
|
where the same definitions, or definitions based only on the macros
|
|
|
|
|
in bits/floatn.h, are appropriate for all glibc configurations. */
|
|
|
|
|
|
|
|
|
|
/* Defined to 1 if the current compiler invocation provides a
|
|
|
|
|
floating-point type with the right format for this type, and this
|
|
|
|
|
glibc includes corresponding *fN or *fNx interfaces for it. */
|
|
|
|
|
#define __HAVE_FLOAT16 0
|
2017-12-07 08:48:31 +08:00
|
|
|
#define __HAVE_FLOAT32 1
|
2017-12-06 08:58:03 +08:00
|
|
|
#define __HAVE_FLOAT64 1
|
|
|
|
|
#define __HAVE_FLOAT32X 1
|
2017-10-21 05:42:51 +08:00
|
|
|
#define __HAVE_FLOAT128X 0
|
|
|
|
|
|
|
|
|
|
/* Defined to 1 if the corresponding __HAVE_<type> macro is 1 and the
|
|
|
|
|
type is the first with its format in the sequence of (the default
|
|
|
|
|
choices for) float, double, long double, _Float16, _Float32,
|
|
|
|
|
_Float64, _Float128, _Float32x, _Float64x, _Float128x for this
|
|
|
|
|
glibc; that is, if functions present once per floating-point format
|
|
|
|
|
rather than once per type are present for this type.
|
|
|
|
|
|
|
|
|
|
All configurations supported by glibc have _Float32 the same format
|
|
|
|
|
as float, _Float64 and _Float32x the same format as double, the
|
|
|
|
|
_Float64x the same format as either long double or _Float128. No
|
|
|
|
|
configurations support _Float128x or, as of GCC 7, have compiler
|
|
|
|
|
support for a type meeting the requirements for _Float128x. */
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT16 __HAVE_FLOAT16
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT32 0
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT64 0
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT32X 0
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT64X 0
|
|
|
|
|
#define __HAVE_DISTINCT_FLOAT128X __HAVE_FLOAT128X
|
|
|
|
|
|
2018-05-12 05:05:03 +08:00
|
|
|
/* Defined to 1 if the corresponding _FloatN type is not binary compatible
|
|
|
|
|
with the corresponding ISO C type in the current compilation unit as
|
|
|
|
|
opposed to __HAVE_DISTINCT_FLOATN, which indicates the default types built
|
|
|
|
|
in glibc. */
|
|
|
|
|
#define __HAVE_FLOAT128_UNLIKE_LDBL (__HAVE_DISTINCT_FLOAT128 \
|
|
|
|
|
&& __LDBL_MANT_DIG__ != 113)
|
|
|
|
|
|
2017-10-21 05:42:51 +08:00
|
|
|
/* Defined to 1 if any _FloatN or _FloatNx types that are not
|
|
|
|
|
ABI-distinct are however distinct types at the C language level (so
|
|
|
|
|
for the purposes of __builtin_types_compatible_p and _Generic). */
|
|
|
|
|
#if __GNUC_PREREQ (7, 0) && !defined __cplusplus
|
|
|
|
|
# define __HAVE_FLOATN_NOT_TYPEDEF 1
|
|
|
|
|
#else
|
|
|
|
|
# define __HAVE_FLOATN_NOT_TYPEDEF 0
|
|
|
|
|
#endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
#ifndef __ASSEMBLER__
|
|
|
|
|
|
2017-10-21 05:42:51 +08:00
|
|
|
/* Defined to concatenate the literal suffix to be used with _FloatN
|
|
|
|
|
or _FloatNx types, if __HAVE_<type> is 1. The corresponding
|
|
|
|
|
literal suffixes exist since GCC 7, for C only. */
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT16
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
/* No corresponding suffix available for this type. */
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __f16(x) ((_Float16) x##f)
|
|
|
|
|
# else
|
|
|
|
|
# define __f16(x) x##f16
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __f32(x) x##f
|
|
|
|
|
# else
|
|
|
|
|
# define __f32(x) x##f32
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
# ifdef __NO_LONG_DOUBLE_MATH
|
|
|
|
|
# define __f64(x) x##l
|
|
|
|
|
# else
|
|
|
|
|
# define __f64(x) x
|
|
|
|
|
# endif
|
2017-11-18 06:01:43 +08:00
|
|
|
# else
|
|
|
|
|
# define __f64(x) x##f64
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __f32x(x) x
|
|
|
|
|
# else
|
|
|
|
|
# define __f32x(x) x##f32x
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X_LONG_DOUBLE
|
|
|
|
|
# define __f64x(x) x##l
|
|
|
|
|
# else
|
|
|
|
|
# define __f64x(x) __f128 (x)
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# else
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __f64x(x) x##f64x
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT128X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# error "_Float128X supported but no constant suffix"
|
|
|
|
|
# else
|
|
|
|
|
# define __f128x(x) x##f128x
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
/* Defined to a complex type if __HAVE_<type> is 1. */
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT16
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef _Complex float __cfloat16 __attribute__ ((__mode__ (__HC__)));
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __CFLOAT16 __cfloat16
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT16 _Complex _Float16
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __CFLOAT32 _Complex float
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT32 _Complex _Float32
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
# ifdef __NO_LONG_DOUBLE_MATH
|
|
|
|
|
# define __CFLOAT64 _Complex long double
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT64 _Complex double
|
|
|
|
|
# endif
|
2017-11-18 06:01:43 +08:00
|
|
|
# else
|
|
|
|
|
# define __CFLOAT64 _Complex _Float64
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __CFLOAT32X _Complex double
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT32X _Complex _Float32x
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X_LONG_DOUBLE
|
|
|
|
|
# define __CFLOAT64X _Complex long double
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT64X __CFLOAT128
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# else
|
2017-11-18 06:01:43 +08:00
|
|
|
# define __CFLOAT64X _Complex _Float64x
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT128X
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# error "_Float128X supported but no complex type"
|
|
|
|
|
# else
|
|
|
|
|
# define __CFLOAT128X _Complex _Float128x
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
/* The remaining of this file provides support for older compilers. */
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT16
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef float _Float16 __attribute__ ((__mode__ (__HF__)));
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf16() ((_Float16) __builtin_huge_val ())
|
|
|
|
|
# define __builtin_inff16() ((_Float16) __builtin_inf ())
|
|
|
|
|
# define __builtin_nanf16(x) ((_Float16) __builtin_nan (x))
|
|
|
|
|
# define __builtin_nansf16(x) ((_Float16) __builtin_nans (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef float _Float32;
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf32() (__builtin_huge_valf ())
|
|
|
|
|
# define __builtin_inff32() (__builtin_inff ())
|
|
|
|
|
# define __builtin_nanf32(x) (__builtin_nanf (x))
|
|
|
|
|
# define __builtin_nansf32(x) (__builtin_nansf (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64
|
2017-10-21 05:42:51 +08:00
|
|
|
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
/* If double, long double and _Float64 all have the same set of
|
|
|
|
|
values, TS 18661-3 requires the usual arithmetic conversions on
|
|
|
|
|
long double and _Float64 to produce _Float64. For this to be the
|
|
|
|
|
case when building with a compiler without a distinct _Float64
|
|
|
|
|
type, _Float64 must be a typedef for long double, not for
|
|
|
|
|
double. */
|
|
|
|
|
|
|
|
|
|
# ifdef __NO_LONG_DOUBLE_MATH
|
|
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
typedef long double _Float64;
|
|
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf64() (__builtin_huge_vall ())
|
|
|
|
|
# define __builtin_inff64() (__builtin_infl ())
|
|
|
|
|
# define __builtin_nanf64(x) (__builtin_nanl (x))
|
|
|
|
|
# define __builtin_nansf64(x) (__builtin_nansl (x))
|
|
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
# else
|
|
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef double _Float64;
|
Use long double not double for _Float64 with old GCC if values the same.
If double, long double and _Float64 all have the same set of values,
TS 18661-3 requires the usual arithmetic conversions on long double
and _Float64 to produce _Float64. For this to be the case when
building with a compiler without a distinct _Float64 type, _Float64
must be a typedef for long double, not for double. (_Float32x,
however, must be double in such a case, not long double, because the
usual arithmetic conversions on _Float32x and double must produce
double.)
This patch adjusts the fallback definition of _Float64 and associated
macros accordingly in that case, to fix the build of test-tgmath3 with
GCC 6 for such a configuration. Tested in conjunction with _Float64
changes with build-many-glibcs.py for arm-linux-gnueabi, to make sure
the issue with test-tgmath3 is fixed. Also tested for x86_64.
* bits/floatn-common.h: Include <bits/long-double.h>.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__f64): Use suffix 'l'.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (__CFLOAT64): Use _Complex long double.
[__HAVE_FLOAT64 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus)
&& __NO_LONG_DOUBLE_MATH] (_Float64): Use long double.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_huge_valf64): Use __builtin_huge_vall.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_inff64): Use __builtin_infl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nanf64): Use __builtin_nanl.
[__HAVE_FLOAT64 && !__GNUC_PREREQ (7, 0) && __NO_LONG_DOUBLE_MATH]
(__builtin_nansf64): Use __builtin_nansl.
2017-12-06 05:52:15 +08:00
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf64() (__builtin_huge_val ())
|
|
|
|
|
# define __builtin_inff64() (__builtin_inf ())
|
|
|
|
|
# define __builtin_nanf64(x) (__builtin_nan (x))
|
|
|
|
|
# define __builtin_nansf64(x) (__builtin_nans (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT32X
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef double _Float32x;
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf32x() (__builtin_huge_val ())
|
|
|
|
|
# define __builtin_inff32x() (__builtin_inf ())
|
|
|
|
|
# define __builtin_nanf32x(x) (__builtin_nan (x))
|
|
|
|
|
# define __builtin_nansf32x(x) (__builtin_nans (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT64X_LONG_DOUBLE
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef long double _Float64x;
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf64x() (__builtin_huge_vall ())
|
|
|
|
|
# define __builtin_inff64x() (__builtin_infl ())
|
|
|
|
|
# define __builtin_nanf64x(x) (__builtin_nanl (x))
|
|
|
|
|
# define __builtin_nansf64x(x) (__builtin_nansl (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# else
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-10-21 05:42:51 +08:00
|
|
|
typedef _Float128 _Float64x;
|
2017-11-18 06:01:43 +08:00
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf64x() (__builtin_huge_valf128 ())
|
|
|
|
|
# define __builtin_inff64x() (__builtin_inff128 ())
|
|
|
|
|
# define __builtin_nanf64x(x) (__builtin_nanf128 (x))
|
|
|
|
|
# define __builtin_nansf64x(x) (__builtin_nansf128 (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
|
|
|
|
# endif
|
|
|
|
|
|
|
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if __HAVE_FLOAT128X
|
2017-10-21 05:42:51 +08:00
|
|
|
|
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.
2022-09-29 04:09:34 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
|
2017-11-18 06:01:43 +08:00
|
|
|
# error "_Float128x supported but no type"
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
# if !__GNUC_PREREQ (7, 0)
|
|
|
|
|
# define __builtin_huge_valf128x() ((_Float128x) __builtin_huge_val ())
|
|
|
|
|
# define __builtin_inff128x() ((_Float128x) __builtin_inf ())
|
|
|
|
|
# define __builtin_nanf128x(x) ((_Float128x) __builtin_nan (x))
|
|
|
|
|
# define __builtin_nansf128x(x) ((_Float128x) __builtin_nans (x))
|
|
|
|
|
# endif
|
2017-10-21 05:42:51 +08:00
|
|
|
|
|
|
|
|
# endif
|
|
|
|
|
|
2017-11-18 06:01:43 +08:00
|
|
|
#endif /* !__ASSEMBLER__. */
|
2017-10-21 05:42:51 +08:00
|
|
|
|
|
|
|
|
#endif /* _BITS_FLOATN_COMMON_H */
|
