which is used everywhere except on vax. This is to simplify and
to ensure the function is included in the build, allowing us to
re-add the nearbyint() test.
This isn't a functional difference because huge + x > one is
always true for a small x, and is probably a magical incantation
to raise inexact if x != 0
Found by GCC 8.0
restore ABI compatibility with previous releases for ieeefp.h on sh3.
add namespace.h protection for all the fenv interfaces.
use MKSOFTFLOAT on sh3 instead of assuming softfloat.
standardize on comparing MKSOFTFLOAT with "no".
remove the arm-specific softfloat fenv code (which also had several bugs).
fix logic errors in the arm hardfloat feraiseexcept() and feupdateenv().
all later users of y first assign another value.
using ifdefs to make potential future code syncs easier, as is done
elsewhere.
suggested by coverity, CID 1300929, 1300930.
values into p,q sane. Get rid of redundant assignment. Indent
for legibility. NFC.
This doesn't create a functional difference, as all callers
test number >= 0x40000000 anyway.
To see this, note the following:
- consistently, hx is the high bits of x, lx is the low bits,
x is the float.
- & 0x7fffffff zeroes the sign bit, as does fabs.
A case where it isn't easy to see that there's no functional
change is y1, which does:
ix = hx & 0x7fffffff (zero signbit of high bits of x)
y = fabs(x) (this has a zeroed signbit but otherwise same as x)
ix >= 0x40000000
pone(y); qone(y)
qone(x) (also pone) do:
ix = hx & 0x7fffffff
ix in qone and in the calling function are the same number,
and the comparison applies for both, and ix < 0x40000000 isn't
possible.
(Also, no explosions seem to happen when I feed it random numbers)
-0.0 > 0 is also false. no functional change.
while this is mostly a change to be consistent in style (the rest of the
comparisons aren't done with signbit), it is also a micro-optimization.
with our default compile flags, calls to copysign are libm calls (and a
whole function call!!). this generates more efficient code.
delicacy in order to maintain continuity around it.
we have an initial case to deal with a fairly common case: getting
a real number. Avoid dealing with the branch cut in this case by
checking if the real part is negative.
later, -0.0 < 0 is not met, so instead, test for a negative number
using signbit, so negative zero is also treated as a negative number.
Fixes last part of PR lib/51427: libm issues triggered by py-numpy
ok riastradh
