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 <[EMAIL PROTECTED]> Never organized
