qiurui
/
glibc
mirror of git://sourceware.org/git/glibc.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
glibc/math/test-flt-eval-method.c

248 lines
5.8 KiB
C
Raw Normal View History

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.
2016-11-23 00:28:30 +00:00
/* Test evaluation method typedefs match FLT_EVAL_METHOD.
Update copyright dates with scripts/update-copyrights
2025-01-01 18:14:45 +00:00
Copyright (C) 2016-2025 Free Software Foundation, Inc.
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.
2016-11-23 00:28:30 +00: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 05:40:42 +00:00
<https://www.gnu.org/licenses/>. */
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.
2016-11-23 00:28:30 +00:00
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
#define __STDC_WANT_IEC_60559_TYPES_EXT__
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.
2016-11-23 00:28:30 +00:00
#include <float.h>
#include <math.h>
#if FLT_EVAL_METHOD == -1
/* Cannot test. */
typedef float_t my_float_t;
typedef double_t my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long_double_t my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float16_t my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float32_t my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64_t my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128_t my_Float128_t;
# endif
#elif FLT_EVAL_METHOD == 0
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.
2016-11-23 00:28:30 +00:00
typedef float my_float_t;
typedef double my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef float my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float32 my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 1
typedef double my_float_t;
typedef double my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef double my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef double my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 2
typedef long double my_float_t;
typedef long double my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef long double my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef long double my_Float32_t;
# endif
# if __HAVE_FLOAT64
# ifdef __NO_LONG_DOUBLE_MATH
typedef _Float64 my_Float64_t;
# else
typedef long double my_Float64_t;
# endif
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
#elif FLT_EVAL_METHOD == 16
typedef float my_float_t;
typedef double my_double_t;
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float16 my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float32 my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 32
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef float my_float_t;
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.
2016-11-23 00:28:30 +00:00
typedef double my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float32 my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float32 my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 33
typedef _Float32x my_float_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef double my_double_t;
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float32x my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float32x my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 64
typedef _Float64 my_float_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef double my_double_t;
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float64 my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float64 my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 65
typedef _Float64x my_float_t;
typedef _Float64x my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
typedef long double my_long_double_t;
# if __HAVE_FLOAT16
typedef _Float64x my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float64x my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float64x my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 128
typedef _Float128 my_float_t;
typedef _Float128 my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
# if __HAVE_FLOAT128_UNLIKE_LDBL && __LDBL_MANT_DIG__ != 106
typedef _Float128 my_long_double_t;
# else
typedef long double my_long_double_t;
# endif
# if __HAVE_FLOAT16
typedef _Float128 my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float128 my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float128 my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128 my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#elif FLT_EVAL_METHOD == 129
typedef _Float128x my_float_t;
typedef _Float128x my_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
# if __LDBL_MANT_DIG__ != 106
typedef _Float128x my_long_double_t;
# else
typedef long double my_long_double_t;
# endif
# if __HAVE_FLOAT16
typedef _Float128x my_Float16_t;
# endif
# if __HAVE_FLOAT32
typedef _Float128x my_Float32_t;
# endif
# if __HAVE_FLOAT64
typedef _Float128x my_Float64_t;
# endif
# if __HAVE_FLOAT128
typedef _Float128x my_Float128_t;
# endif
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.
2016-11-23 00:28:30 +00:00
#else
# error "Unknown FLT_EVAL_METHOD"
#endif
extern float_t test_float_t;
extern my_float_t test_float_t;
extern double_t test_double_t;
extern my_double_t test_double_t;
Add C23 long_double_t, _FloatN_t C23 Annex H adds <math.h> typedefs long_double_t and _FloatN_t (originally introduced in TS 18661-3), analogous to float_t and double_t. Add these typedefs to glibc. (There are no _FloatNx_t typedefs.) C23 also slightly changes the rules for how such typedef names should be defined, compared to the definition in TS 18661-3. In both cases, <TYPE>_t corresponds to the evaluation format for <TYPE>, as specified by FLT_EVAL_METHOD (for which <math.h> uses glibc's internal __GLIBC_FLT_EVAL_METHOD). Specifically, each FLT_EVAL_METHOD value corresponds to some type U (for example, 64 corresponds to U = _Float64), and for types with exactly the same set of values as U, TS 18661-3 says expressions with those types are to be evaluated to the range and precision of type U (so <TYPE>_t is defined to U), whereas C23 only does that for types whose values are a strict subset of those of type U (so <TYPE>_t is defined to <TYPE>). As with other cases where semantics changed between TS 18661 and C23, this patch only implements the newer version of the semantics (including adjusting existing definitions of float_t and double_t as needed). The new semantics are contradictory between the main standard and Annex H for the case of FLT_EVAL_METHOD == 2 and the choice of double_t when double and long double have the same values (the main standard says it's defined as long double in that case, whereas Annex H would define it as double), which I've raised on the WG14 reflector (but I think setting FLT_EVAL_METHOD == 2 when double and long double have the same values is a fairly theoretical combination of features); for now glibc follows the value in the main standard in that case. Note that I think all existing GCC targets supported by glibc only use values -1, 0, 1, 2 or 16 for FLT_EVAL_METHOD (so most of the header code is somewhat theoretical, though potentially relevant with other compilers since the choice of FLT_EVAL_METHOD is only an API choice, not an ABI one; it can vary with compiler options, and these typedefs should not be used in ABIs). The testcase (expanded to cover the new typedefs) is really just repeating the same logic in a second place (so all it really tests is that __GLIBC_FLT_EVAL_METHOD is consistent with FLT_EVAL_METHOD). Tested for x86_64 and x86, and with build-many-glibcs.py.
2025-11-04 17:12:00 +00:00
extern long_double_t test_long_double_t;
extern my_long_double_t test_long_double_t;
#if __HAVE_FLOAT16
extern _Float16_t test_Float16_t;
extern my_Float16_t test_Float16_t;
#endif
#if __HAVE_FLOAT32
extern _Float32_t test_Float32_t;
extern my_Float32_t test_Float32_t;
#endif
#if __HAVE_FLOAT64
extern _Float64_t test_Float64_t;
extern my_Float64_t test_Float64_t;
#endif
#if __HAVE_FLOAT128
extern _Float128_t test_Float128_t;
extern my_Float128_t test_Float128_t;
#endif
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.
2016-11-23 00:28:30 +00:00
/* This is a compilation test. */
#define TEST_FUNCTION 0
#include "../test-skeleton.c"