glibc/math/gen-tgmath-tests.py

860 lines
39 KiB
Python
Raw Normal View History

#!/usr/bin/python3
# Generate tests for <tgmath.h> macros.
# Copyright (C) 2017-2024 Free Software Foundation, Inc.
# 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/>.
# As glibc does not support decimal floating point, the types to
# consider for generic parameters are standard and binary
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
# floating-point types, and integer types which are treated as
# _Float32x if any argument has a _FloatNx type and otherwise as
# double. The corresponding complex types may also be used (including
# complex integer types, which are a GNU extension, but are currently
# disabled here because they do not work properly with tgmath.h).
# C23 makes the <tgmath.h> rules for selecting a function to call
# correspond to the usual arithmetic conversions (applied successively
# to the arguments for generic parameters in order), which choose the
# type whose set of values contains that of the other type (undefined
# behavior if neither type's set of values is a superset of the
# other), with interchange types being preferred to standard types
# (long double, double, float), being preferred to extended types
# (_Float128x, _Float64x, _Float32x).
# For the standard and binary floating-point types supported by GCC 7
# on any platform, this means the resulting type is the last of the
# given types in one of the following orders, or undefined behavior if
# types with both ibm128 and binary128 representation are specified.
# If double = long double: _Float16, float, _Float32, _Float32x,
# double, long double, _Float64, _Float64x, _Float128.
# Otherwise: _Float16, float, _Float32, _Float32x, double, _Float64,
# _Float64x, long double, _Float128.
# We generate tests to verify the return type is exactly as expected.
# We also verify that the function called is real or complex as
# expected, and that it is called for the right floating-point format
# (but it is OK to call a double function instead of a long double one
# if they have the same format, for example). For all the formats
# supported on any given configuration of glibc, the MANT_DIG value
# uniquely determines the format.
import string
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
import sys
class Type(object):
"""A type that may be used as an argument for generic parameters."""
# All possible argument or result types.
all_types_list = []
# All argument types.
argument_types_list = []
# All real argument types.
real_argument_types_list = []
# Real argument types that correspond to a standard floating type
# (float, double or long double; not _FloatN or _FloatNx).
standard_real_argument_types_list = []
# The real floating types by their order properties (which are
# tuples giving the positions in both the possible orders above).
real_types_order = {}
# The type double.
double_type = None
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
# The type long double.
long_double_type = None
# The type _Complex double.
complex_double_type = None
# The type _Float64.
float64_type = None
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
# The type _Complex _Float64.
complex_float64_type = None
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
# The type _Float32x.
float32x_type = None
# The type _Complex _Float32x.
complex_float32x_type = None
# The type _Float64x.
float64x_type = None
def __init__(self, name, suffix=None, mant_dig=None, condition='1',
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
order=None, integer=False, complex=False, real_type=None,
floatnx=False):
"""Initialize a Type object, creating any corresponding complex type
in the process."""
self.name = name
self.suffix = suffix
self.mant_dig = mant_dig
self.condition = condition
self.order = order
self.integer = integer
self.complex = complex
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
self.floatnx = floatnx
if complex:
self.complex_type = self
self.real_type = real_type
else:
# complex_type filled in by the caller once created.
self.complex_type = None
self.real_type = self
def register_type(self, internal):
"""Record a type in the lists of all types."""
Type.all_types_list.append(self)
if not internal:
Type.argument_types_list.append(self)
if not self.complex:
Type.real_argument_types_list.append(self)
if not self.name.startswith('_Float'):
Type.standard_real_argument_types_list.append(self)
if self.order is not None:
Type.real_types_order[self.order] = self
if self.name == 'double':
Type.double_type = self
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if self.name == 'long double':
Type.long_double_type = self
if self.name == '_Complex double':
Type.complex_double_type = self
if self.name == '_Float64':
Type.float64_type = self
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if self.name == '_Complex _Float64':
Type.complex_float64_type = self
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
if self.name == '_Float32x':
Type.float32x_type = self
if self.name == '_Complex _Float32x':
Type.complex_float32x_type = self
if self.name == '_Float64x':
Type.float64x_type = self
@staticmethod
def create_type(name, suffix=None, mant_dig=None, condition='1', order=None,
integer=False, complex_name=None, complex_ok=True,
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
floatnx=False, internal=False):
"""Create and register a Type object for a real type, creating any
corresponding complex type in the process."""
real_type = Type(name, suffix=suffix, mant_dig=mant_dig,
condition=condition, order=order, integer=integer,
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
complex=False, floatnx=floatnx)
Fix tgmath.h handling of complex integers (bug 21684). The tgmath.h macros return a real type not a complex type when an argument is of complex integer type (a GNU extension) and there are no arguments of complex floating type. It seems clear that just as real integers are mapped to double for tgmath.h, so complex integers should be mapped to _Complex double. This patch implements such a mapping. The main complication in fixing this bug is that the tgmath.h macros expand their arguments a large number of times, resulting in exponential blowup of the size of the expansion when calls to tgmath.h macros are used in the arguments of such macros; it would be unfortunate for fixing a bug with a fairly obscure extension to make the macros expand their arguments even more times. Thus, this patch optimizes the definitions of the relevant macros. __tgmath_real_type previously expanded its argument 7 times and now expands it 3 times. __tgmath_complex_type, used in place of __tgmath_real_type only for functions that might return either real or complex types, not for complex functions that always return real types or always return complex types, expands its argument 5 times. So the sizes of the macro expansions from nested macro calls are correspondingly reduced (remembering that each tgmath.h macro expands __tgmath_real_type, or sometimes now __tgmath_complex_type, several times). Sometimes the real return type resulted from calling a complex function and converting the result to a real type; sometimes it resulted from calling a real function, because the logic for determining whether arguments were real or complex, based on sizeof, was confused by integer promotions applying to e.g. short int but not _Complex short int. The relevant tests are converted to use a new macro __expr_is_real, which, by calling __builtin_classify_type rather than comparing the results of two calls to sizeof, also reduces the number of times macros expand their arguments. Although there are reductions in the number of times macros expand their arguments, I do not consider this to fix bug 21660, since a proper fix means each macro expanding its arguments only once (via using new compiler features designed for that purpose). Tested for x86_64. [BZ #21684] * math/tgmath.h (__floating_type): Simplify definitions. (__real_integer_type): New macro. (__complex_integer_type): Likewise. (__expr_is_real): Likewise. (__tgmath_real_type_sub): Update comment to describe handling of complex types. (__tgmath_complex_type_sub): New macro. (__tgmath_complex_type): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_CF128): Use __expr_is_real. (__TGMATH_UNARY_REAL_IMAG): Use __tgmath_complex_type and __expr_is_real. (__TGMATH_BINARY_REAL_IMAG): Likewise. (__TGMATH_UNARY_REAL_IMAG_RET_REAL): Use __expr_is_real. * math/gen-tgmath-tests.py (Type.create_type): Create complex integer types.
2017-08-22 17:55:42 +00:00
if complex_ok:
if complex_name is None:
complex_name = '_Complex %s' % name
complex_type = Type(complex_name, condition=condition,
integer=integer, complex=True,
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
real_type=real_type, floatnx=floatnx)
else:
complex_type = None
real_type.complex_type = complex_type
real_type.register_type(internal)
if complex_type is not None:
complex_type.register_type(internal)
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
def floating_type(self, integer_float32x):
"""Return the corresponding floating type."""
if self.integer:
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
if integer_float32x:
return (Type.complex_float32x_type
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if self.complex
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
else Type.float32x_type)
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
else:
return (Type.complex_double_type
if self.complex
else Type.double_type)
else:
return self
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
def real_floating_type(self, integer_float32x):
"""Return the corresponding real floating type."""
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
return self.real_type.floating_type(integer_float32x)
def __str__(self):
"""Return string representation of a type."""
return self.name
@staticmethod
def init_types():
"""Initialize all the known types."""
Type.create_type('_Float16', 'f16', 'FLT16_MANT_DIG',
complex_name='__CFLOAT16',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F16', order=(0, 0))
Type.create_type('float', 'f', 'FLT_MANT_DIG', order=(1, 1))
Type.create_type('_Float32', 'f32', 'FLT32_MANT_DIG',
complex_name='__CFLOAT32',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F32', order=(2, 2))
Type.create_type('_Float32x', 'f32x', 'FLT32X_MANT_DIG',
complex_name='__CFLOAT32X',
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
condition='defined HUGE_VAL_F32X', order=(3, 3),
floatnx=True)
Type.create_type('double', '', 'DBL_MANT_DIG', order=(4, 4))
Type.create_type('long double', 'l', 'LDBL_MANT_DIG', order=(5, 7))
Type.create_type('_Float64', 'f64', 'FLT64_MANT_DIG',
complex_name='__CFLOAT64',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F64', order=(6, 5))
Type.create_type('_Float64x', 'f64x', 'FLT64X_MANT_DIG',
complex_name='__CFLOAT64X',
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
condition='defined HUGE_VAL_F64X', order=(7, 6),
floatnx=True)
Type.create_type('_Float128', 'f128', 'FLT128_MANT_DIG',
complex_name='__CFLOAT128',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F128', order=(8, 8))
Type.create_type('char', integer=True)
Type.create_type('signed char', integer=True)
Type.create_type('unsigned char', integer=True)
Type.create_type('short int', integer=True)
Type.create_type('unsigned short int', integer=True)
Type.create_type('int', integer=True)
Type.create_type('unsigned int', integer=True)
Type.create_type('long int', integer=True)
Type.create_type('unsigned long int', integer=True)
Type.create_type('long long int', integer=True)
Type.create_type('unsigned long long int', integer=True)
Type.create_type('__int128', integer=True,
condition='defined __SIZEOF_INT128__')
Type.create_type('unsigned __int128', integer=True,
condition='defined __SIZEOF_INT128__')
Type.create_type('enum e', integer=True, complex_ok=False)
Type.create_type('_Bool', integer=True, complex_ok=False)
Fix tgmath.h for bit-fields (bug 21685). The tgmath.h macros produce errors for bit-field arguments, because they apply sizeof and typeof to the arguments. This patch fixes them to use unary + systematically before using sizeof or typeof on arguments that might be bit-fields (note that __real__ of a bit-field is still a bit-field for this purpose, since it's an lvalue). gen-tgmath-tests.py is extended to add tests for this case. Tested for x86_64. [BZ #21685] * math/tgmath.h (__tgmath_real_type): Use unary + on potentially bit-field expressions passed to sizeof or typeof. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_F128): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_CF128): Likewise. (__TGMATH_UNARY_REAL_ONLY): Likewise. (__TGMATH_UNARY_REAL_RET_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_ONLY): Likewise. (__TGMATH_BINARY_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_RET_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_SECOND_REAL_ONLY): Likewise. (__TGMATH_TERNARY_REAL_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_REAL_RET_ONLY): Likewise. (__TGMATH_UNARY_REAL_IMAG): Likewise. (__TGMATH_UNARY_IMAG): Likewise. (__TGMATH_UNARY_REAL_IMAG_RET_REAL): Likewise. (__TGMATH_BINARY_REAL_IMAG): Likewise. * math/gen-tgmath-tests.py (Type.init_types): Create bit_field type. (define_vars_for_type): Handle bit_field type specially. (Tests.__init__): Declare structure with bit-field element.
2017-08-02 16:09:01 +00:00
Type.create_type('bit_field', integer=True, complex_ok=False)
# Internal types represent the combination of long double with
# _Float64 or _Float64x, for which the ordering depends on
# whether long double has the same format as double.
Type.create_type('long_double_Float64', None, 'LDBL_MANT_DIG',
complex_name='complex_long_double_Float64',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F64', order=(6, 7),
internal=True)
Type.create_type('long_double_Float64x', None, 'FLT64X_MANT_DIG',
complex_name='complex_long_double_Float64x',
2017-06-28 17:53:46 +00:00
condition='defined HUGE_VAL_F64X', order=(7, 7),
internal=True)
@staticmethod
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
def can_combine_types(types):
"""Return a C preprocessor conditional for whether the given list of
types can be used together as type-generic macro arguments."""
have_long_double = False
have_float128 = False
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
integer_float32x = any(t.floatnx for t in types)
for t in types:
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
t = t.real_floating_type(integer_float32x)
if t.name == 'long double':
have_long_double = True
if t.name == '_Float128' or t.name == '_Float64x':
have_float128 = True
if have_long_double and have_float128:
# If ibm128 format is in use for long double, both
# _Float64x and _Float128 are binary128 and the types
# cannot be combined.
return '(LDBL_MANT_DIG != 106)'
return '1'
@staticmethod
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
def combine_types(types):
"""Return the result of combining a set of types."""
have_complex = False
combined = None
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
integer_float32x = any(t.floatnx for t in types)
for t in types:
if t.complex:
have_complex = True
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
t = t.real_floating_type(integer_float32x)
if combined is None:
combined = t
else:
order = (max(combined.order[0], t.order[0]),
max(combined.order[1], t.order[1]))
combined = Type.real_types_order[order]
return combined.complex_type if have_complex else combined
def list_product_initial(initial, lists):
"""Return a list of lists, with an initial sequence from the first
argument (a list of lists) followed by each sequence of one
element from each successive element of the second argument."""
if not lists:
return initial
return list_product_initial([a + [b] for a in initial for b in lists[0]],
lists[1:])
def list_product(lists):
"""Return a list of lists, with each sequence of one element from each
successive element of the argument."""
return list_product_initial([[]], lists)
try:
trans_id = str.maketrans(' *', '_p')
except AttributeError:
trans_id = string.maketrans(' *', '_p')
def var_for_type(name):
"""Return the name of a variable with a given type (name)."""
return 'var_%s' % name.translate(trans_id)
def vol_var_for_type(name):
"""Return the name of a variable with a given volatile type (name)."""
return 'vol_var_%s' % name.translate(trans_id)
def define_vars_for_type(name):
"""Return the definitions of variables with a given type (name)."""
Fix tgmath.h for bit-fields (bug 21685). The tgmath.h macros produce errors for bit-field arguments, because they apply sizeof and typeof to the arguments. This patch fixes them to use unary + systematically before using sizeof or typeof on arguments that might be bit-fields (note that __real__ of a bit-field is still a bit-field for this purpose, since it's an lvalue). gen-tgmath-tests.py is extended to add tests for this case. Tested for x86_64. [BZ #21685] * math/tgmath.h (__tgmath_real_type): Use unary + on potentially bit-field expressions passed to sizeof or typeof. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_F128): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_CF128): Likewise. (__TGMATH_UNARY_REAL_ONLY): Likewise. (__TGMATH_UNARY_REAL_RET_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_ONLY): Likewise. (__TGMATH_BINARY_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_RET_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_SECOND_REAL_ONLY): Likewise. (__TGMATH_TERNARY_REAL_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_REAL_RET_ONLY): Likewise. (__TGMATH_UNARY_REAL_IMAG): Likewise. (__TGMATH_UNARY_IMAG): Likewise. (__TGMATH_UNARY_REAL_IMAG_RET_REAL): Likewise. (__TGMATH_BINARY_REAL_IMAG): Likewise. * math/gen-tgmath-tests.py (Type.init_types): Create bit_field type. (define_vars_for_type): Handle bit_field type specially. (Tests.__init__): Declare structure with bit-field element.
2017-08-02 16:09:01 +00:00
if name == 'bit_field':
struct_vars = define_vars_for_type('struct s');
return '%s#define %s %s.bf\n' % (struct_vars,
vol_var_for_type(name),
vol_var_for_type('struct s'))
return ('%s %s __attribute__ ((unused));\n'
'%s volatile %s __attribute__ ((unused));\n'
% (name, var_for_type(name), name, vol_var_for_type(name)))
def if_cond_text(conds, text):
"""Return the result of making some text conditional under #if. The
text ends with a newline, as does the return value if not empty."""
if '0' in conds:
return ''
conds = [c for c in conds if c != '1']
conds = sorted(set(conds))
if not conds:
return text
return '#if %s\n%s#endif\n' % (' && '.join(conds), text)
class Tests(object):
"""The state associated with testcase generation."""
def __init__(self):
"""Initialize a Tests object."""
self.header_list = ['#define __STDC_WANT_IEC_60559_TYPES_EXT__\n'
'#include <float.h>\n'
'#include <stdbool.h>\n'
'#include <stdint.h>\n'
'#include <stdio.h>\n'
'#include <string.h>\n'
'#include <tgmath.h>\n'
'\n'
'struct test\n'
' {\n'
' void (*func) (void);\n'
' const char *func_name;\n'
' const char *test_name;\n'
' int mant_dig;\n'
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
' int narrow_mant_dig;\n'
' };\n'
'int num_pass, num_fail;\n'
'volatile int called_mant_dig;\n'
'const char *volatile called_func_name;\n'
Fix tgmath.h for bit-fields (bug 21685). The tgmath.h macros produce errors for bit-field arguments, because they apply sizeof and typeof to the arguments. This patch fixes them to use unary + systematically before using sizeof or typeof on arguments that might be bit-fields (note that __real__ of a bit-field is still a bit-field for this purpose, since it's an lvalue). gen-tgmath-tests.py is extended to add tests for this case. Tested for x86_64. [BZ #21685] * math/tgmath.h (__tgmath_real_type): Use unary + on potentially bit-field expressions passed to sizeof or typeof. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_F128): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (__TGMATH_CF128): Likewise. (__TGMATH_UNARY_REAL_ONLY): Likewise. (__TGMATH_UNARY_REAL_RET_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_ONLY): Likewise. (__TGMATH_BINARY_REAL_STD_ONLY): Likewise. (__TGMATH_BINARY_REAL_RET_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_SECOND_REAL_ONLY): Likewise. (__TGMATH_TERNARY_REAL_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_REAL_RET_ONLY): Likewise. (__TGMATH_UNARY_REAL_IMAG): Likewise. (__TGMATH_UNARY_IMAG): Likewise. (__TGMATH_UNARY_REAL_IMAG_RET_REAL): Likewise. (__TGMATH_BINARY_REAL_IMAG): Likewise. * math/gen-tgmath-tests.py (Type.init_types): Create bit_field type. (define_vars_for_type): Handle bit_field type specially. (Tests.__init__): Declare structure with bit-field element.
2017-08-02 16:09:01 +00:00
'enum e { E, F };\n'
'struct s\n'
' {\n'
' int bf:2;\n'
' };\n']
float64_text = ('# if LDBL_MANT_DIG == DBL_MANT_DIG\n'
'typedef _Float64 long_double_Float64;\n'
'typedef __CFLOAT64 complex_long_double_Float64;\n'
'# else\n'
'typedef long double long_double_Float64;\n'
'typedef _Complex long double '
'complex_long_double_Float64;\n'
'# endif\n')
float64_text = if_cond_text([Type.float64_type.condition],
float64_text)
float64x_text = ('# if LDBL_MANT_DIG == DBL_MANT_DIG\n'
'typedef _Float64x long_double_Float64x;\n'
'typedef __CFLOAT64X complex_long_double_Float64x;\n'
'# else\n'
'typedef long double long_double_Float64x;\n'
'typedef _Complex long double '
'complex_long_double_Float64x;\n'
'# endif\n')
float64x_text = if_cond_text([Type.float64x_type.condition],
float64x_text)
self.header_list.append(float64_text)
self.header_list.append(float64x_text)
self.types_seen = set()
for t in Type.all_types_list:
self.add_type_var(t.name, t.condition)
self.test_text_list = []
self.test_array_list = []
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
self.macros_seen = set()
def add_type_var(self, name, cond):
"""Add declarations of variables for a type."""
if name in self.types_seen:
return
t_vars = define_vars_for_type(name)
self.header_list.append(if_cond_text([cond], t_vars))
self.types_seen.add(name)
def add_tests(self, macro, ret, args, complex_func=None):
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
"""Add tests for a given tgmath.h macro, if that is the macro for
which tests are to be generated; otherwise just add it to the
list of macros for which test generation is supported."""
# 'c' means the function argument or return type is
# type-generic and complex only (a complex function argument
# may still have a real macro argument). 'g' means it is
# type-generic and may be real or complex; 'r' means it is
# type-generic and may only be real; 's' means the same as
# 'r', but restricted to float, double and long double.
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
self.macros_seen.add(macro)
if macro != self.macro:
return
have_complex = False
func = macro
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
narrowing = False
narrowing_std = False
if ret == 'c' or 'c' in args:
# Complex-only.
have_complex = True
complex_func = func
func = None
elif ret == 'g' or 'g' in args:
# Real and complex.
have_complex = True
if complex_func is None:
complex_func = 'c%s' % func
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
# For narrowing macros, compute narrow_args, the list of
# argument types for which there is an actual corresponding
# function. If none of those types exist, or the return type
# does not exist, then the macro is not defined and no tests
# of it can be run.
if ret == 'float':
narrowing = True
narrowing_std = True
narrow_cond = '1'
narrow_args = [Type.double_type, Type.long_double_type]
elif ret == 'double':
narrowing = True
narrowing_std = True
narrow_cond = '1'
narrow_args = [Type.long_double_type]
elif ret.startswith('_Float'):
narrowing = True
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
narrow_args_1 = []
narrow_args_2 = []
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
nret_type = None
for order, real_type in sorted(Type.real_types_order.items()):
if real_type.name == ret:
nret_type = real_type
elif nret_type and real_type.name.startswith('_Float'):
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
if ret.endswith('x') == real_type.name.endswith('x'):
narrow_args_1.append(real_type)
else:
narrow_args_2.append(real_type)
narrow_args = narrow_args_1 + narrow_args_2
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if narrow_args:
narrow_cond = ('(%s && (%s))'
% (nret_type.condition,
' || '.join(t.condition
for t in narrow_args)))
else:
# No possible argument types, even conditionally.
narrow_cond = '0'
types = [ret] + args
for t in types:
if t != 'c' and t != 'g' and t != 'r' and t != 's':
self.add_type_var(t, '1')
for t in Type.argument_types_list:
if t.integer:
continue
if t.complex and not have_complex:
continue
if func is None and not t.complex:
continue
if ret == 's' and t.name.startswith('_Float'):
continue
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if narrowing and t not in narrow_args:
continue
if ret == 'c':
ret_name = t.complex_type.name
elif ret == 'g':
ret_name = t.name
elif ret == 'r' or ret == 's':
ret_name = t.real_type.name
else:
ret_name = ret
dummy_func_name = complex_func if t.complex else func
arg_list = []
arg_num = 0
for a in args:
if a == 'c':
arg_name = t.complex_type.name
elif a == 'g':
arg_name = t.name
elif a == 'r' or a == 's':
arg_name = t.real_type.name
else:
arg_name = a
arg_list.append('%s arg%d __attribute__ ((unused))'
% (arg_name, arg_num))
arg_num += 1
dummy_func = ('%s\n'
'(%s%s) (%s)\n'
'{\n'
' called_mant_dig = %s;\n'
' called_func_name = "%s";\n'
' return 0;\n'
'}\n' % (ret_name, dummy_func_name,
t.real_type.suffix, ', '.join(arg_list),
t.real_type.mant_dig, dummy_func_name))
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if narrowing:
dummy_cond = [narrow_cond, t.condition]
else:
dummy_cond = [t.condition]
dummy_func = if_cond_text(dummy_cond, dummy_func)
self.test_text_list.append(dummy_func)
arg_types = []
for t in args:
if t == 'g' or t == 'c':
arg_types.append(Type.argument_types_list)
elif t == 'r':
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
arg_types.append(Type.real_argument_types_list)
elif t == 's':
arg_types.append(Type.standard_real_argument_types_list)
arg_types_product = list_product(arg_types)
test_num = 0
for this_args in arg_types_product:
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
comb_type = Type.combine_types(this_args)
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if narrowing:
# As long as there are no integer arguments, and as
# long as the chosen argument type is as wide as all
# the floating-point arguments passed, the semantics
# of the macro call do not depend on the exact
# function chosen. In particular, for f32x functions
# when _Float64x exists, the chosen type should differ
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
# for double / _Float32x and _Float64 arguments, but
# it is not always possible to distinguish those types
# before GCC 7 (resulting in some cases - only real
# arguments - where a wider argument type is used,
# which is semantically OK, and others - integer
# arguments present - where it may not be OK, but is
# unavoidable).
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
narrow_mant_dig = comb_type.real_type.mant_dig
for arg_type in this_args:
if arg_type.integer:
narrow_mant_dig = 0
else:
narrow_mant_dig = 0
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
can_comb = Type.can_combine_types(this_args)
all_conds = [t.condition for t in this_args]
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
narrow_args_cond = '(%s)' % ' && '.join(sorted(set(all_conds)))
all_conds.append(can_comb)
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
if narrowing:
all_conds.append(narrow_cond)
any_complex = func is None
for t in this_args:
if t.complex:
any_complex = True
func_name = complex_func if any_complex else func
test_name = '%s (%s)' % (macro,
', '.join([t.name for t in this_args]))
test_func_name = 'test_%s_%d' % (macro, test_num)
test_num += 1
mant_dig = comb_type.real_type.mant_dig
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
test_mant_dig_comp = ''
if (narrowing
and comb_type not in narrow_args):
# The expected argument type is the first in
# narrow_args that can represent all the values of
# comb_type (which, for the supported cases, means the
# first with mant_dig at least as large as that for
# comb_type, provided this isn't the case of an IBM
# long double argument with binary128 type from
# narrow_args).
narrow_extra_conds = []
test_mant_dig_list = ['#undef NARROW_MANT_DIG\n#if 0\n']
for t in narrow_args:
t_cond = '(%s && %s && %s <= %s && %s)' % (
narrow_args_cond, t.condition, mant_dig, t.mant_dig,
Type.can_combine_types(this_args + [t]))
narrow_extra_conds.append(t_cond)
test_mant_dig_list.append('#elif %s\n'
'#define NARROW_MANT_DIG %s\n'
% (t_cond, t.mant_dig))
test_mant_dig_list.append('#endif\n')
test_mant_dig_comp = ''.join(test_mant_dig_list)
all_conds.append('(%s)' % ' || '.join(narrow_extra_conds))
# A special case where this logic isn't correct is
# where comb_type is the internal long_double_Float64
# or long_double_Float64x, which will be detected as
# not in narrow_args even if the actual type chosen in
# a particular configuration would have been in
# narrow_args, so check for that case and handle it
# appropriately. In particular, if long double has
# the same format as double and there are long double
# and _Float64 arguments, and the macro returns
# _Float32x, the function called should be one for
# _Float64 arguments, not one for _Float64x arguments
# that would arise from this logic.
if comb_type.real_type.name == 'long_double_Float64':
comb_type_1 = Type.long_double_type
comb_type_2 = Type.float64_type
comb_type_is_2_cond = 'LDBL_MANT_DIG <= FLT64_MANT_DIG'
elif comb_type.real_type.name == 'long_double_Float64x':
comb_type_1 = Type.long_double_type
comb_type_2 = Type.float64x_type
comb_type_is_2_cond = 'LDBL_MANT_DIG < FLT64X_MANT_DIG'
else:
comb_type_1 = None
comb_type_2 = None
if comb_type_1 is None:
mant_dig = 'NARROW_MANT_DIG'
else:
mant_dig = ''
if comb_type_1 in narrow_args:
mant_dig += '!(%s) ? %s : ' % (comb_type_is_2_cond,
comb_type_1.mant_dig)
if comb_type_2 in narrow_args:
mant_dig += '%s ? %s : ' % (comb_type_is_2_cond,
comb_type_2.mant_dig)
mant_dig += 'NARROW_MANT_DIG'
if narrow_mant_dig != 0:
narrow_mant_dig = mant_dig
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
test_text = '%s, "%s", "%s", %s, %s' % (test_func_name, func_name,
test_name, mant_dig,
narrow_mant_dig)
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
test_text = '%s { %s },\n' % (test_mant_dig_comp, test_text)
test_text = if_cond_text(all_conds, test_text)
self.test_array_list.append(test_text)
call_args = []
call_arg_pos = 0
for t in args:
if t == 'g' or t == 'c' or t == 'r' or t == 's':
type = this_args[call_arg_pos].name
call_arg_pos += 1
else:
type = t
call_args.append(vol_var_for_type(type))
call_args_text = ', '.join(call_args)
if ret == 'g':
ret_type = comb_type.name
elif ret == 'r' or ret == 's':
ret_type = comb_type.real_type.name
elif ret == 'c':
ret_type = comb_type.complex_type.name
else:
ret_type = ret
call_text = '%s (%s)' % (macro, call_args_text)
test_func_text = ('static void\n'
'%s (void)\n'
'{\n'
' extern typeof (%s) %s '
'__attribute__ ((unused));\n'
' %s = %s;\n'
'}\n' % (test_func_name, call_text,
var_for_type(ret_type),
vol_var_for_type(ret_type), call_text))
test_func_text = if_cond_text(all_conds, test_func_text)
self.test_text_list.append(test_func_text)
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
def add_all_tests(self, macro):
"""Add tests for the given tgmath.h macro, if any, and generate the
list of all supported macros."""
self.macro = macro
# C99/C11 real-only functions.
self.add_tests('atan2', 'r', ['r', 'r'])
self.add_tests('cbrt', 'r', ['r'])
self.add_tests('ceil', 'r', ['r'])
self.add_tests('copysign', 'r', ['r', 'r'])
self.add_tests('erf', 'r', ['r'])
self.add_tests('erfc', 'r', ['r'])
self.add_tests('exp2', 'r', ['r'])
self.add_tests('expm1', 'r', ['r'])
self.add_tests('fdim', 'r', ['r', 'r'])
self.add_tests('floor', 'r', ['r'])
self.add_tests('fma', 'r', ['r', 'r', 'r'])
self.add_tests('fmax', 'r', ['r', 'r'])
self.add_tests('fmin', 'r', ['r', 'r'])
self.add_tests('fmod', 'r', ['r', 'r'])
self.add_tests('frexp', 'r', ['r', 'int *'])
self.add_tests('hypot', 'r', ['r', 'r'])
self.add_tests('ilogb', 'int', ['r'])
self.add_tests('ldexp', 'r', ['r', 'int'])
self.add_tests('lgamma', 'r', ['r'])
self.add_tests('llrint', 'long long int', ['r'])
self.add_tests('llround', 'long long int', ['r'])
# log10 is real-only in ISO C, but supports complex arguments
# as a GNU extension.
self.add_tests('log10', 'g', ['g'])
self.add_tests('log1p', 'r', ['r'])
self.add_tests('log2', 'r', ['r'])
self.add_tests('logb', 'r', ['r'])
self.add_tests('lrint', 'long int', ['r'])
self.add_tests('lround', 'long int', ['r'])
self.add_tests('nearbyint', 'r', ['r'])
self.add_tests('nextafter', 'r', ['r', 'r'])
self.add_tests('nexttoward', 's', ['s', 'long double'])
self.add_tests('remainder', 'r', ['r', 'r'])
self.add_tests('remquo', 'r', ['r', 'r', 'int *'])
self.add_tests('rint', 'r', ['r'])
self.add_tests('round', 'r', ['r'])
self.add_tests('scalbn', 'r', ['r', 'int'])
self.add_tests('scalbln', 'r', ['r', 'long int'])
self.add_tests('tgamma', 'r', ['r'])
self.add_tests('trunc', 'r', ['r'])
# C99/C11 real-and-complex functions.
self.add_tests('acos', 'g', ['g'])
self.add_tests('asin', 'g', ['g'])
self.add_tests('atan', 'g', ['g'])
self.add_tests('acosh', 'g', ['g'])
self.add_tests('asinh', 'g', ['g'])
self.add_tests('atanh', 'g', ['g'])
self.add_tests('cos', 'g', ['g'])
self.add_tests('sin', 'g', ['g'])
self.add_tests('tan', 'g', ['g'])
self.add_tests('cosh', 'g', ['g'])
self.add_tests('sinh', 'g', ['g'])
self.add_tests('tanh', 'g', ['g'])
self.add_tests('exp', 'g', ['g'])
self.add_tests('log', 'g', ['g'])
self.add_tests('pow', 'g', ['g', 'g'])
self.add_tests('sqrt', 'g', ['g'])
self.add_tests('fabs', 'r', ['g'], 'cabs')
# C99/C11 complex-only functions.
self.add_tests('carg', 'r', ['c'])
self.add_tests('cimag', 'r', ['c'])
self.add_tests('conj', 'c', ['c'])
self.add_tests('cproj', 'c', ['c'])
self.add_tests('creal', 'r', ['c'])
# TS 18661-1 functions.
self.add_tests('roundeven', 'r', ['r'])
self.add_tests('nextup', 'r', ['r'])
self.add_tests('nextdown', 'r', ['r'])
self.add_tests('fminmag', 'r', ['r', 'r'])
self.add_tests('fmaxmag', 'r', ['r', 'r'])
self.add_tests('llogb', 'long int', ['r'])
self.add_tests('fromfp', 'intmax_t', ['r', 'int', 'unsigned int'])
self.add_tests('fromfpx', 'intmax_t', ['r', 'int', 'unsigned int'])
self.add_tests('ufromfp', 'uintmax_t', ['r', 'int', 'unsigned int'])
self.add_tests('ufromfpx', 'uintmax_t', ['r', 'int', 'unsigned int'])
Add narrowing fma functions This patch adds the narrowing fused multiply-add functions from TS 18661-1 / TS 18661-3 / C2X to glibc's libm: ffma, ffmal, dfmal, f32fmaf64, f32fmaf32x, f32xfmaf64 for all configurations; f32fmaf64x, f32fmaf128, f64fmaf64x, f64fmaf128, f32xfmaf64x, f32xfmaf128, f64xfmaf128 for configurations with _Float64x and _Float128; __f32fmaieee128 and __f64fmaieee128 aliases in the powerpc64le case (for calls to ffmal and dfmal when long double is IEEE binary128). Corresponding tgmath.h macro support is also added. The changes are mostly similar to those for the other narrowing functions previously added, especially that for sqrt, so the description of those generally applies to this patch as well. As with sqrt, I reused the same test inputs in auto-libm-test-in as for non-narrowing fma rather than adding extra or separate inputs for narrowing fma. The tests in libm-test-narrow-fma.inc also follow those for non-narrowing fma. The non-narrowing fma has a known bug (bug 6801) that it does not set errno on errors (overflow, underflow, Inf * 0, Inf - Inf). Rather than fixing this or having narrowing fma check for errors when non-narrowing does not (complicating the cases when narrowing fma can otherwise be an alias for a non-narrowing function), this patch does not attempt to check for errors from narrowing fma and set errno; the CHECK_NARROW_FMA macro is still present, but as a placeholder that does nothing, and this missing errno setting is considered to be covered by the existing bug rather than needing a separate open bug. missing-errno annotations are duly added to many of the auto-libm-test-in test inputs for fma. This completes adding all the new functions from TS 18661-1 to glibc, so will be followed by corresponding stdc-predef.h changes to define __STDC_IEC_60559_BFP__ and __STDC_IEC_60559_COMPLEX__, as the support for TS 18661-1 will be at a similar level to that for C standard floating-point facilities up to C11 (pragmas not implemented, but library functions done). (There are still further changes to be done to implement changes to the types of fromfp functions from N2548.) Tested as followed: natively with the full glibc testsuite for x86_64 (GCC 11, 7, 6) and x86 (GCC 11); with build-many-glibcs.py with GCC 11, 7 and 6; cross testing of math/ tests for powerpc64le, powerpc32 hard float, mips64 (all three ABIs, both hard and soft float). The different GCC versions are to cover the different cases in tgmath.h and tgmath.h tests properly (GCC 6 has _Float* only as typedefs in glibc headers, GCC 7 has proper _Float* support, GCC 8 adds __builtin_tgmath).
2021-09-22 21:25:31 +00:00
for fn, args in (('add', 2), ('div', 2), ('fma', 3), ('mul', 2),
('sqrt', 1), ('sub', 2)):
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
for ret, prefix in (('float', 'f'),
('double', 'd'),
('_Float16', 'f16'),
('_Float32', 'f32'),
('_Float64', 'f64'),
('_Float128', 'f128'),
('_Float32x', 'f32x'),
('_Float64x', 'f64x')):
Add narrowing square root functions This patch adds the narrowing square root functions from TS 18661-1 / TS 18661-3 / C2X to glibc's libm: fsqrt, fsqrtl, dsqrtl, f32sqrtf64, f32sqrtf32x, f32xsqrtf64 for all configurations; f32sqrtf64x, f32sqrtf128, f64sqrtf64x, f64sqrtf128, f32xsqrtf64x, f32xsqrtf128, f64xsqrtf128 for configurations with _Float64x and _Float128; __f32sqrtieee128 and __f64sqrtieee128 aliases in the powerpc64le case (for calls to fsqrtl and dsqrtl when long double is IEEE binary128). Corresponding tgmath.h macro support is also added. The changes are mostly similar to those for the other narrowing functions previously added, so the description of those generally applies to this patch as well. However, the not-actually-narrowing cases (where the two types involved in the function have the same floating-point format) are aliased to sqrt, sqrtl or sqrtf128 rather than needing a separately built not-actually-narrowing function such as was needed for add / sub / mul / div. Thus, there is no __nldbl_dsqrtl name for ldbl-opt because no such name was needed (whereas the other functions needed such a name since the only other name for that entry point was e.g. f32xaddf64, not reserved by TS 18661-1); the headers are made to arrange for sqrt to be called in that case instead. The DIAG_* calls in sysdeps/ieee754/soft-fp/s_dsqrtl.c are because they were observed to be needed in GCC 7 testing of riscv32-linux-gnu-rv32imac-ilp32. The other sysdeps/ieee754/soft-fp/ files added didn't need such DIAG_* in any configuration I tested with build-many-glibcs.py, but if they do turn out to be needed in more files with some other configuration / GCC version, they can always be added there. I reused the same test inputs in auto-libm-test-in as for non-narrowing sqrt rather than adding extra or separate inputs for narrowing sqrt. The tests in libm-test-narrow-sqrt.inc also follow those for non-narrowing sqrt. Tested as followed: natively with the full glibc testsuite for x86_64 (GCC 11, 7, 6) and x86 (GCC 11); with build-many-glibcs.py with GCC 11, 7 and 6; cross testing of math/ tests for powerpc64le, powerpc32 hard float, mips64 (all three ABIs, both hard and soft float). The different GCC versions are to cover the different cases in tgmath.h and tgmath.h tests properly (GCC 6 has _Float* only as typedefs in glibc headers, GCC 7 has proper _Float* support, GCC 8 adds __builtin_tgmath).
2021-09-10 20:56:22 +00:00
self.add_tests(prefix + fn, ret, ['r'] * args)
# TS 18661-4 functions.
self.add_tests('exp10', 'r', ['r'])
Implement C23 exp2m1, exp10m1 C23 adds various <math.h> function families originally defined in TS 18661-4. Add the exp2m1 and exp10m1 functions (exp2(x)-1 and exp10(x)-1, like expm1). As with other such functions, these use type-generic templates that could be replaced with faster and more accurate type-specific implementations in future. Test inputs are copied from those for expm1, plus some additions close to the overflow threshold (copied from exp2 and exp10) and also some near the underflow threshold. exp2m1 has the unusual property of having an input (M_MAX_EXP) where whether the function overflows (under IEEE semantics) depends on the rounding mode. Although these could reasonably be XFAILed in the testsuite (as we do in some cases for arguments very close to a function's overflow threshold when an error of a few ulps in the implementation can result in the implementation not agreeing with an ideal one on whether overflow takes place - the testsuite isn't smart enough to handle this automatically), since these functions aren't required to be correctly rounding, I made the implementation check for and handle this case specially. The Makefile ordering expected by lint-makefiles for the new functions is a bit peculiar, but I implemented it in this patch so that the test passes; I don't know why log2 also needed moving in one Makefile variable setting when it didn't in my previous patches, but the failure showed a different place was expected for that function as well. The powerpc64le IFUNC setup seems not to be as self-contained as one might hope; it shouldn't be necessary to add IFUNCs for new functions such as these simply to get them building, but without setting up IFUNCs for the new functions, there were undefined references to __GI___expm1f128 (that IFUNC machinery results in no such function being defined, but doesn't stop include/math.h from doing the redirection resulting in the exp2m1f128 and exp10m1f128 implementations expecting to call it). Tested for x86_64 and x86, and with build-many-glibcs.py.
2024-06-17 16:31:49 +00:00
self.add_tests('exp2m1', 'r', ['r'])
self.add_tests('exp10m1', 'r', ['r'])
self.add_tests('log2p1', 'r', ['r'])
self.add_tests('log10p1', 'r', ['r'])
self.add_tests('logp1', 'r', ['r'])
# C23 functions.
Add fmaximum, fminimum functions C2X adds new <math.h> functions for floating-point maximum and minimum, corresponding to the new operations that were added in IEEE 754-2019 because of concerns about the old operations not being associative in the presence of signaling NaNs. fmaximum and fminimum handle NaNs like most <math.h> functions (any NaN argument means the result is a quiet NaN). fmaximum_num and fminimum_num handle both quiet and signaling NaNs the way fmax and fmin handle quiet NaNs (if one argument is a number and the other is a NaN, return the number), but still raise "invalid" for a signaling NaN argument, making them exceptions to the normal rule that a function with a floating-point result raising "invalid" also returns a quiet NaN. fmaximum_mag, fminimum_mag, fmaximum_mag_num and fminimum_mag_num are corresponding functions returning the argument with greatest or least absolute value. All these functions also treat +0 as greater than -0. There are also corresponding <tgmath.h> type-generic macros. Add these functions to glibc. The implementations use type-generic templates based on those for fmax, fmin, fmaxmag and fminmag, and test inputs are based on those for those functions with appropriate adjustments to the expected results. The RISC-V maintainers might wish to add optimized versions of fmaximum_num and fminimum_num (for float and double), since RISC-V (F extension version 2.2 and later) provides instructions corresponding to those functions - though it might be at least as useful to add architecture-independent built-in functions to GCC and teach the RISC-V back end to expand those functions inline, which is what you generally want for functions that can be implemented with a single instruction. Tested for x86_64 and x86, and with build-many-glibcs.py.
2021-09-28 23:31:35 +00:00
self.add_tests('fmaximum', 'r', ['r', 'r'])
self.add_tests('fmaximum_mag', 'r', ['r', 'r'])
self.add_tests('fmaximum_num', 'r', ['r', 'r'])
self.add_tests('fmaximum_mag_num', 'r', ['r', 'r'])
self.add_tests('fminimum', 'r', ['r', 'r'])
self.add_tests('fminimum_mag', 'r', ['r', 'r'])
self.add_tests('fminimum_num', 'r', ['r', 'r'])
self.add_tests('fminimum_mag_num', 'r', ['r', 'r'])
# Miscellaneous functions.
self.add_tests('scalb', 's', ['s', 's'])
def tests_text(self):
"""Return the text of the generated testcase."""
test_list = [''.join(self.test_text_list),
'static const struct test tests[] =\n'
' {\n',
''.join(self.test_array_list),
' };\n']
footer_list = ['static int\n'
'do_test (void)\n'
'{\n'
' for (size_t i = 0;\n'
' i < sizeof (tests) / sizeof (tests[0]);\n'
' i++)\n'
' {\n'
' called_mant_dig = 0;\n'
' called_func_name = "";\n'
' tests[i].func ();\n'
' if (called_mant_dig == tests[i].mant_dig\n'
' && strcmp (called_func_name,\n'
' tests[i].func_name) == 0)\n'
' num_pass++;\n'
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
'#if !__GNUC_PREREQ (7, 0)\n'
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
' else if (tests[i].narrow_mant_dig > 0\n'
' && (called_mant_dig\n'
' >= tests[i].narrow_mant_dig)\n'
' && strcmp (called_func_name,\n'
' tests[i].func_name) == 0)\n'
' {\n'
' num_pass++;\n'
' printf ("Test %zu (%s):\\n"\n'
' " Expected: %s precision %d\\n"\n'
' " Actual: %s precision %d\\n"\n'
' " (OK with old GCC)\\n\\n",\n'
' i, tests[i].test_name,\n'
' tests[i].func_name,\n'
' tests[i].mant_dig,\n'
' called_func_name, called_mant_dig);\n'
' }\n'
C2x semantics for <tgmath.h> <tgmath.h> implements semantics for integer generic arguments that handle cases involving _FloatN / _FloatNx types as specified in TS 18661-3 plus some defect fixes. C2x has further changes to the semantics for <tgmath.h> macros with such types, which should also be considered defect fixes (although handled through the integration of TS 18661-3 in C2x rather than through an issue tracking process). Specifically, the rules were changed because of problems raised with using the macros with the evaluation format types such as float_t and _Float32_t: the older version of the rules didn't allow passing _FloatN / _FloatNx types to the narrowing macros returning float or double, or passing float / double / long double to the narrowing macros returning _FloatN / _FloatNx, which was a problem with the evaluation format types which could be either kind of type depending on the value of FLT_EVAL_METHOD. Thus the new rules allow cases of mixing types which were not allowed before, and, as part of the changes, the handling of integer arguments was also changed: if there is any _FloatNx generic argument, integer generic arguments are treated as _Float32x (not double), while the rule about treating integer arguments to narrowing macros returning _FloatN or _FloatNx as _Float64 not double was removed (no longer needed now double is a valid argument to such macros). I've implemented the changes in GCC's __builtin_tgmath, which thus requires updates to glibc's test expectations so that the tests continue to build with GCC 13 (the test is also updated to test the argument types that weren't allowed before but are now valid under C2x rules). Given those test changes, it's then also necessary to fix the implementations in <tgmath.h> to have appropriate semantics with older GCC so that the tests pass with GCC versions before GCC 13 as well. For some cases (non-narrowing macros with two or three generic arguments; narrowing macros returning _Float32x), the older version of __builtin_tgmath doesn't correspond sufficiently well to C2x semantics, so in those cases <tgmath.h> is adjusted to use the older macro implementation instead of __builtin_tgmath. The older macro implementation is itself adjusted to give the desired semantics, with GCC 7 and later. (It's not possible to get the right semantics in all cases for the narrowing macros with GCC 6 and before when the _FloatN / _FloatNx names are typedefs rather than distinct types.) Tested as follows: with the full glibc testsuite for x86_64, GCC 6, 7, 11, 13; with execution of the math/tests for aarch64, arm, powerpc and powerpc64le, GCC 6, 7, 12 and 13 (powerpc64le only with GCC 12 and 13); with build-many-glibcs.py with GCC 6, 7, 12 and 13.
2023-01-06 19:33:29 +00:00
' else if (tests[i].narrow_mant_dig == 0\n'
' && strcmp (called_func_name,\n'
' tests[i].func_name) == 0)\n'
' {\n'
' num_pass++;\n'
' printf ("Test %zu (%s):\\n"\n'
' " Expected: %s precision %d\\n"\n'
' " Actual: %s precision %d\\n"\n'
' " (unavoidable with old GCC)'
'\\n\\n",\n'
' i, tests[i].test_name,\n'
' tests[i].func_name,\n'
' tests[i].mant_dig,\n'
' called_func_name, called_mant_dig);\n'
' }\n'
Add tgmath.h macros for narrowing functions. When adding some of the TS 18661 narrowing functions for glibc 2.28, I deferred adding corresponding <tgmath.h> support because of unresolved questions about the specification for those type-generic macros, especially in relation to _FloatN and _FloatNx types. Those issues are now clarified in the response to Clarification Request 13 to TS 18661-3, and this patch adds the deferred tgmath.h support. As with other tgmath.h macros, there are fairly straightforward implementations based on __builtin_tgmath for GCC 8 and later, which result in exactly the right function being called in each case, and more complicated implementations for GCC 7 and earlier, which generally result in a function being called whose arguments have the right format (i.e. an alias for the right function), but which might not be exactly the function name specified by TS 18661. In one case with older compilers (f32x* macros, where the type _Float64x exists and all the arguments have type _Float32 or _Float32x), there is a further relaxation and the function called may have arguments narrower than the one specified by the TS, but still wide enough to represent the arguments exactly, so the result of the call is unchanged (as this does not affect any case where rounding of integer arguments might be involved). With GCC 6 or before this is inherently unavoidable (but still harmless and not detectable by how the compiled program behaves, unless it redefines the functions in question like the testcases do) because _Float32x and _Float64 are both typedefs for double in that case but the specified semantics result in different functions, with different argument formats, being called for those two argument types. Tests for the new macros are handled through gen-tgmath-tests.py, which deals with the special-case handling for older GCC. Tested as follows: with the full glibc testsuite on x86_64 and x86 (with GCC 6, 7 and 8); with the math/ tests on aarch64 and arm (with GCC 6, 7 and 8); with build-many-glibcs.py (with GCC 6, 7 and 9). * math/tgmath.h [__HAVE_FLOAT128X]: Give error. [(__HAVE_FLOAT64X && !__HAVE_FLOAT128) || (__HAVE_FLOAT128 && !__HAVE_FLOAT64X)]: Likewise. (__TGMATH_2_NARROW_F): Likewise. (__TGMATH_2_NARROW_D): New macro. (__TGMATH_2_NARROW_F16): Likewise. (__TGMATH_2_NARROW_F32): Likewise. (__TGMATH_2_NARROW_F64): Likewise. (__TGMATH_2_NARROW_F32X): Likewise. (__TGMATH_2_NARROW_F64X): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F16): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F64): Likewise. [__HAVE_BUILTIN_TGMATH] (__TGMATH_NARROW_FUNCS_F32X): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dadd): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fdiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (ddiv): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dmul): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (fsub): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)] (dsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT16] (f16sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32] (f32sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64add): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64div): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64mul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64 && (__HAVE_FLOAT64X || __HAVE_FLOAT128)] (f64sub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT32X] (f32xsub): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xadd): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xdiv): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xmul): Likewise. [__GLIBC_USE (IEC_60559_TYPES_EXT) && __HAVE_FLOAT64X && (__HAVE_FLOAT128X || __HAVE_FLOAT128)] (f64xsub): Likewise. * math/gen-tgmath-tests.py (Type): Add members non_standard_real_argument_types_list, long_double_type, complex_float64_type and float32x_ext_type. (Type.__init__): Set the new members. (Type.floating_type): Add new argument floatn. (Type.real_floating_type): Likewise. (Type.can_combine_types): Likewise. (Type.combine_types): Likewise. (Type.init_types): Create internal Float32x_ext type. (Tests.__init__): Define Float32x_ext in generated C code. (Tests.add_tests): Handle narrowing functions. (Tests.add_all_tests): Likewise. (Tests.tests_text): Allow variation in mant_dig for narrowing functions with compilers before GCC 8. * math/Makefile (tgmath3-narrow-types): New variable. (tgmath3-narrow-macros): Likewise. (tgmath3-macros): Add $(tgmath3-narrow-macros).
2019-08-21 12:06:44 +00:00
'#endif\n'
' else\n'
' {\n'
' num_fail++;\n'
' printf ("Test %zu (%s):\\n"\n'
' " Expected: %s precision %d\\n"\n'
' " Actual: %s precision %d\\n\\n",\n'
' i, tests[i].test_name,\n'
' tests[i].func_name,\n'
' tests[i].mant_dig,\n'
' called_func_name, called_mant_dig);\n'
' }\n'
' }\n'
' printf ("%d pass, %d fail\\n", num_pass, num_fail);\n'
' return num_fail != 0;\n'
'}\n'
'\n'
'#include <support/test-driver.c>']
return ''.join(self.header_list + test_list + footer_list)
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
def check_macro_list(self, macro_list):
"""Check the list of macros that can be tested."""
if self.macros_seen != set(macro_list):
print('error: macro list mismatch')
sys.exit(1)
def main():
"""The main entry point."""
Type.init_types()
t = Tests()
Split test-tgmath3 by function. It has been noted that test-tgmath3 is slow to compile, and to link on some systems <https://sourceware.org/ml/libc-alpha/2018-02/msg00477.html>, because of the size of the test. I'm working on tgmath.h support for the TS 18661-1 / 18661-3 functions that round their results to a narrower type. For the functions already present in glibc, this wouldn't make test-tgmath3 much bigger, because those functions only have two arguments. For the narrowing versions of fma (for which I've not yet added the functions to glibc), however, it would result in many configurations building tests of the type-generic macros f32fma, f64fma, f32xfma, f64xfma, each with 21 possible types for each of three arguments (float, double, long double aren't valid argument types for these macros when they return a _FloatN / _FloatNx type), so substantially increasing the size of the testcase. To avoid further increasing the size of a single test when adding the type-generic narrowing fma macros, this patch arranges for the test-tgmath3 tests to be run separately for each function tested. The fma tests are still by far the largest (next is pow, as that has two arguments that can be real or complex; after that, the two-argument real-only functions), but each type-generic fma macro for a different return type would end up with its tests being run separately, rather than increasing the size of a single test. To avoid accidentally missing testing a macro because gen-tgmath-tests.py supports testing it but the makefile fails to call it for that function, a test is also added that verifies that the lists of macros in the makefile and gen-tgmath-tests.py agree. Tested for x86_64. * math/gen-tgmath-tests.py: Import sys. (Tests.__init__): Initialize macros_seen. (Tests.add_tests): Add macro to macros_seen. Only generate tests if requested to do so for this macro. (Tests.add_all_tests): Take argument for macro for which to generate tests. (Tests.check_macro_list): New function. (main): Handle check-list argument and argument specifying macro for which to generate tests. * math/Makefile [PYTHON] (tgmath3-macros): New variable. [PYTHON] (tgmath3-macro-tests): Likewise. [PYTHON] (tests): Add $(tgmath3-macro-tests) not test-tgmath3. [PYTHON] (generated): Add $(addsuffix .c,$(tgmath3-macro-tests)) not test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): Remove. [PYTHON] ($(tgmath3-macro-tests:%=$(objpfx)%.o): Add -fno-builtin to CFLAGS. [PYTHON] ($(objpfx)test-tgmath3.c): Replace rule by.... [PYTHON] ($(foreach m,$(tgmath3-macros),$(objpfx)test-tgmath3-$(m).c): ... this. New rule. [PYTHON] (tests-special): Add $(objpfx)test-tgmath3-macro-list.out. [PYTHON] ($(objpfx)test-tgmath3-macro-list.out): New rule.
2018-05-18 17:30:18 +00:00
if sys.argv[1] == 'check-list':
macro = None
macro_list = sys.argv[2:]
else:
macro = sys.argv[1]
macro_list = []
t.add_all_tests(macro)
if macro:
print(t.tests_text())
else:
t.check_macro_list(macro_list)
if __name__ == '__main__':
main()