Probably better links for this, but on MIPS, the floating point signalling bit seems typically inverted:https://sourceware.org/binutils/docs/as/MIPS-NaN-Encodings.html

However, Python's_Py_dg_stdnan should create quiet NaNs, but hard-codes the bit to 0.

This again continues to do weird things if mixed with NumPy apparently visible in somefmin downstream test failures (to be clear, I don't think the signalling bitshould matter for that, but it is incorrect anyway; the bit should never be set in our part of the world). (Seenumpy/numpy#23158)

To me, all of that is a bit moot though. Python has this manual definition for NaN and Inf, but also definesPy_NAN andPy_HUGE_VAL. In theory,Py_HUGE_VAL doesn't need to be inf andPy_NAN I am not actually sure what it could be if NaN is not available...

But... If you have IEEE doubles and setting the bit-pattern manually is reasonable. You certainly can assume that both are defined to the right thing andPy_NAN is in fact aNaN value. Doing that simplifies the code, but should also solve the MIPS issue sincePy_NAN presumably is correctly defined to a quiet NaN.

This is done ingh-104202. I suppose a test might be:

if hasattr(math, "nan"):    bits_nan1 = struct.pack("d", math.inf - math.inf)    bits_nan2 = struct.pack("d", math.nan)    assert bits_nan1 == bits_nan2