On Fri, 7 Feb 2025 at 11:53, Michael Tokarev <m...@tls.msk.ru> wrote:
>
> 07.02.2025 13:27, Paolo Bonzini wrote:
> > From: Peter Maydell <peter.mayd...@linaro.org>
> >
> > In commit 8adcff4ae7 ("fpu: handle raising Invalid for infzero in
> > pick_nan_muladd") we changed the handling of 0 * Inf + QNaN to always
> > raise the Invalid exception regardless of target architecture. (This
> > was a change affecting hppa, i386, sh4 and tricore.) However, this
> > was incorrect for i386, which documents in the SDM section 14.5.2
> > that for the 0 * Inf + NaN case that it will only raise the Invalid
> > exception when the input is an SNaN. (This is permitted by the IEEE
> > 754-2008 specification, which documents that whether we raise Invalid
> > for 0 * Inf + QNaN is implementation defined.)
> >
> > Adjust the softfloat pick_nan_muladd code to allow the target to
> > suppress the raising of Invalid for the inf * zero + NaN case (as an
> > extra flag orthogonal to its choice for when to use the default NaN),
> > and enable that for x86.
> >
> > We do not revert here the behaviour change for hppa, sh4 or tricore:
> > * The sh4 manual is clear that it should signal Invalid
> > * The tricore manual is a bit vague but doesn't say it shouldn't
> > * The hppa manual doesn't talk about fused multiply-add corner
> > cases at all
> >
> > Cc: qemu-sta...@nongnu.org
> > Fixes: 8adcff4ae7 (""fpu: handle raising Invalid for infzero in
> > pick_nan_muladd")
>
> A nitpick: double double-quote.
>
> 8adcff4ae7 is v9.2.0-7-g8adcff4ae7 - which is 7 commits *after* the latest
> released version, -- hopefully this fix should not go to any stable series,
> unless 8adcff4ae7 itself has to be picked up for 9.2 too.
Ah, yes, I think I assumed based on date that 8adcff4ae7 had
made it into a release already. That commit was a refactoring
so it doesn't need to be backported anywhere.
-- PMM
