On 6 January 2011 18:48, Aurelien Jarno <aurel...@aurel32.net> wrote: > On Thu, Jan 06, 2011 at 03:34:38PM +0000, Peter Maydell wrote: >> In helper_fnmadd() and helper_fnmsub(): >> if (likely(!float64_is_quiet_nan(farg1.d))) >> farg1.d = float64_chs(farg1.d); >> >> is I think OK but somebody else might like to check. > > After reading the manual again, it seems float64_is_nan() should be used > here. The idea is that fnmadd returns the negated value of fmadd, and > that NaN should be propagated as fnmadd was a single instruction. In > QEMU chs changes the sign bit even if the value is NaN. Quoting the > manual: > > | This instruction produces the same result as would be obtained by > | using the Floating Multiply-Add instruction and then negating the > | result, with the following exceptions. > | * QNaNs propagate with no effect on their "sign" bit. > | * QNaNs that are generated as the result of a disabled Invalid > | Operation Exception have a "sign" bit of 0. > | * SNaNs that are converted to QNaNs as the result of a disabled > | Invalid Operation Exception retain the "sign”"bit of the SNaN.
Yes, I read that text, but I kind of convinced myself that at that point in the code it wasn't possible to get a signalling NaN (since they've been handled earlier). Still, the _any_nan() check is probably clearer code. -- PMM