On 11/28/24 08:54, Peter Maydell wrote:
Currently we hardcode the default NaN value in parts64_default_nan() using a compile-time ifdef ladder. This is awkward for two cases: * for single-QEMU-binary we can't hard-code target-specifics like this * for Arm FEAT_AFP the default NaN value depends on FPCR.AH (specifically the sign bit is different)Add a field to float_status to specify the default NaN value; fall back to the old ifdef behaviour if these are not set. The default NaN value is specified by setting a uint8_t to a pattern corresponding to the sign and upper fraction parts of the NaN; the lower bits of the fraction are set from bit 0 of the pattern. This is an RFC to ask for opinions on whether this is the right way to let the target set its default NaN. I can't decide whether I think encoding it into a uint8_t like that is clever, or merely too clever :-)
I think that's perfectly fine.
#elif defined(TARGET_HEXAGON) - sign = 1; - frac = ~0ULL; + /* + * Sign bit set, all frac bits set. This is an odd special case, + * where our value doesn't match up with the snan_bit_is_one setting. + * This is because for Hexagon the returned value is always -1, + * not a real NaN value. + */ + dnan_pattern = 0b11111111;
It's a real (signalling) nan value -- the oddity is that the default nan is not quiet. Reviewed-by: Richard Henderson <richard.hender...@linaro.org> r~
