A recent discussion in bug 14469 notes that a threshold in float
Bessel function implementations, used to determine when to use a
simpler implementation approach, results in substantially inaccurate
results.
As I discussed in
<https://sourceware.org/ml/libc-alpha/2013-03/msg00345.html>, a
heuristic argument suggests 2^(S+P) as the right order of magnitude
for a suitable threshold, where S is the number of significand bits in
the floating-point type and P is the number of significant bits in the
representation of the floating-point type, and the float and ldbl-96
implementations use thresholds that are too small. Some threshold
does need using, there or elsewhere in the implementation, to avoid
spurious underflow and overflow for large arguments.
This patch sets the thresholds in the affected implementations to more
heuristically justifiable values. Results will still be inaccurate
close to zeroes of the functions (thus this patch does *not* fix any
of the bugs for Bessel function inaccuracy); fixing that would require
a different implementation approach, likely along the lines described
in <http://www.cl.cam.ac.uk/~jrh13/papers/bessel.ps.gz>.
So the justification for a change such as this would be statistical
rather than based on particular tests that had excessive errors and no
longer do so (no doubt such tests could be found, but would probably
be too fragile to add to the testsuite, as liable to give large errors
again from very small implementation changes or even from compiler
changes). See
<https://sourceware.org/ml/libc-alpha/2020-02/msg00638.html> for such
statistics of the resulting improvements for float functions.
Tested (glibc testsuite) for x86_64.
Bug 25487 reports stack corruption in ldbl-96 sinl on a pseudo-zero
argument (an representation where all the significand bits, including
the explicit high bit, are zero, but the exponent is not zero, which
is not a valid representation for the long double type).
Although this is not a valid long double representation, existing
practice in this area (see bug 4586, originally marked invalid but
subsequently fixed) is that we still seek to avoid invalid memory
accesses as a result, in case of programs that treat arbitrary binary
data as long double representations, although the invalid
representations of the ldbl-96 format do not need to be consistently
handled the same as any particular valid representation.
This patch makes the range reduction detect pseudo-zero and unnormal
representations that would otherwise go to __kernel_rem_pio2, and
returns a NaN for them instead of continuing with the range reduction
process. (Pseudo-zero and unnormal representations whose unbiased
exponent is less than -1 have already been safely returned from the
function before this point without going through the rest of range
reduction.) Pseudo-zero representations would previously result in
the value passed to __kernel_rem_pio2 being all-zero, which is
definitely unsafe; unnormal representations would previously result in
a value passed whose high bit is zero, which might well be unsafe
since that is not a form of input expected by __kernel_rem_pio2.
Tested for x86_64.
This should be unconditionally set to match the common implementation,
and fixes multiple test failures related to sprintf.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
The build has been failing on powerpc64le-linux-gnu with GCC 10
due to a maybe-uninitialized error:
../sysdeps/ieee754/dbl-64/mpa.c:875:6: error: ‘w.e’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
875 | EY -= EX;
| ^~
The warning is thrown because when __inv is called by __dvd *y is not
initialized and if t == 0 before calling __dbl_mp, EY will stay
uninitialized, as the function does not touch it in this case.
However, since t will be set to 1/t before calling __dbl_mp, t == 0 will
never happen, so we can instruct the compiler to ignore this case, which
suppresses the warning.
Tested on powerpc64le.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
This patch adds a new macro, libm_alias_finite, to define all _finite
symbol. It sets all _finite symbol as compat symbol based on its first
version (obtained from the definition at built generated first-versions.h).
The <fn>f128_finite symbols were introduced in GLIBC 2.26 and so need
special treatment in code that is shared between long double and float128.
It is done by adding a list, similar to internal symbol redifinition,
on sysdeps/ieee754/float128/float128_private.h.
Alpha also needs some tricky changes to ensure we still emit 2 compat
symbols for sqrt(f).
Passes buildmanyglibc.
Co-authored-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Reviewed-by: Siddhesh Poyarekar <siddhesh@sourceware.org>
Some compiler versions, e.g. GCC 7, complain when -mlong-double-128 is
used together with -mabi=ibmlongdouble or -mabi=ieeelongdouble,
producing the following error message:
cc1: error: ‘-mabi=ibmlongdouble’ requires ‘-mlong-double-128’
This patch removes -mlong-double-128 from the compilation lines that
explicitly request -mabi=*longdouble.
Tested for powerpc64le.
Reviewed-by: Tulio Magno Quites Machado Filho <tuliom@linux.ibm.com>
Some of the files that provide stdio.h and wchar.h functions have a
filename prefixed with 'io', such as 'iovsprintf.c'. On platforms that
imply ldbl-128ibm-compat, these files must be compiled with the flag
-mabi=ibmlongdouble. This patch adds this flag to their compilation.
Notice that this is not required for the other files that provide
similar functions, because filenames that are not prefixed with 'io'
have ldbl-128ibm-compat counterparts in the Makefile, which already adds
-mabi=ibmlongdouble to them.
Reviewed-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
On platforms where long double has IEEE binary128 format as a third
option (initially, only powerpc64le), many exported functions are
redirected to their __*ieee128 equivalents. This redirection is
provided by installed headers such as stdio-ldbl.h, and is supposed to
work correctly with user code.
However, during the build of glibc, similar redirections are employed,
in internal headers, such as include/stdio.h, in order to avoid extra
PLT entries. These redirections conflict with the redirections to
__*ieee128, and must be avoided during the build. This patch protects
the second redirections with a test for __LONG_DOUBLE_USES_FLOAT128, a
new macro that is defined to 1 when functions that deal with long double
typed values reuses the _Float128 implementation (this is currently only
true for powerpc64le).
Tested for powerpc64le, x86_64, and with build-many-glibcs.py.
Co-authored-by: Gabriel F. T. Gomes <gabrielftg@linux.ibm.com>
Reviewed-by: Florian Weimer <fweimer@redhat.com>
On powerpc64le, the libm_alias_float128_other_r_ldbl macro is
used to create an alias between totalorderf128 and __totalorderlieee128,
as well as between the totalordermagf128 and __totalordermaglieee128.
However, the totalorder* and totalordermag* functions changed their
parameter type since commit ID 42760d7646 and got compat symbols for
their old versions. With this change, the aforementioned macro would
create two conflicting aliases for __totalorderlieee128 and
__totalordermaglieee128.
This patch avoids the creation of the alias between the IEEE long double
symbols (__totalorderl*ieee128) and the compat symbols, because the IEEE
long double functions have never been exported thus don't need such
compat symbol.
Tested for powerpc64le.
Reviewed-by: Joseph Myers <joseph@codesourcery.com>
This patch adds IEEE long double versions of q*cvt* functions for
powerpc64le. Unlike all other long double to/from string conversion
functions, these do not rely on internal functions that can take
floating-point numbers with different formats and act on them
accordingly, instead, the related files are rebuilt with the
-mabi=ieeelongdouble compiler flag set.
Having -mabi=ieeelongdouble passed to the compiler causes the object
files to be marked with a .gnu_attribute that is incompatible with the
.gnu_attribute in files built with -mabi=ibmlongdouble (the default).
The difference causes error messages similar to the following:
ld: libc_pic.a(s_isinfl.os) uses IBM long double,
libc_pic.a(ieee128-qefgcvt_r.os) uses IEEE long double.
collect2: error: ld returned 1 exit status
make[2]: *** [../Makerules:649: libc_pic.os] Error 1
Although this warning is useful in other situations, the library
actually needs to have functions with different long double formats, so
.gnu_attribute generation is explicitly disabled for these files with
the use of -mno-gnu-attribute.
Tested for powerpc64le on the branch that actually enables the
sysdeps/ieee754/ldbl-128ibm-compat for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
In the format string for *scanf functions, the '%as', '%aS', and '%a[]'
modifiers behave differently depending on ISO C99 compatibility. When
_GNU_SOURCE is defined and -std=c89 is passed to the compiler, these
functions behave like ascanf, and the modifiers allocate memory for the
output. Otherwise, the ISO C99 compliant version of these functions is
used, and the modifiers consume a floating-point argument. This patch
adds the IEEE binary128 variant of ISO C99 compliant functions for the
third long double format on powerpc64le.
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Since commit
commit 03992356e6
Author: Zack Weinberg <zackw@panix.com>
Date: Sat Feb 10 11:58:35 2018 -0500
Use C99-compliant scanf under _GNU_SOURCE with modern compilers.
the selection of the GNU versions of scanf functions requires both
_GNU_SOURCE and -std=c89. This patch changes the tests in
ldbl-128ibm-compat so that they actually test the GNU versions (without
this change, the redirection to the ISO C99 version always happens, so
GNU versions of the new implementation (e.g. __scanfieee128) were left
untested).
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
This patch just adjusts the generic implementation regarding code style.
No functional change.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch just adjusts the generic implementation regarding code style.
No functional change.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch just adjusts the generic implementation regarding code style.
No functional change.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch just adjusts the generic implementation regarding code style.
No functional change.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch just adjusts the generic implementation regarding code style.
No functional change.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is always using the corresponding GCC builtin for copysignf, copysign,
and is using the builtin for copysignl, copysignf128 if the USE_FUNCTION_BUILTIN
macros are defined to one in math-use-builtins.h.
Altough the long double version is enabled by default we still need
the macro and the alternative implementation as the _Float128 version
of the builtin is not available with all supported GCC versions.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for roundf, round,
roundl and roundf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for truncf, trunc,
truncl and truncf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for ceilf, ceil,
ceill and ceilf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for floorf, floor,
floorl and floorf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for rintf, rint,
rintl and rintf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch is using the corresponding GCC builtin for nearbyintf, nearbyint,
nearbintl and nearbyintf128 if the USE_FUNCTION_BUILTIN macros are defined to one
in math-use-builtins.h.
This is the case for s390 if build with at least --march=z196 --mzarch.
Otherwise the generic implementation is used. The code of the generic
implementation is not changed.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_round.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_trunc.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
The code is not changed except changes in code style.
Also adjusted the include path in x86_64 and sparc64 files.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_ceil.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
The code is not changed except changes in code style.
Also adjusted the include path in x86_64 and sparc64 files.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_floor.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
The code is not changed except changes in code style.
Also adjusted the include path in x86_64 and sparc64 files.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_rint.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
The code is not changed except changes in code style.
Also adjusted the include path in x86_64 file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
This patch replaces s_nearbyint.c in sysdeps/dbl-64 with the one in
sysdeps/dbl-64/wordsize-64 and removes the latter one.
The code is not changed except changes in code style.
Also adjusted the include path in x86_64 file.
Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Since the commit
commit 86a0f56158
Author: Rajalakshmi Srinivasaraghavan <raji@linux.vnet.ibm.com>
Date: Thu Jun 28 13:57:50 2018 +0530
ldbl-128ibm-compat: Introduce ieee128 symbols
IEEE long double versions of strfroml, strtold, and wcstold have been
prepared, but not exposed (which will only happen when the full support
for IEEE long double is complete). This patch adds tests for these
functions in both IBM and IEEE long double mode.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
This patch adds elementary tests to check that strfmon and strfmon_l
correctly evaluate long double values with IBM Extended Precision and
IEEE binary128 format.
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Similarly to what has been done for printf-like functions, more
specifically to the internal implementation in __vfprintf_internal, this
patch extends __vstrfmon_l_internal to deal with long double values with
binary128 format (as a third format option and reusing the float128
implementation).
Tested for powerpc64le, powerpc64, x86_64, and with build-many-glibcs.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Several commits to the ldbl-128ibm-compat directory added new files
where the URL in the copyright notice pointed to an http, rather than to
an https, address. This happened because I copied the notices before
commit ID 5a82c74822. This trivial patch fixes this issue.
Similarly to __vfprintf_internal and __vfscanf_internal, the internal
implementation of syslog functions (__vsyslog_internal) takes a
'mode_flags' parameter used to select the format of long double
parameters. This patch adds variants of the syslog functions that set
'mode_flags' to PRINTF_LDBL_USES_FLOAT128, thus enabling the correct
printing of long double values on powerpc64le, when long double has IEEE
binary128 format (-mabi=ieeelongdouble).
Tested for powerpc64le.
Reviewed-by: Florian Weimer <fweimer@redhat.com>
Reviewed-by: Joseph Myers <joseph@codesourcery.com>
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Similarly to the functions from the *printf family, this patch adds
implementations for __obstack_*printf* functions that set the
'mode_flags' parameter to PRINTF_LDBL_USES_FLOAT128, before making calls
to __vfprintf_internal (indirectly through __obstack_vprintf_internal).
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Commit IDs 9771e6cb51 and 7597b0c7f7 added tests for the functions
from err.h and error.h that can take long double parameters.
Afterwards, commit ID f0eaf86276 reused them on architectures that
changed the long double format from the same as double to something else
(i.e.: architectures that imply ldbl-opt). This patch reuses it again
for IEEE long double on powerpc64le.
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Use the recently added, internal functions, __error_at_line_internal and
__error_internal, to provide error.h functions that can take long double
arguments with IEEE binary128 format on platforms where long double can
also take double format or some non-IEEE format (currently, this means
powerpc64le).
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Use the recently added, internal functions, __vwarnx_internal and
__vwarn_internal, to provide err.h functions that can take long double
arguments with IEEE binary128 format on platforms where long double can
also take double format or some non-IEEE format (currently, this means
powerpc64le).
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Use the recently added, internal functions, __argp_error_internal and
__argp_failure_internal, to provide argp_error and argp_failure that can
take long double arguments with IEEE binary128 format on platforms where
long double can also take double format or some non-IEEE format
(currently, this means powerpc64le).
Tested for powerpc64le.
Reviewed-by: Paul E. Murphy <murphyp@linux.ibm.com>
Similarly to what was done for regular character scanning functions,
this patch uses the new mode mask, SCANF_LDBL_USES_FLOAT128, in the
'mode' argument of the wide characters scanning function,
__vfwscanf_internal (which is also extended to support scanning
floating-point values with IEEE binary128, by redirecting calls to
__wcstold_internal to __wcstof128_internal).
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
The 'mode' argument to __vfscanf_internal allows the selection of the
long double format for all long double arguments requested by the format
string. Currently, there are two possibilities: long double with the
same format as double or long double as something else. The 'something
else' format varies between architectures, and on powerpc64le, it means
IBM Extended Precision format.
In preparation for the third option of long double format on
powerpc64le, this patch uses the new mode mask,
SCANF_LDBL_USES_FLOAT128, which tells __vfscanf_internal to call
__strtof128_internal, instead of __strtold_internal, and save the output
into a _Float128 variable.
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
The format string can request positional parameters, instead of relying
on the order in which they appear as arguments. Since this has an
effect on how the type of each argument is determined, this patch
extends the test cases to use positional parameters with mixed double
and long double types, to verify that the IEEE long double
implementations of *printf work correctly in this scenario.
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
A single format string can take double and long double parameters at the
same time. Internally, these parameters are routed to the same
function, which correctly reads them and calls the underlying functions
responsible for the actual conversion to string. This patch adds a new
case to test this scenario.
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
Similarly to what was done for the regular character, fortified printing
functions, this patch combines the mode masks PRINTF_LDBL_USES_FLOAT128
and PRINTF_FORTIFY to provide wide character versions of fortified
printf functions. It also adds two flavors of test cases: one that
explicitly calls the fortified functions, and another that reuses the
non-fortified test, but defining _FORTIFY_SOURCE as 2. The first
guarantees that the implementations are actually being tested
(independently of what's in bits/wchar2.h), whereas the second
guarantees that the redirections calls the correct function in the IBM
and IEEE long double cases.
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
Since the introduction of internal functions with explicit flags for the
printf family of functions, the 'mode' parameter can be used to select
which format long double parameters have (with the mode flags:
PRINTF_LDBL_IS_DBL and PRINTF_LDBL_USES_FLOAT128), as well as to select
whether to check for overflows (mode flag: PRINTF_FORTIFY).
This patch combines PRINTF_LDBL_USES_FLOAT128 and PRINTF_FORTIFY to
provide the IEEE binary128 version of printf-like function for platforms
where long double can take this format, in addition to the double format
and to some non-ieee format (currently, this means powerpc64le).
There are two flavors of test cases provided with this patch: one that
explicitly calls the fortified functions, for instance __asprintf_chk,
and another that reuses the non-fortified test, but defining
_FORTIFY_SOURCE as 2. The first guarantees that the implementations are
actually being tested (in bits/stdio2.h, vprintf gets redirected to
__vfprintf_chk, which would leave __vprintf_chk untested), whereas the
second guarantees that the redirections calls the correct function in
the IBM and IEEE long double cases.
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
Similarly to what was done for regular character printing functions,
this patch uses the new mode mask, PRINTF_LDBL_USES_FLOAT128, in the
'mode' argument of the wide characters printing function,
__vfwprintf_internal (which is also extended to support printing
floating-point values with IEEE binary128, by saving floating-point
values into variables of type __float128 and adjusting the parameters to
__printf_fp and __printf_fphex as if it was a call from a wide-character
version of strfromf128 (even though such version does not exist)).
Tested for powerpc64le.
Reviewed-By: Paul E. Murphy <murphyp@linux.ibm.com>
