diff options
author | Joseph Myers <joseph@codesourcery.com> | 2021-09-28 23:31:35 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2021-09-28 23:31:35 +0000 |
commit | 90f0ac10a74b2d43b5a65aab4be40565e359be43 (patch) | |
tree | ab0e73d7c60a7255fa5e7c9cbe58e80c3eb8d9cd /nis/nis_domain_of_r.c | |
parent | 5bf07e1b3a74232bfb8332275110be1a5da50f83 (diff) | |
download | glibc-90f0ac10a74b2d43b5a65aab4be40565e359be43.tar.gz glibc-90f0ac10a74b2d43b5a65aab4be40565e359be43.tar.xz glibc-90f0ac10a74b2d43b5a65aab4be40565e359be43.zip |
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.
Diffstat (limited to 'nis/nis_domain_of_r.c')
0 files changed, 0 insertions, 0 deletions