mirror of
https://sourceware.org/git/glibc.git
synced 2024-11-26 23:10:06 +00:00
f124cb3811
In <https://sourceware.org/ml/libc-alpha/2013-05/msg00722.html> I remarked on the possibility of arithmetic in various nearbyint implementations being scheduled before feholdexcept calls, resulting in spurious "inexact" exceptions. I'm now actually observing this occurring in glibc built for ARM with GCC 7 (in fact, both copies of the same addition/subtraction sequence being combined and moved out before the conditionals and feholdexcept/fesetenv pairs), resulting in test failures. This patch makes the nearbyint implementations with this particular feholdexcept / arithmetic / fesetenv pattern consistently use math_opt_barrier on the function argument when first used in arithmetic, and also consistently use math_force_eval before fesetenv (the latter was generally already done, but the dbl-64/wordsize-64 implementation used math_opt_barrier instead, and as math_opt_barrier's intended effect is through its output value being used, such a use that doesn't use the return value is suspect). Tested for x86_64 (--disable-multi-arch so more of these implementations get used), and for ARM in a configuration where I saw the problem scheduling. [BZ #22225] * sysdeps/ieee754/dbl-64/s_nearbyint.c (__nearbyint): Use math_opt_barrier on argument when doing arithmetic on it. * sysdeps/ieee754/dbl-64/wordsize-64/s_nearbyint.c (__nearbyint): Likewise. Use math_force_eval not math_opt_barrier after arithmetic. * sysdeps/ieee754/flt-32/s_nearbyintf.c (__nearbyintf): Use math_opt_barrier on argument when doing arithmetic on it. * sysdeps/ieee754/ldbl-128/s_nearbyintl.c (__nearbyintl): Likewise. |
||
---|---|---|
.. | ||
aarch64 | ||
alpha | ||
arm | ||
generic | ||
gnu | ||
hppa | ||
i386 | ||
ia64 | ||
ieee754 | ||
init_array | ||
m68k | ||
mach | ||
microblaze | ||
mips | ||
nios2 | ||
nptl | ||
posix | ||
powerpc | ||
pthread | ||
s390 | ||
sh | ||
sparc | ||
tile | ||
unix | ||
wordsize-32 | ||
wordsize-64 | ||
x86 | ||
x86_64 |