Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat

["J. Mayer" <l_indien@magic.fr>]

On Sat, 2007-11-03 at 22:28 +0100, Aurelien Jarno wrote: 
> On Sat, Nov 03, 2007 at 02:06:04PM -0400, Daniel Jacobowitz wrote:
> > On Sat, Nov 03, 2007 at 06:35:48PM +0100, Aurelien Jarno wrote:
> > > Hi all,
> > > 
> > > The current softfloat implementation changes qNaN into sNaN when 
> > > converting between formats, for no reason. The attached patch fixes
> > > that. It also fixes an off-by-one in the extended double precision
> > > format (aka floatx80), the mantissa is 64-bit long and not 63-bit
> > > long.
> > > 
> > > With this patch applied all the glibc 2.7 floating point tests
> > > are successfull on MIPS and MIPSEL.
> > 
> > FYI, I posted a similar patch and haven't had time to get back to it.
> > Andreas reminded me that we need to make sure at least one mantissa
> > bit is set.  If we're confident that the common NaN format will
> > already have some bit other than the qnan/snan bit set, this is fine;
> > otherwise, we might want to forcibly set some other mantissa bit.
> > 
> 
> Please find an updated patch below. I have tried to match real x86, MIPS,
> HPPA, PowerPC and SPARC hardware when all mantissa bits are cleared.

It's a good idea to fix NaN problems here but in my opinion, it's a bad
idea to have target dependant code here. This code should implement IEEE
behavior. Target specific behavior / deviations from the norm has to be
implemented in target specific code. As targets have to check the
presence of a NaN to update the FP flags, it seems that uglyifying this
code with target specific hacks is pointless. If the target code do not
check the presence of a NaN, that means that it does not implement
precise FPU emulation, then there's no need to have specific code to
return a precise value (I mean target dependant) from the generic code,
imho.

[...]

-- 
J. Mayer <l_indien@magic.fr>
Never organized