diff options
author | Joseph Myers <joseph@codesourcery.com> | 2015-05-22 17:36:52 +0000 |
---|---|---|
committer | Joseph Myers <joseph@codesourcery.com> | 2015-05-22 17:36:52 +0000 |
commit | fded7ed684b17e42a5cc5434e799166ca2df1643 (patch) | |
tree | 2b26ec47a3f4ac8b4ea19e23e71dad97bd118ba7 /benchtests/bench-memset.c | |
parent | 992328e5e0852c2f3b7126a5861235b07ad27cac (diff) | |
download | glibc-fded7ed684b17e42a5cc5434e799166ca2df1643.tar glibc-fded7ed684b17e42a5cc5434e799166ca2df1643.tar.gz glibc-fded7ed684b17e42a5cc5434e799166ca2df1643.tar.bz2 glibc-fded7ed684b17e42a5cc5434e799166ca2df1643.zip |
Fix ldbl-128 / ldbl-128ibm asinl for -Wuninitialized.
The ldbl-128 and ldbl-128ibm implementations of asinl produce
uninitialized variable warnings with -Wuninitialized because the code
for small arguments in fact always returns but the compiler cannot see
this and instead sees that a variable would be uninitialized if the
"if (huge + x > one)" conditional used to force the "inexact"
exception were false.
All the code in libm trying to force "inexact" for functions that are
not exactly defined is suspect and should be removed at some point
given that we now have a clear definition of the accuracy goals for
libm functions which, following C99/C11, does not require anything
about "inexact" for most functions (likewise, the multi-precision code
that tries to give correctly-rounded results, very slowly, for
functions for which the goals clearly do not include correct rounding,
if the faster paths are accurate enough). However, for now this patch
simply changes the code to use math_force_eval, rather than "if", to
ensure the evaluation of the inexact computation.
Tested for powerpc and mips64.
* sysdeps/ieee754/ldbl-128/e_asinl.c (__ieee754_asinl): Don't use
a conditional in forcing "inexact".
* sysdeps/ieee754/ldbl-128ibm/e_asinl.c (__ieee754_asinl):
Likewise.
Diffstat (limited to 'benchtests/bench-memset.c')
0 files changed, 0 insertions, 0 deletions