Fix StrictMath.copySign's behavior with NaN.
StrictMath's copySign method is defined to treat all NaNs as positive, regardless
of their sign bit. Rather than add yet more code on the Java side (which already
called down to native code three times), let's just make one call to native code.
This change fixes failures in already-committed StrictMath tests.
The only other potential instances of this class of error were in the
max and min methods, but they all handle NaNs before calling
(double|float)To(Raw)?LongBits, so the choice there really is arbitrary.
Change-Id: I439dbdff9068cb420b78a6330cde9d7d0d12c0ef
4 files changed