about summary refs log tree commit diff
path: root/math/gen-tgmath-tests.py
Commit message (Collapse)AuthorAgeFilesLines
* Update copyright dates with scripts/update-copyrights.Joseph Myers2018-01-011-1/+1
| | | | | | | * All files with FSF copyright notices: Update copyright dates using scripts/update-copyrights. * locale/programs/charmap-kw.h: Regenerated. * locale/programs/locfile-kw.h: Likewise.
* Fix gen-tgmath-tests.py for _Float64, _Float64x testing.Joseph Myers2017-11-241-2/+2
| | | | | | | | | | | | | | math/gen-tgmath-tests.py was missing a create_type argument when creating the internal types for combinations of long double with _Float64 and _Float64x, so resulting in output that did not compile when glibc support for those types was enabled. This patch adds the missing argument so that the tests properly compile in that case. Tested for x86_64, including in conjunction with _Float64x support patches. * math/gen-tgmath-tests.py (Type.init_types): Pass suffix argument for combinations of long double with _Float64 and _Float64x.
* Fix tgmath.h handling of complex integers (bug 21684).Joseph Myers2017-08-221-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix tgmath.h for __int128 (bug 21686).Joseph Myers2017-08-021-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | When a tgmath.h macro is passed a double argument and an argument of type __int128, it generates a call to a long double function (although the result still gets converted to type double). __int128 is similar enough to integer types that it should be handled consistently like them, so always like double for these macros rather than sometimes like double and sometimes like long double. This patch fixes the logic accordingly and makes gen-tgmath-tests.py generate tests for __int128. Tested for x86_64 and x86. [BZ #21686] * math/tgmath.h (__TGMATH_BINARY_REAL_ONLY): Add arguments before comparing size with that of double. (__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_BINARY_REAL_IMAG): Likewise. * math/gen-tgmath-tests.py (Type.init_types): Create __int128 and unsigned __int128 types.
* Fix tgmath.h for bit-fields (bug 21685).Joseph Myers2017-08-021-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* Fix gen-tgmath-tests.py output for GCC 7 <float.h>.Joseph Myers2017-06-281-1/+2
| | | | | * math/gen-tgmath-tests.py (Tests.__init__): Define __STDC_WANT_IEC_60559_TYPES_EXT__ at start of generated file.
* Support _Float128 in tgmath.h.Joseph Myers2017-06-281-8/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds tgmath.h support for _Float128, so eliminating the awkward caveat in NEWS about the type not being supported there. This does inevitably increase the size of macro expansions (which grows particularly fast when you have nested calls to tgmath.h macros), but only when _Float128 is supported and the declarations of _Float128 interfaces are visible; otherwise the expansions are unchanged. Tested for x86_64 and arm. * math/tgmath.h: Include <bits/libc-header-start.h> and <bits/floatn.h>. (__TGMATH_F128): New macro. (__TGMATH_CF128): Likewise. (__TGMATH_UNARY_REAL_ONLY): Use __TGMATH_F128. (__TGMATH_UNARY_REAL_RET_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_ONLY): Likewise. (__TGMATH_BINARY_FIRST_REAL_STD_ONLY): New macro. (__TGMATH_BINARY_REAL_ONLY): Use __TGMATH_F128. (__TGMATH_BINARY_REAL_STD_ONLY): New macro. (__TGMATH_BINARY_REAL_RET_ONLY): Use __TGMATH_F128. (__TGMATH_TERNARY_FIRST_SECOND_REAL_ONLY): Likewise. (__TGMATH_TERNARY_REAL_ONLY): Likewise. (__TGMATH_TERNARY_FIRST_REAL_RET_ONLY): Likewise. (__TGMATH_UNARY_REAL_IMAG): Use __TGMATH_CF128. (__TGMATH_UNARY_IMAG): Use __TGMATH_F128. (__TGMATH_UNARY_REAL_IMAG_RET_REAL): Use __TGMATH_CF128. (__TGMATH_BINARY_REAL_IMAG): Likewise. (nexttoward): Use __TGMATH_BINARY_FIRST_REAL_STD_ONLY. [__USE_MISC] (scalb): Use __TGMATH_BINARY_REAL_STD_ONLY. * math/gen-tgmath-tests.py (Type.init_types): Enable _FloatN and _FloatNx types if the corresponding HUGE_VAL macros are defined.
* Use clog10 not __clog10 in tgmath.h log10 macro.Joseph Myers2017-06-281-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | As a GNU extension, for _GNU_SOURCE glibc's complex.h provides a clog10 function and tgmath.h supports complex arguments to the log10 macro. However, tgmath.h uses __clog10 not clog10 in defining the macro. There is no namespace reason (ignoring the block-scope namespace issues that would apply equally to *every* function called by tgmath.h macros) for using __clog10 here, since this is only for _GNU_SOURCE so clog10 is always visible when this macro definition is used. Furthermore, __clog10f128 is not exported, so supporting _Float128 in tgmath.h implies using clog10 not __clog10 there. (__clog10 and clog10 aren't used in libstdc++ either, although that library would have a good case for using the __clog10 reserved-namespace export: the standard C++ library includes log10 of a complex number.) This patch duly changes the header to use clog10, and enables tests of the macro for complex arguments. Tested for x86_64. * math/tgmath.h [__USE_GNU] (log10): Use clog10 not __clog10. * math/gen-tgmath-tests.py (Tests.add_all_tests): Test log10 for complex arguments.
* Fix tgmath.h totalorder, totalordermag return type (bug 21687).Joseph Myers2017-06-281-2/+2
| | | | | | | | | | | | | | | | | | | The tgmath.h totalorder and totalordermag macros wrongly return a floating-point type. They should return int, like the underlying functions. This patch fixes them accordingly, updating tests including enabling tests of those functions from gen-tgmath-tests.py. Tested for x86_64. [BZ #21687] * math/tgmath.h (__TGMATH_BINARY_REAL_RET_ONLY): New macro. (totalorder): Use it. (totalordermag): Likewise. * math/gen-tgmath-tests.py (Tests.add_all_tests): Enable tests of totalorder and totalordermag. * math/test-tgmath.c (F(compile_test)): Do not call totalorder or totalordermag in arguments of calls to those functions. (NCALLS): Change to 134.
* Add more thorough generated tgmath.h test.Joseph Myers2017-06-281-0/+608
This patch adds a more thorough test of tgmath.h macros, verifying both the return type and the function called for all the cases of valid argument types. (Cases with current problems - I've just filed four bugs - are disabled or omitted pending fixing those problems.) The test uses a Python generator (works with both Python 2 and 3) to generate a C file which is then built and run as a test in the usual way (and that C file includes its own dummy definitions of libm functions similar to existing tgmath.h tests). The motivation is to make it easier to add tests of tgmath.h for _Float128 when adding tgmath.h support for that type; the _FloatN / _FloatNx support is present in the script, but disabled until the tgmath.h support is written. Tested for x86_64, and for arm to check things in the long double = double case. (In that case, it's OK to call either double or long double functions when the selected type is double or long double, as long as the return type of the macro is exactly correct.) * math/gen-tgmath-tests.py: New file. * math/Makefile [PYTHON] (tests): Add test-tgmath3. [PYTHON] (generated): Add test-tgmath3.c. [PYTHON] (CFLAGS-test-tgmath3.c): New variable. [PYTHON] ($(objpfx)test-tgmath3.c): New rule.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-11-07 10:26:26 +0000