TST: Fix test_numeric on riscv64 #25430
Conversation
|
This issue was mentioned previously in #8213 . Here I simply disable the tests entirely on risvc64 rather than modifying them to try to get them to pass as it's best to not to assume that the sign of negative NaNs will be retained on RISC-V. |
|
One thing that I do wonder a bit is whether we cannot actually make sure that assignment of a scalar NaN preserves the sign and if necessary that the NaN scalar has no signbit set (is positive). I am a bit curious how much of this is just because the way we define (This is under the assumption that mainly casts do not preserve NaN sign or payload(?)) |
It's not just the casts. The RISC-V floating point arithmetic instructions (e.g., FADD, FSUB, FMUL, FMADD, FMIN, FMAX) all return the canonical NaN. Now, loads and stores and instructions that copy floating points values between registers without conversion do preserve the signs of NaNs. Even so, in this patch I disable
on riscv64 even though there's no conversion and this test actually passes. I felt it was a bit too fragile to leave it enabled as we'd be relying on nothing happening to that value other than it being stored and loaded. As an example of fragility,
passes on amd64 but fails on riscv64, even though there's no conversion. |
|
Hmmm, if the test isn't failing: I don't really see anything but store/load happening here, so I honestly wouldn't change it. (The interesting part I guess being that there is no cast here in the setup code.)
Yes, OK. This type of thing we should just skip on RISC V. TBH, if it goes beyond multiplying by |
Modify test_numeric so that it passes on riscv64. The subtest TestBoolCmp::test_float currently fails on riscv64 as it assumes that the sign of -np.nan is retained when stored to and read back from an array. This is not always the case on riscv64. Many RISC-V instructions that produce NaNs return a canonical NaN, as defined by the RISC-V specification. The canonical NaNs are always positive. In this particular test the negative sign of the -np.nan is lost when it is converted from a double to a float before being stored in self.signf. We disable the float32 sign tests for -np.nan on riscv64 allowing test_numeric to pass.
6ac0051 to
468678a
Compare
|
@seberg I've re-enabled the double sign test for -np.nan on RISC-V in my PR. As discussed above, this test doesn't actually fail on RISC-V. The PR now just disables the float32 sign tests for -np.nan on RISC-V. I've also rebased the PR against main. |
|
Sorry, forgot about this. Let's get this in if it fixes tests on RISC-V. Thanks @markdryan |
Modify test_numeric so that it passes on riscv64. The subtest TestBoolCmp::test_float currently fails on riscv64 as it assumes that the sign of -np.nan is retained when stored to and read back from an array. This is not always the case on riscv64. Many RISC-V instructions that produce NaNs return a canonical NaN, as defined by the RISC-V specification. The canonical NaNs are always positive. In this particular test the negative sign of the -np.nan is lost when it is converted from a double to a float before being stored in self.signf. It's best not to make any assumptions about the retention of signs for negative NaNs on RISC-V so we disable both sign tests for -np.nan on riscv64.