about summary refs log tree commit diff
path: root/math/math.h
Commit message (Collapse)AuthorAgeFilesLines
* Refer to C23 in place of C2X in glibcJoseph Myers2024-02-011-12/+12
| | | | | | | | | | | | | | | WG14 decided to use the name C23 as the informal name of the next revision of the C standard (notwithstanding the publication date in 2024). Update references to C2X in glibc to use the C23 name. This is intended to update everything *except* where it involves renaming files (the changes involving renaming tests are intended to be done separately). In the case of the _ISOC2X_SOURCE feature test macro - the only user-visible interface involved - support for that macro is kept for backwards compatibility, while adding _ISOC23_SOURCE. Tested for x86_64.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2024-01-011-1/+1
|
* Stop applying a GCC-specific workaround on clang [BZ #30550]Tulio Magno Quites Machado Filho2023-06-301-1/+2
| | | | | | | | | | GCC was the only compiler affected by the issue with __builtin_isinf_sign and float128. Fix BZ #30550. Reported-by: Qiu Chaofan <qiucofan@cn.ibm.com> Reviewed-by: Florian Weimer <fweimer@redhat.com>
* Fix all the remaining misspellings -- BZ 25337Paul Pluzhnikov2023-06-021-1/+1
|
* Update copyright dates with scripts/update-copyrightsJoseph Myers2023-01-061-1/+1
|
* Fix iseqsig for _FloatN and _FloatNx in C++ with GCC 13Joseph Myers2022-09-301-1/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | With GCC 13, _FloatN and _FloatNx types, when they exist, are distinct types like they are in C with GCC 7 and later, rather than typedefs for types such as float, double or long double. This breaks the templated iseqsig implementation for C++ in <math.h>, when used with types that were previously implemented as aliases. Add the necessary definitions for _Float32, _Float64, _Float128 (when the same format as long double), _Float32x and _Float64x in this case, so that iseqsig can be used with such types in C++ with GCC 13 as it could with previous GCC versions. Also add tests for calling iseqsig in C++ with arguments of such types (more minimal than existing tests, so that they can work with older GCC versions and without relying on any C++ library support for the types or on hardcoding details of their formats). The LDBL_MANT_DIG != 106 conditionals on some tests are because the type-generic comparison macros have undefined behavior when neither argument has a type whose set of values is a subset of those for the type of the other argument, which applies when one argument is IBM long double and the other is an IEEE format wider than binary64. Tested with build-many-glibcs.py glibcs build for aarch64-linux-gnu i686-linux-gnu mips-linux-gnu mips64-linux-gnu-n32 powerpc-linux-gnu powerpc64le-linux-gnu x86_64-linux-gnu.
* math: Fix float conversion regressions with gcc-12 [BZ #28713]Szabolcs Nagy2022-01-101-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Converting double precision constants to float is now affected by the runtime dynamic rounding mode instead of being evaluated at compile time with default rounding mode (except static object initializers). This can change the computed result and cause performance regression. The known correctness issues (increased ulp errors) are already fixed, this patch fixes remaining cases of unnecessary runtime conversions. Add float M_* macros to math.h as new GNU extension API. To avoid conversions the new M_* macros are used and instead of casting double literals to float, use float literals (only required if the conversion is inexact). The patch was tested on aarch64 where the following symbols had new spurious conversion instructions that got fixed: __clog10f __gammaf_r_finite@GLIBC_2.17 __j0f_finite@GLIBC_2.17 __j1f_finite@GLIBC_2.17 __jnf_finite@GLIBC_2.17 __kernel_casinhf __lgamma_negf __log1pf __y0f_finite@GLIBC_2.17 __y1f_finite@GLIBC_2.17 cacosf cacoshf casinhf catanf catanhf clogf gammaf_positive Fixes bug 28713. Reviewed-by: Paul Zimmermann <Paul.Zimmermann@inria.fr>
* Update copyright dates with scripts/update-copyrightsPaul Eggert2022-01-011-1/+1
| | | | | | | | | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 7061 files FOO. I then removed trailing white space from math/tgmath.h, support/tst-support-open-dev-null-range.c, and sysdeps/x86_64/multiarch/strlen-vec.S, to work around the following obscure pre-commit check failure diagnostics from Savannah. I don't know why I run into these diagnostics whereas others evidently do not. remote: *** 912-#endif remote: *** 913: remote: *** 914- remote: *** error: lines with trailing whitespace found ... remote: *** error: sysdeps/unix/sysv/linux/statx_cp.c: trailing lines
* Add narrowing square root functionsJoseph Myers2021-09-101-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* Update floating-point feature test macro handling for C2XJoseph Myers2021-06-011-8/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ISO C2X has made some changes to the handling of feature test macros related to features from the floating-point TSes, and to exactly what such features are present in what headers, that require corresponding changes in glibc. * For the few features that were controlled by __STDC_WANT_IEC_60559_BFP_EXT__ (and the corresponding DFP macro) in C2X, there is now instead a new feature test macro __STDC_WANT_IEC_60559_EXT__ covering both binary and decimal FP. This controls CR_DECIMAL_DIG in <float.h> (provided by GCC; I implemented support for the new feature test macro for GCC 11) and the totalorder and payload functions in <math.h>. C2X no longer says anything about __STDC_WANT_IEC_60559_BFP_EXT__ (so it's appropriate for that macro to continue to enable exactly the features from TS 18661-1). * The SNAN macros for each floating-point type have moved to <float.h> (and been renamed in the process). Thus, the copies in <math.h> should only be defined for __STDC_WANT_IEC_60559_BFP_EXT__, not for C2X. * The fmaxmag and fminmag functions have been removed (replaced by new functions for the new min/max operations in IEEE 754-2019). Thus those should also only be declared for __STDC_WANT_IEC_60559_BFP_EXT__. * The _FloatN / _FloatNx handling for the last two points in glibc is trickier, since __STDC_WANT_IEC_60559_TYPES_EXT__ is still in C2X (the integration of TS 18661-3 as an Annex, that is, which hasn't yet been merged into the C standard git repository but has been accepted by WG14), so C2X with that macro should not declare some things that are declared for older standards with that macro. The approach taken here is to provide the declarations (when __STDC_WANT_IEC_60559_TYPES_EXT__ is enabled) only when (defined __USE_GNU || !__GLIBC_USE (ISOC2X)), so if C2X features are enabled then those declarations (that are only in TS 18661-3 and not in C2X) will only be provided if _GNU_SOURCE is defined as well. Thus _GNU_SOURCE remains a superset of the TS features as well as of C2X. Some other somewhat related changes in C2X are not addressed here. There's an open proposal not to include the fmin and fmax functions for the _FloatN / _FloatNx types, given the new min/max operations, which could be handled like the previous point if adopted. And the fromfp functions have been changed to return a result in floating type rather than intmax_t / uintmax_t; my inclination there is to treat that like that change of totalorder type (new symbol versions etc. for the ABI change; old versions become compat symbols and are no longer supported as an API). Tested for x86_64 and x86.
* Update copyright dates with scripts/update-copyrightsPaul Eggert2021-01-021-1/+1
| | | | | | | | | | | | | | | | I used these shell commands: ../glibc/scripts/update-copyrights $PWD/../gnulib/build-aux/update-copyright (cd ../glibc && git commit -am"[this commit message]") and then ignored the output, which consisted lines saying "FOO: warning: copyright statement not found" for each of 6694 files FOO. I then removed trailing white space from benchtests/bench-pthread-locks.c and iconvdata/tst-iconv-big5-hkscs-to-2ucs4.c, to work around this diagnostic from Savannah: remote: *** pre-commit check failed ... remote: *** error: lines with trailing whitespace found remote: error: hook declined to update refs/heads/master
* Rename __LONG_DOUBLE_USES_FLOAT128 to __LDOUBLE_REDIRECTS_TO_FLOAT128_ABIPaul E. Murphy2020-04-301-6/+6
| | | | | | | | | | | | | | | Improve the commentary to aid future developers who will stumble upon this novel, yet not always perfect, mechanism to support alternative formats for long double. Likewise, rename __LONG_DOUBLE_USES_FLOAT128 to __LDOUBLE_REDIRECTS_TO_FLOAT128_ABI now that development work has settled down. The command used was git grep -l __LONG_DOUBLE_USES_FLOAT128 ':!./ChangeLog*' | \ xargs sed -i 's/__LONG_DOUBLE_USES_FLOAT128/__LDOUBLE_REDIRECTS_TO_FLOAT128_ABI/g' Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* Remove __NO_MATH_INLINESAdhemerval Zanella2020-04-171-7/+0
| | | | | | With fenvinline.h removal the flag is not used anymore. Checked on x86_64-linux-gnu.
* math: Remove mathinlineAdhemerval Zanella2020-03-191-6/+0
| | | | | With m68k bits moved to internal headers, no architectures export additional optimizations on mathinline.
* ldbl-128ibm-compat: Redirect long double functions to f128/ieee128 functionsTulio Magno Quites Machado Filho2020-02-281-3/+56
| | | | | | | | | | | | | | | | Modify the headers to redirect long double functions to global __*f128 symbols or to __*ieee128 otherwise. Most of the functions in math.h benefit from the infrastructure already available for __LDBL_COMPAT. The only exceptions are nexttowardf and nexttoward that need especial treatment. Both math/bits/mathcalls-helper-functions.h and math/bits/mathcalls.h were modified in order to provide alternative redirection destinations that are essential to support functions that should not be redirected to the same name pattern of the rest of the functions, i.e.: __fpclassify, __signbit, __iseqsig, __issignaling, isinf, finite and isnan, which will be redirected to __*f128 instead of __*ieee128 used for the rest.
* Undefine redirections after long double definition on __LDBL_COMPAT [BZ #23294]Tulio Magno Quites Machado Filho2020-02-201-5/+13
| | | | | | After defining the long double redirections to double, __MATHDECL_1 has to be redefined to its previous state in order to avoid redirecting all subsequent types.
* Update copyright dates with scripts/update-copyrights.Joseph Myers2020-01-011-1/+1
|
* Remove math-finite.hWilco Dijkstra2019-10-211-220/+0
| | | | | | | | Remove math-finite.h redirections for math functions. Passes buildmanyglibc. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
* Prefer https to http for gnu.org and fsf.org URLsPaul Eggert2019-09-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Declare most TS 18661-1 interfaces for C2X.Joseph Myers2019-08-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2X adds the interfaces from TS 18661-1, and all except a handful in Annex F are unconditionally visible in C2X rather than only visible when __STDC_WANT_IEC_60559_BFP_EXT__ is defined. This patch updates glibc headers accordingly: most uses of __GLIBC_USE (IEC_60559_BFP_EXT) are changed to a new __GLIBC_USE (IEC_60559_BFP_EXT_C2X). (Regarding totalorder and totalordermag, the type-generic macros in tgmath.h will go away when the functions are changed to take pointer arguments.) * bits/libc-header-start.h (__GLIBC_USE_IEC_60559_BFP_EXT): Update comment. (__GLIBC_USE_IEC_60559_BFP_EXT_C2X): New macro. * bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Change to [__GLIBC_USE (IEC_60559_BFP_EXT_C2X)]. * include/limits.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * math/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * math/math.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * stdlib/bits/stdlib-ldbl.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * stdlib/stdint.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * stdlib/stdlib.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/aarch64/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/alpha/fpu/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/arm/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/csky/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/hppa/fpu/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/ia64/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/m68k/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/microblaze/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/mips/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/nios2/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/powerpc/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/riscv/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/s390/fpu/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/sh/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/sparc/fpu/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * sysdeps/x86/fpu/bits/fenv.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise. * math/bits/mathcalls.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise, except for totalorder, totalordermag, getpayload, setpayload and setpayloadsig. * math/tgmath.h [__GLIBC_USE (IEC_60559_BFP_EXT)]: Likewise, except for totalorder and totalordermag.
* math: Enable some math builtins for clangAdhemerval Zanella2019-03-261-6/+11
| | | | | | | | | | | | | | | This patch enable the builtin usage for clang for the C99 functions fpclassify, isfinite, isnormal, isnan, isinf, and sigbit. This allows clang optimize the calls on frontend instead of call the appropriate glibc symbols. Checked on aarch64-linux-gnu and x86_64-linux-gnu. I checked the supported version for each builtin based on released version from clang/llvm. * math/math.h (fpclassify, isfinite, isnormal, isnan): Use builtin for clang 2.8. (signbit): Use builtin for clang 3.3. (isinf): Use builtin for clang 3.7.
* Update copyright dates with scripts/update-copyrights.Joseph Myers2019-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 parameter type in C++ version of iseqsig (bug 23171)Gabriel F. T. Gomes2018-05-241-1/+1
| | | | | | | | | | | | | | | The commit commit c85e54ac6cef0faed7b7ffc722f52523dec59bf5 Author: Gabriel F. T. Gomes <gabriel@inconstante.eti.br> Date: Fri Nov 3 10:44:36 2017 -0200 Provide a C++ version of iseqsig (bug 22377) mistakenly used double parameters in the long double version of iseqsig, thus causing spurious conversions to double, as reported on bug 23171. Tested for powerpc64le and x86_64.
* powerpc: Fix the compiler type used with C++ when -mabi=ieeelongdoubleTulio Magno Quites Machado Filho2018-05-111-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | When compiling C++ code with -mabi=ieeelongdouble, KCtype is unavailable and the long double type should be used instead. This is also providing macro __HAVE_FLOAT128_UNLIKE_LDBL in order to identify the kind of long double type is being used in the current compilation unit. Notice that bits/floatn.h cannot benefit from the new macro due to order of header inclusion. * bits/floatn-common.h: Define __HAVE_FLOAT128_UNLIKE_LDBL. * math/math.h: Restrict the prototype definition for the functions issignaling(_Float128) and iszero(_Float128); and template __iseqsig_type<_Float128>, from __HAVE_DISTINCT_FLOAT128 to __HAVE_FLOAT128_UNLIKE_LDBL. * sysdeps/powerpc/bits/floatn.h [__HAVE_FLOAT128 && (!__GNUC_PREREQ (7, 0) || defined __cplusplus) && __LDBL_MANT_DIG__ == 113]: Use long double suffix for __f128() constants; define the type _Float128 as long double; and reuse long double in __CFLOAT128. Signed-off-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
* Add build infrastructure for narrowing libm functions.Joseph Myers2018-02-091-0/+284
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | TS 18661-1 defines libm functions that carry out an operation (+ - * / sqrt fma) on their arguments and return a result rounded to a (usually) narrower type, as if the original result were computed to infinite precision and then rounded directly to the result type without any intermediate rounding to the argument type. For example, fadd, faddl and daddl for addition. These are the last remaining TS 18661-1 functions left to be added to glibc. TS 18661-3 extends this to corresponding functions for _FloatN and _FloatNx types. As functions parametrized by two rather than one varying floating-point types, these functions require infrastructure in glibc that was not required for previous libm functions. This patch provides such infrastructure - excluding test support, and actual function implementations, which will be in subsequent patches. Declaring the functions uses a header bits/mathcalls-narrow.h, which is included many times, for each relevant pair of types. This will end up containing macro calls of the form __MATHCALL_NARROW (__MATHCALL_NAME (add), __MATHCALL_REDIR_NAME (add), 2); for each family of narrowing functions. (The structure of this macro call, with the calls to __MATHCALL_NAME and __MATHCALL_REDIR_NAME there rather than in the definition of __MATHCALL_NARROW, arises from the names such as "add" *not* themselves being reserved identifiers - meaning it's necessary to avoid any indirection that would result in a user-defined "add" macro being expanded.) Whereas for existing functions declaring long double functions is disabled if _LIBC in the case where they alias double functions, to facilitate defining the long double functions as aliases of the double ones, there is no such logic for the narrowing functions in this patch. Rather, the files defining such functions are expected to use #define to hide the original declarations of the alias names, to avoid errors about defining aliases with incompatible types. math/Makefile support is added for building the functions (listed in libm-narrow-fns, currently empty) for all relevant pairs of types. An internal header math-narrow.h is added for macros shared between multiple function implementations - currently a ROUND_TO_ODD macro to facilitate writing functions using the round-to-odd implementation approach, and alias macros to create all the required function aliases. libc_feholdexcept_setroundf128 and libc_feupdateenv_testf128 are added for use when required (only for x86_64). float128_private.h support is added for ldbl-128 narrowing functions to be used for _Float128. Certain things are specifically omitted from this patch and the immediate followups. tgmath.h support is deferred; there remain unresolved questions about how the type-generic macros for these functions are supposed to work, especially in the case of arguments of integer type. The math.h / bits/mathcalls-narrow.h logic, and the logic for determining what functions / aliases to define, will need some adjustments to support the sqrt and fma functions, where e.g. f32xsqrtf64 can just be an alias for sqrt rather than a separate function. TS 18661-1 defines FP_FAST_* macros but no support is included for defining them (they won't in general be true without architecture-specific optimized function versions). For each of the function groups (add sub mul div sqrt fma) there are always six functions present (e.g. fadd, faddl, daddl, f32addf64, f32addf32x, f32xaddf64). When _Float64x and _Float128 are supported, there are seven more (e.g. f32addf64x, f32addf128, f64addf64x, f64addf128, f32xaddf64x, f32xaddf128, f64xaddf128). In addition, in the ldbl-opt case there are function names such as __nldbl_daddl (an alias for f32xaddf64, which is not a reserved name in TS 18661-1, only in TS 18661-3), for calls to daddl to be mapped to in the -mlong-double-64 case. (Calls to faddl just get mapped to fadd, and for sqrt and fma there won't be __nldbl_* functions because dsqrtl and dfmal can just be mapped to sqrt and fma with -mlong-double-64.) While there are six or thirteen functions present in each group (plus __nldbl_* names only as an ABI, not an API), not all are distinct; they fall in various groups of aliases. There are two distinct versions built if long double has the same format as double; four if they have distinct formats but there is no _Float64x or _Float128 support; five if long double has binary128 format; seven when _Float128 is distinct from long double. Architecture-specific optimized versions are possible, but not included in my patches. For example, IA64 generally supports narrowing the result of most floating-point instructions; Power ISA 2.07 (POWER8) supports double values as arguments to float instructions, with the results narrowed as expected; Power ISA 3 (POWER9) supports round-to-odd for float128 instructions, so meaning that approach can be used without needing to set and restore the rounding mode and test "inexact". I intend to leave any such optimized versions to the architecture maintainers. Generally in such cases it would also make sense for calls to these functions to be expanded inline (given -fno-math-errno); I put a suggestion for TS 18661-1 built-in functions at <https://gcc.gnu.org/wiki/SummerOfCode>. Tested for x86_64 (this patch in isolation, as well as testing for various configurations in conjunction with further patches). * math/bits/mathcalls-narrow.h: New file. * include/bits/mathcalls-narrow.h: Likewise. * math/math-narrow.h: Likewise. * math/math.h (__MATHCALL_NARROW_ARGS_1): New macro. (__MATHCALL_NARROW_ARGS_2): Likewise. (__MATHCALL_NARROW_ARGS_3): Likewise. (__MATHCALL_NARROW_NORMAL): Likewise. (__MATHCALL_NARROW_REDIR): Likewise. (__MATHCALL_NARROW): Likewise. [__GLIBC_USE (IEC_60559_BFP_EXT)]: Repeatedly include <bits/mathcalls-narrow.h> with _Mret_, _Marg_ and __MATHCALL_NAME defined. [__GLIBC_USE (IEC_60559_TYPES_EXT)]: Likewise. * math/Makefile (headers): Add bits/mathcalls-narrow.h. (libm-narrow-fns): New variable. (libm-narrow-types-basic): Likewise. (libm-narrow-types-ldouble-yes): Likewise. (libm-narrow-types-float128-yes): Likewise. (libm-narrow-types-float128-alias-yes): Likewise. (libm-narrow-types): Likewise. (libm-routines): Add narrowing functions. * sysdeps/i386/fpu/fenv_private.h [__x86_64__] (libc_feholdexcept_setroundf128): New macro. [__x86_64__] (libc_feupdateenv_testf128): Likewise. * sysdeps/ieee754/float128/float128_private.h: Include <math/math-narrow.h>. [libc_feholdexcept_setroundf128] (libc_feholdexcept_setroundl): Undefine and redefine. [libc_feupdateenv_testf128] (libc_feupdateenv_testl): Likewise. (libm_alias_float_ldouble): Undefine and redefine. (libm_alias_double_ldouble): Likewise.
* Improve math_errhandlingWilco Dijkstra2018-01-031-4/+10
| | | | | | | | | | | Currently math_errhandling is always set to MATH_ERRNO | MATH_ERREXCEPT even if -fno-math-errno is used. It is not defined at all when fast-math is used. Set it to 0 with fast-math - this is noncomforming but more useful than not define math_errhandling at all. Also take __NO_MATH_ERRNO__ into account and update comment. * math/math.h (math_errhandling): Set to 0 with __FAST_MATH__. Add __NO_MATH_ERRNO__ check.
* 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.
* Provide a C++ version of iseqsig (bug 22377)Gabriel F. T. Gomes2017-12-191-2/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | In C++ mode, __MATH_TG cannot be used for defining iseqsig, because __MATH_TG relies on __builtin_types_compatible_p, which is a C-only builtin. This is true when float128 is provided as an ABI-distinct type from long double. Moreover, the comparison macros from ISO C take two floating-point arguments, which need not have the same type. Choosing what underlying function to call requires evaluating the formats of the arguments, then selecting which is wider. The macro __MATH_EVAL_FMT2 provides this information, however, only the type of the macro expansion is relevant (actually evaluating the expression would be incorrect). This patch provides a C++ version of iseqsig, in which only the type of __MATH_EVAL_FMT2 (__typeof or decltype) is used as a template parameter for __iseqsig_type. This function calls the appropriate underlying function. Tested for powerpc64le and x86_64. [BZ #22377] * math/Makefile [C++] (tests): Add test for iseqsig. * math/math.h [C++] (iseqsig): New implementation, which does not rely on __MATH_TG/__builtin_types_compatible_p. * math/test-math-iseqsig.cc: New file. * sysdeps/powerpc/powerpc64le/Makefile (CFLAGS-test-math-iseqsig.cc): New variable.
* Handle more _FloatN, _FloatNx types in __MATH_TG.Joseph Myers2017-11-031-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Continuing the preparation for additional _FloatN / _FloatNx type support, this patch prepares __MATH_TG to handle more such types. Various unhandled cases, which do not correspond to any current glibc configuration, have explicit #errors added. _Float32 and _Float64x are then handled appropriately in the _Generic case, which is the only one, other than the cases where use of sizeof is sufficient, where they should ever be explicit types at the language level instead of typedefs. There is no need to handle _Float64 or _Float32x explicitly there because the default case calling a double function is correct for those types. Tested for x86_64. * math/math.h [__HAVE_DISTINCT_FLOAT16 || __HAVE_DISTINCT_FLOAT32 || __HAVE_DISTINCT_FLOAT64 || __HAVE_DISTINCT_FLOAT32X || __HAVE_DISTINCT_FLOAT64X || __HAVE_DISTINCT_FLOAT128X]: Use #error. [__NO_LONG_DOUBLE_MATH && __HAVE_DISTINCT_FLOAT128]: Likewise. [__HAVE_DISTINCT_FLOAT128 && !__HAVE_GENERIC_SELECTION && __HAVE_FLOATN_NOT_TYPEDEF]: Likewise. [__HAVE_DISTINCT_FLOAT128 && __HAVE_GENERIC_SELECTION] (__MATH_TG_F32): New macro. [__HAVE_DISTINCT_FLOAT128 && __HAVE_GENERIC_SELECTION] (__MATH_TG_F64X): Likewise. [__HAVE_DISTINCT_FLOAT128 && __HAVE_GENERIC_SELECTION] (__MATH_TG): Use __MATH_TG_F32 and __MATH_TG_F64X.
* Adjust __MATH_EVAL_FMT2 definition to handle _Float16 better.Joseph Myers2017-10-311-0/+2
| | | | | | | | | | | | | | | | | | Continuing the preparation for additional _FloatN / _FloatNx type support, this patch adds an additional case in the definition of __MATH_EVAL_FMT2, as used in defining iseqsig: when __FLT_EVAL_METHOD__ is 0 or 32, it adds 0.0f to the arguments, so that the correct function would be selected in the case of _Float16 arguments with excess precision (were glibc to support _Float16, which of course __MATH_TG and other facilities do not at present - and _Float16 support is not part of what this patch series is aiming for, but this particular fix is simple so is included anyway). Tested for x86_64. * math/math.h [__FLT_EVAL_METHOD__ == 0 || __FLT_EVAL_METHOD__ == 32] (__MATH_EVAL_FMT2): Define to add 0.0f.
* Include bits/math-finite.h for more _FloatN, _FloatNx types.Joseph Myers2017-10-301-2/+137
| | | | | | | | | | | | | | | | | | Continuing the preparation for additional _FloatN / _FloatNx type support, this patch extends the includes of <bits/math-finite.h> to cover all such types, under conditions analogous to those for _Float128. Tested for x86_64. * math/math.h [__HAVE_DISTINCT_FLOAT16 || (__HAVE_FLOAT16 && !_LIBC)]: Include <bits/math-finite.h> with appropriate macros defined and undefined. [__HAVE_DISTINCT_FLOAT32 || (__HAVE_FLOAT32 && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT64 || (__HAVE_FLOAT64 && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT32X || (__HAVE_FLOAT32X && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT64X || (__HAVE_FLOAT64X && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT128X || (__HAVE_FLOAT128X && !_LIBC)]: Likewise.
* Remove _Mlong_double_ etc. macros.Joseph Myers2017-10-301-36/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | math.h has a macro _Mlong_double_ for the type to use when declaring long double functions, and similar macros for other types. math/Makefile uses -D_Mlong_double_=double in the case of long double having the same ABI as double. This originates with: Mon Jul 8 13:37:40 1996 Roland McGrath <roland@delasyd.gnu.ai.mit.edu> * math/math.h (_Mfloat_, _Mlong_double_): New macros, defined iff not already defined to float, long double. Use those macros for _Mdouble_ defns when including mathcalls.h. * math/Makefile [$(long-double-fcts) != yes] (CPPFLAGS): Append -D_Mlong_double_=double. However, math.h stopped declaring long double functions in the case of long double having the same ABI as double (and thus probably stopped actually needing the Makefile definition of _Mlong_double_) with: 1998-11-05 Ulrich Drepper <drepper@cygnus.com> * math/math.h: Unconditionally include bits/mathdef.h. Declare long double functions only if __NO_LONG_DOUBLE_MATH is not defined. * sysdeps/generic/bits/mathdef.h: Define only if __USE_ISOC9X. Define __NO_LONG_DOUBLE_MATH. * sysdeps/m68k/fpu/bits/mathdef.h: Define only if __USE_ISOC9X. * sysdeps/i386/fpu/bits/mathdef.h: Likewise. The declarations were since restored for compiling user code, but remain absent when _LIBC is defined, which is sufficient to avoid problems declaring function aliases of incompatible types. Thus the indirection through the _Mlong_double_ macro is not needed (probably since that 1998 patch), and this patch removes _Mlong_double_ and associated macros for other types, leaving only the macro _Mdouble_ which is actually used as the type for which a given inclusion of <bits/mathcalls.h> should declared functions. Tested for x86_64, and tested with build-many-glibcs.py that installed stripped shared libraries are unchanged by this patch. * math/math.h [!_Mfloat_] (_Mfloat_): Do not define. [!_Mlong_double_] (_Mlong_double_): Likewise. [!_Mfloat16_] (_Mfloat16_): Likewise. [!_Mfloat32_] (_Mfloat32_): Likewise. [!_Mfloat64_] (_Mfloat64_): Likewise. [!_Mfloat128_] (_Mfloat128_): Likewise. [!_Mfloat32x_] (_Mfloat32x_): Likewise. [!_Mfloat64x_] (_Mfloat64x_): Likewise. [!_Mfloat128x_] (_Mfloat128x_): Likewise. (_Mdouble_): Define without indirection through those macros. * math/complex.h [!_Mfloat_] (_Mfloat_): Do not define. [!_Mfloat128_] (_Mfloat128_): Likewise. [_Mlong_double_] (_Mlong_double_): Likewise. (_Mdouble_): Define without indirection through those macros. * math/Makefile [$(long-double-fcts) != yes] (math-CPPFLAGS): Do not add -D_Mlong_double_=double. * include/math.h [_ISOMAC] (_Mlong_double_): Do not undefine. * math/test-signgam-finite-c99.c (_Mlong_double_): Likewise.
* Add _FloatN, _FloatNx M_* constants.Joseph Myers2017-10-301-0/+84
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Continuing the preparation for additional _FloatN / _FloatNx type support, this patch adds M_* constants for such types. The decimal expansions used are all the same as used for _Float128; there's no need to reduce the precision used. In the case of _Float128x, #error is used because the constants would need additional precision, but how much is needed would depend on the actual _Float128x format used, so it's not possible to add header support simply as part of code that handles all _FloatN / _FloatNx types similarly. Tested for x86_64. * math/math.h [__HAVE_FLOAT16 && __USE_GNU] (M_Ef16): New macro. [__HAVE_FLOAT16 && __USE_GNU] (M_LOG2Ef16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_LOG10Ef16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_LN2f16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_LN10f16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_PIf16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_PI_2f16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_PI_4f16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_1_PIf16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_2_PIf16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_2_SQRTPIf16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_SQRT2f16): Likewise. [__HAVE_FLOAT16 && __USE_GNU] (M_SQRT1_2f16): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_Ef32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_LOG2Ef32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_LOG10Ef32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_LN2f32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_LN10f32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_PIf32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_PI_2f32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_PI_4f32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_1_PIf32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_2_PIf32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_2_SQRTPIf32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_SQRT2f32): Likewise. [__HAVE_FLOAT32 && __USE_GNU] (M_SQRT1_2f32): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_Ef64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_LOG2Ef64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_LOG10Ef64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_LN2f64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_LN10f64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_PIf64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_PI_2f64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_PI_4f64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_1_PIf64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_2_PIf64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_2_SQRTPIf64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_SQRT2f64): Likewise. [__HAVE_FLOAT64 && __USE_GNU] (M_SQRT1_2f64): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_Ef32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_LOG2Ef32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_LOG10Ef32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_LN2f32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_LN10f32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_PIf32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_PI_2f32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_PI_4f32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_1_PIf32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_2_PIf32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_2_SQRTPIf32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_SQRT2f32x): Likewise. [__HAVE_FLOAT32X && __USE_GNU] (M_SQRT1_2f32x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_Ef64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_LOG2Ef64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_LOG10Ef64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_LN2f64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_LN10f64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_PIf64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_PI_2f64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_PI_4f64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_1_PIf64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_2_PIf64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_2_SQRTPIf64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_SQRT2f64x): Likewise. [__HAVE_FLOAT64X && __USE_GNU] (M_SQRT1_2f64x): Likewise. [__HAVE_FLOAT128X && __USE_GNU]: Use #error.
* Include bits/mathcalls.h for more _FloatN, _FloatNx types.Joseph Myers2017-10-271-3/+123
| | | | | | | | | | | | | | | | | | | Continuing the preparation for additional _FloatN / _FloatNx type support, this patch arranges for <bits/mathcalls.h> and <bits/mathcalls-helper-functions.h> to be included for each such type under conditions and with macros defined corresponding to those already present for _Float128. Tested for x86_64. * math/math.h [__HAVE_DISTINCT_FLOAT16 || (__HAVE_FLOAT16 && !_LIBC)]: Include <bits/mathcalls-helper-functions.h> and <bits/mathcalls.h> with appropriate macros defined and undefined. [__HAVE_DISTINCT_FLOAT32 || (__HAVE_FLOAT32 && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT64 || (__HAVE_FLOAT64 && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT32X || (__HAVE_FLOAT32X && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT64X || (__HAVE_FLOAT64X && !_LIBC)]: Likewise. [__HAVE_DISTINCT_FLOAT128X || (__HAVE_FLOAT128X && !_LIBC)]: Likewise.
* Add SNAN macros for more _FloatN, _FloatNx types.Joseph Myers2017-10-261-0/+18
| | | | | | | | | | | | | | | | | | | | | This patch continues the preparation for additional _FloatN / _FloatNx type support by adding appropriately conditional definitions of SNAN* macros, corresponding to the SNANF128 definition already present. Tested for x86_64. * math/math.h [__HAVE_FLOAT16 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF16): New macro. [__HAVE_FLOAT32 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF32): Likewise. [__HAVE_FLOAT64 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF64): Likewise. [__HAVE_FLOAT32X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF32X): Likewise. [__HAVE_FLOAT64X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF64X): Likewise. [__HAVE_FLOAT128X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (SNANF128X): Likewise.
* Add HUGE_VAL macros for more _FloatN, _FloatNx types.Joseph Myers2017-10-261-0/+18
| | | | | | | | | | | | | | | | | | | | | | This patch continues the preparation for additional _FloatN / _FloatNx type support by adding appropriately conditional definitions of HUGE_VAL_* macros, corresponding to the HUGE_VAL_F128 definition already present. Tested for x86_64. * math/math.h [__HAVE_FLOAT16 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F16): New macro. [__HAVE_FLOAT32 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F32): Likewise. [__HAVE_FLOAT64 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F64): Likewise. [__HAVE_FLOAT32X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F32X): Likewise. [__HAVE_FLOAT64X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F64X): Likewise. [__HAVE_FLOAT128X && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F128X): Likewise.
* Let signbit use the builtin in C++ mode with gcc < 6.x (bug 22296)Romain Naour2017-10-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When using gcc < 6.x, signbit does not use the type-generic __builtin_signbit builtin, instead it uses __MATH_TG. However, when library support for float128 is available, __MATH_TG uses __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, libstdc++ undefines (in cmath) many macros from math.h, including signbit, so that it can provide its own functions. However, during its configure tests, libstdc++ just tests for the availability of the macros (it does not undefine them, nor does it provide its own functions). Finally, libstdc++ configure tests include math.h and get the definition of signbit that uses __MATH_TG (and __builtin_types_compatible_p). Since libstdc++ does not undefine the macros during its configure tests, they fail. This patch lets signbit use the builtin in C++ mode when gcc < 6.x is used. This allows the configure test in libstdc++ to work. Tested for x86_64. [BZ #22296] * math/math.h: Let signbit use the builtin in C++ mode with gcc < 6.x Cc: Gabriel F. T. Gomes <gftg@linux.vnet.ibm.com> Cc: Joseph Myers <joseph@codesourcery.com>
* Add C++ versions of iscanonical for ldbl-96 and ldbl-128ibm (bug 22235)Gabriel F. T. Gomes2017-10-031-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All representations of floating-point numbers in types with IEC 60559 binary exchange format are canonical. On the other hand, types with IEC 60559 extended formats, such as those implemented under ldbl-96 and ldbl-128ibm, contain representations that are not canonical. TS 18661-1 introduced the type-generic macro iscanonical, which returns whether a floating-point value is canonical or not. In Glibc, this type-generic macro is implemented using the macro __MATH_TG, which, when support for float128 is enabled, relies on __builtin_types_compatible_p to select between floating-point types. However, this use of iscanonical breaks C++ applications, because the builtin is only available in C mode. This patch provides a C++ implementation of iscanonical that relies on function overloading, rather than builtins, to select between floating-point types. Unlike the C++ implementations for iszero and issignaling, this implementation ignores __NO_LONG_DOUBLE_MATH. The double type always matches IEC 60559 double format, which is always canonical. Thus, when double and long double are the same (__NO_LONG_DOUBLE_MATH), iscanonical always returns 1 and is not implemented with __MATH_TG. Tested for powerpc64, powerpc64le and x86_64. [BZ #22235] * math/math.h: Trivial fix for unbalanced parentheses in comment. * math/Makefile [CXX] (tests): Add test-math-iscanonical.cc. (CFLAGS-test-math-iscanonical.cc): New variable. * math/test-math-iscanonical.cc: New file. * sysdeps/ieee754/ldbl-96/bits/iscanonical.h (iscanonical): Provide a C++ implementation based on function overloading, rather than using __MATH_TG, which uses C-only builtins. * sysdeps/ieee754/ldbl-128ibm/bits/iscanonical.h (iscanonical): Likewise. * sysdeps/powerpc/powerpc64le/Makefile (CFLAGS-test-math-iscanonical.cc): New variable.
* Simplify C99 isgreater macrosWilco Dijkstra2017-09-281-63/+32
| | | | | | | | | | | | | | | | Simplify the C99 isgreater macros. Although some support was added in GCC 2.97, not all targets added support until GCC 3.1. Therefore only use the builtins in math.h from GCC 3.1 onwards, and defer to generic macros otherwise. Improve the generic isunordered macro to use compares rather than call fpclassify twice - this is not only faster but also correct for signaling NaNs. * math/math.h: Improve handling of C99 isgreater macros. * sysdeps/alpha/fpu/bits/mathinline.h: Remove isgreater macros. * sysdeps/m68k/m680x0/fpu/bits/mathinline.h: Likewise. * sysdeps/powerpc/bits/mathinline.h: Likewise. * sysdeps/sparc/fpu/bits/mathinline.h: Likewise. * sysdeps/x86/fpu/bits/mathinline.h: Likewise.
* Let fpclassify use the builtin when optimizing for size in C++ mode (bug 22146)Gabriel F. T. Gomes2017-09-221-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When optimization for size is on (-Os), fpclassify does not use the type-generic __builtin_fpclassify builtin, instead it uses __MATH_TG. However, when library support for float128 is available, __MATH_TG uses __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, libstdc++ undefines (in cmath) many macros from math.h, including fpclassify, so that it can provide its own functions. However, during its configure tests, libstdc++ just tests for the availability of the macros (it does not undefine them, nor does it provide its own functions). Finally, when libstdc++ is configured with optimization for size enabled, its configure tests include math.h and get the definition of fpclassify that uses __MATH_TG (and __builtin_types_compatible_p). Since libstdc++ does not undefine the macros during its configure tests, they fail. This patch lets fpclassify use the builtin in C++ mode, even when optimization for size is on. This allows the configure test in libstdc++ to work. Tested for powerpc64le and x86_64. [BZ #22146] math/math.h: Let fpclassify use the builtin in C++ mode, even when optimazing for size.
* math.h: Warn about an already-defined log macroFlorian Weimer2017-09-041-0/+5
| | | | | | | | This is a common programming error, and the cause of the problem is not always obvious. <tgmath.h> defines a log macro, but it includes <math.h> before that, so that is compatible with the warning.
* math/math.h (HUGE_VAL): Improve commentary.Zack Weinberg2017-09-011-2/+7
|
* Simplify NAN definitions.Joseph Myers2017-08-311-2/+9
| | | | | | | | | | | | | | | | | | | | Similar to my patches for HUGE_VAL and INFINITY. this patch eliminates the bits/nan.h headers. __builtin_nanf ("") is used to define NAN for GCC 3.3 and later; the fallback is (0.0f / 0.0f), which is a constant expression for a quiet NaN of type float, but raises a spurious "invalid" exception outside static initializers, which seems the best that can be done purely in standard C. Again, if anyone actually uses a compiler with its own incompatible extension for producing a constant quiet NaN, we can add compiler conditionals. Tested for x86_64. * math/math.h [__USE_ISOC99] (NAN): Define directly here. Do not include <bits/nan.h>. * math/Makefile (headers): Remove bits/nan.h. * bits/nan.h: Remove. * sysdeps/ieee754/bits/nan.h: Likewise. * sysdeps/mips/bits/nan.h: Likewise.
* Simplify INFINITY definitions.Joseph Myers2017-08-311-2/+6
| | | | | | | | | | | | | | | | Similar to my patch for HUGE_VAL, this patch eliminates the bits/inf.h headers and just unconditionally uses the same definitions as the sysdeps/ieee754 version did (__builtin_inff () for GCC >= 3.3, otherwise HUGE_VALF), directly in math.h, so removing an unnecessary level of indirection. Tested for x86_64. * math/math.h [__USE_ISOC99] (INFINITY): Define directly here. Do not include <bits/inf.h>. * math/Makefile (headers): Remove bits/inf.h. * bits/inf.h: Remove. * sysdeps/ieee754/bits/inf.h: Likewise.
* Simplify HUGE_VAL definitions.Joseph Myers2017-08-311-8/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are various bits/huge_val*.h headers to define HUGE_VAL and related macros. All of them use __builtin_huge_val etc. for GCC 3.3 and later. Then there are various fallbacks, such as using a large hex float constant for GCC 2.96 and later, or using unions (with or without compound literals) to construct the bytes of an infinity, with this last being the reason for having architecture-specific files. Supporting TS 18661-3 _FloatN / _FloatNx types that have the same format as other supported types will mean adding more such macros; needing to add more headers for them doesn't seem very desirable. The fallbacks based on bytes of the representation of an infinity do not meet the standard requirements for a constant expression. At least one of them is also wrong: sysdeps/sh/bits/huge_val.h is producing a mixed-endian representation which does not match what GCC does. This patch eliminates all those headers, defining the macros directly in math.h. For GCC 3.3 and later, the built-in functions are used as now. For other compilers, a large constant 1e10000 (with appropriate suffix) is used. This is like the fallback for GCC 2.96 and later, but without using hex floats (which have no apparent advantage here). It is unambiguously valid standard C for all floating-point formats with infinities, which covers all formats supported by glibc or likely to be supported by glibc in future (C90 DR#025 said that if a floating-point format represents infinities, all real values lie within the range of representable values, so the constraints for constant expressions are not violated), but may generate compiler warnings and wouldn't handle the TS 18661-1 FENV_ROUND pragma correctly. If someone is actually using a compiler with glibc that does not claim to be GCC 3.3 or later, but which has a better way to define the HUGE_VAL macros, we can always add compiler conditionals in with alternative definitions. I intend to make similar changes for INF and NAN. The SNAN macros already just use __builtin_nans etc. with no fallback for compilers not claiming to be GCC 3.3 or later. Tested for x86_64. * math/math.h: Do not include bits/huge_val.h, bits/huge_valf.h, bits/huge_vall.h or bits/huge_val_flt128.h. (HUGE_VAL): Define directly here. [__USE_ISOC99] (HUGE_VALF): Likewise. [__USE_ISOC99] (HUGE_VALL): Likewise. [__HAVE_FLOAT128 && __GLIBC_USE (IEC_60559_TYPES_EXT)] (HUGE_VAL_F128): Likewise. * math/Makefile (headers): Remove bits/huge_val.h, bits/huge_valf.h, bits/huge_vall.h and bits/huge_val_flt128.h. * bits/huge_val.h: Remove. * bits/huge_val_flt128.h: Likewise. * bits/huge_valf.h: Likewise. * bits/huge_vall.h: Likewise. * sysdeps/ia64/bits/huge_vall.h: Likewise. * sysdeps/ieee754/bits/huge_val.h: Likewise. * sysdeps/ieee754/bits/huge_valf.h: Likewise. * sysdeps/m68k/m680x0/bits/huge_vall.h: Likewise. * sysdeps/sh/bits/huge_val.h: Likewise. * sysdeps/sparc/bits/huge_vall.h: Likewise. * sysdeps/x86/bits/huge_vall.h: Likewise.
* Fix bits/math-finite.h _MSUF_ expansion namespace (bug 22028).Joseph Myers2017-08-291-18/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The current bits/math-finite.h approach to defining functions for different types, involving math.h defining _MSUF_ and _MSUFTO_ for the function suffixes involved, is not namespace-clean if one of those suffixes (f, l, f128) is defined as a macro by the user before math.h is included; too many levels of macro expansion occur. Instead, those suffixes should appear directly in the expansion of the macro using ## so they don't get expanded even if defined as macros by the user (that is, math.h should be defining __REDIRFROM_X and __REDIRTO_X directly to use those suffixes rather than suffixes being passed as an argument by macro callers). This patch makes that change. Tested for x86_64. [BZ #22028] * math/math.h [__FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0] (_MSUF_): Remove macro. [__FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0] (_MSUFTO_): Likewise. [__FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0] (__REDIRFROM_X): New macro. [__FINITE_MATH_ONLY__ && __FINITE_MATH_ONLY__ > 0] (__REDIRTO_X): Likewise. * math/bits/math-finite.h (__REDIRFROM_X): Remove macro. (__REDIRTO_X): Likewise. (__MATH_REDIRCALL): Do not pass _MSUF_ or _MSUFTO_ macro arguments. (__MATH_REDIRCALL_2): Likewise. (__MATH_REDIRCALL_INTERNAL): Likewise. (__REDIRFROM (lgamma, , _MSUF_)): Likewise. (__REDIRFROM (gamma, , _MSUF_)): Likweise. (__REDIRFROM (__gamma, _r_finite, _MSUF_)): Likewise. (__REDIRFROM (tgamma, , _MSUF_)): Likewise. * math/test-finite-macros.c: New file. * math/Makefile (tests): Add test-finite-macros. (CFLAGS-test-finite-macros.c): New variable.
* Provide a C++ version of iszero that does not use __MATH_TG (bug 21930)Gabriel F. T. Gomes2017-08-281-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | When signaling nans are enabled (with -fsignaling-nans), the C++ version of iszero uses the fpclassify macro, which is defined with __MATH_TG. However, when support for float128 is available, __MATH_TG uses the builtin __builtin_types_compatible_p, which is only available in C mode. This patch refactors the C++ version of iszero so that it uses function overloading to select between the floating-point types, instead of relying on fpclassify and __MATH_TG. Tested for powerpc64le, s390x, x86_64, and with build-many-glibcs.py. [BZ #21930] * math/math.h [defined __cplusplus && defined __SUPPORT_SNAN__] (iszero): New C++ implementation that does not use fpclassify/__MATH_TG/__builtin_types_compatible_p, when signaling nans are enabled, since __builtin_types_compatible_p is a C-only feature. * math/test-math-iszero.cc: When __HAVE_DISTINCT_FLOAT128 is defined, include ieee754_float128.h for access to the union and member ieee854_float128.ieee. [__HAVE_DISTINCT_FLOAT128] (do_test): Call check_float128. [__HAVE_DISTINCT_FLOAT128] (check_float128): New function. * sysdeps/powerpc/powerpc64le/Makefile [subdir == math] (CXXFLAGS-test-math-iszero.cc): Add -mfloat128 to the build options of test-math-zero on powerpc64le.
* Clean up bits/math-finite.h for aliasing types.Joseph Myers2017-08-251-8/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch cleans up how bits/math-finite.h handles types that are ABI-aliases of other types. For such types, no __*_finite functions exist; instead, bits/math-finite.h must redirect calls to a the functions for a canonical choice of type for each floating-point format. (For the actual public interfaces, symbols need exporting for each type, even those that are ABI-aliases, because of standard requirements that programs can declare the functions themselves without including <math.h>, but that does not apply to __*_finite.) At present, there is a special-case conditional in bits/math-finite.h on __MATH_DECLARING_LDOUBLE && defined __NO_LONG_DOUBLE_MATH to handle redirecting long double function calls to double __*_finite. This patch replaces this by a more general mechanism. math.h, before each inclusion of bits/math-finite.h, defines _MSUFTO_ as the suffix to use on the target of redirection, in addition to the existing _MSUF_. This way, __MATH_DECLARING_LDOUBLE can go away, as can the special conditional in bits/math-finite.h. With this patch, math.h is now prepared for the case of supporting float128 functions as aliases of long double ones on platforms where long double is binary128, with _MSUFTO_ appropriately defined for that case, and appropriate _MSUFTO_ definitions can easily be included when supporting _Float32 / _Float64 / _Float32x / _Float64x (which will always be ABI-aliases of another type when supported). Tested for x86_64, and did a compilation test for ARM with build-many-glibcs.py to cover the long double = double case. * math/math.h (_MSUFTO_): Define and undefine for each inclusion of <bits/math-finite.h>. (__MATH_DECLARING_LDOUBLE): Do not define and undefine for each inclusion of <bits/math-finite.h>. * math/bits/math-finite.h (__REDIRTO_X): Do not define conditionally on [__MATH_DECLARING_LDOUBLE && defined __NO_LONG_DOUBLE_MATH]. (__MATH_REDIRCALL): Use _MSUFTO_ in __REDIRTO call. (__MATH_REDIRCALL_2): Likewise. (__MATH_REDIRCALL_INTERNAL): Likewise. (__REDIRFROM (lgamma, , _MSUF_)): Likewise. (__REDIRFROM (gamma, , _MSUF_)): Likewise. (__REDIRFROM (tgamma, , _MSUF_)): Likewise.
* Fix the C++ version of issignaling when __NO_LONG_DOUBLE_MATH is definedGabriel F. T. Gomes2017-08-241-1/+9
| | | | | | | | | | | | When __NO_LONG_DOUBLE_MATH is defined, __issignalingl is not available, thus issignaling with long double argument should call __issignaling, instead. Tested for powerpc64le. * math/math.h [defined __cplusplus] (issignaling): In the long double case, call __issignalingl only if __NO_LONG_DOUBLE_MATH is not defined. Call __issignaling, otherwise.
* Provide a C++ version of issignaling that does not use __MATH_TGGabriel F. T. Gomes2017-08-221-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | The macro __MATH_TG contains the logic to select between long double and _Float128, when these types are ABI-distinct. This logic relies on __builtin_types_compatible_p, which is not available in C++ mode. On the other hand, C++ function overloading provides the means to distinguish between the floating-point types. The overloading resolution will match the correct parameter regardless of type qualifiers, i.e.: const and volatile. Tested for powerpc64le, s390x, and x86_64. * math/math.h [defined __cplusplus] (issignaling): Provide a C++ definition for issignaling that does not rely on __MATH_TG, since __MATH_TG uses __builtin_types_compatible_p, which is only available in C mode. (CFLAGS-test-math-issignaling.cc): New variable. * math/Makefile [CXX] (tests): Add test-math-issignaling. * math/test-math-issignaling.cc: New test for C++ implementation of type-generic issignaling. * sysdeps/powerpc/powerpc64le/Makefile [subdir == math] (CXXFLAGS-test-math-issignaling.cc): Add -mfloat128 to the build options of test-math-issignaling on powerpc64le.
generated by cgit-pink 1.4.1 (git 2.36.1) at 2024-06-06 11:47:24 +0000