Hi Aleksandar, On Mon, Jul 24, 2017 at 02:36:05PM +0100, Aleksandar Markovic wrote: > > > diff --git a/arch/mips/math-emu/dp_fmax.c b/arch/mips/math-emu/dp_fmax.c > > > index fd71b8d..567fc33 100644 > > > --- a/arch/mips/math-emu/dp_fmax.c > > > +++ b/arch/mips/math-emu/dp_fmax.c > > > @@ -47,6 +47,9 @@ union ieee754dp ieee754dp_fmax(union ieee754dp x, union ieee754dp y) > > > case CLPAIR(IEEE754_CLASS_SNAN, IEEE754_CLASS_INF): > > > return ieee754dp_nanxcpt(x); > > > > > > + case CLPAIR(IEEE754_CLASS_QNAN, IEEE754_CLASS_QNAN): > > > + return x; > > > > couldn't the above... > > > > > + > > > /* numbers are preferred to NaNs */ > > > case CLPAIR(IEEE754_CLASS_ZERO, IEEE754_CLASS_QNAN): > > > case CLPAIR(IEEE754_CLASS_NORM, IEEE754_CLASS_QNAN): > > > @@ -54,7 +57,6 @@ union ieee754dp ieee754dp_fmax(union ieee754dp x, union ieee754dp y) > > > > ... go somewhere around here and fall through to the existing return x > > case? > > > > It could, but at the expense of code clarity and/or logical grouping of special cases, > which after this patch looks like: > > . . . > | > case of both inputs qNaN > | > case of only x input qNaN > | > case of only y input qNaN > | > . . . > > If you agree, I suggest keeping the code the same as currently proposed in > this patch, except that the following comments should be added in appropriate > places: > > /* > * Quiet NaN handling > */ > /* The case of both inputs quiet NaNs */ > . . . > /* The cases of exactly one input quiet NaN */ > > Unfortunately, the code segment for handling of sNaN and infinity inputs do > not follow the organization that I proposed. However, I think that my proposal > for case organization is the superior one - therefore I intend to keep it in v4, > unless you tell me not to do so. Okay, I don't object. Thanks James
Attachment:
signature.asc
Description: Digital signature
