From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Iqy9l-00022e-UR for qemu-devel@nongnu.org; Sat, 10 Nov 2007 16:46:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Iqy9k-00021z-66 for qemu-devel@nongnu.org; Sat, 10 Nov 2007 16:46:21 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Iqy9k-00021t-0T for qemu-devel@nongnu.org; Sat, 10 Nov 2007 16:46:20 -0500 Received: from hall.aurel32.net ([88.191.38.19]) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1Iqy9j-0001ke-Nc for qemu-devel@nongnu.org; Sat, 10 Nov 2007 16:46:20 -0500 Message-ID: <473626A4.9020802@aurel32.net> Date: Sat, 10 Nov 2007 22:46:12 +0100 From: Aurelien Jarno MIME-Version: 1.0 Subject: Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat References: <20071103173548.GA16847@hall.aurel32.net> <20071103180604.GA14403@caradoc.them.org> <20071103212816.GA31686@hall.aurel32.net> <20071110211821.GA8363@networkno.de> In-Reply-To: <20071110211821.GA8363@networkno.de> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thiemo Seufer , qemu-devel@nongnu.org Thiemo Seufer a écrit : > 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. > > The default NaN pattern for MIPS and HPPA were broken. (Fabrice spotted > this.) I currently have the appended patch, it assumes HPPA is similiar > to MIPS, which is probably incorrect. HPPA only generates different NaN values, appart from that it behaves the same as MIPS. On the other side, target-hppa is not yet implemented (even if some patches could be found on the web). >> Index: fpu/softfloat-specialize.h >> =================================================================== >> RCS file: /sources/qemu/qemu/fpu/softfloat-specialize.h,v >> retrieving revision 1.3 >> diff -u -d -p -r1.3 softfloat-specialize.h >> --- fpu/softfloat-specialize.h 11 May 2007 17:10:14 -0000 1.3 >> +++ fpu/softfloat-specialize.h 3 Nov 2007 21:17:57 -0000 >> @@ -120,9 +120,17 @@ static commonNaNT float32ToCommonNaN( fl >> >> static float32 commonNaNToFloat32( commonNaNT a ) >> { >> - >> - return ( ( (bits32) a.sign )<<31 ) | 0x7FC00000 | ( a.high>>41 ); >> - >> + bits32 mantissa = a.high>>41; >> + if (mantissa) >> + return ( ( (bits32) a.sign )<<31 ) | 0x7F800000 | ( mantissa ); >> + else >> +#if defined(TARGET_MIPS) >> + return ( ( (bits32) a.sign )<<31 ) | 0x7FBFFFFF | ( mantissa ); >> +#elif defined(TARGET_HPPA) >> + return ( ( (bits32) a.sign )<<31 ) | 0x7FA00000 | ( mantissa ); >> +#else >> + return ( ( (bits32) a.sign )<<31 ) | 0x7FC00000; >> +#endif > > This looks odd. Do MIPS and HPPA really need a specialcase here but none > for doubles? Could you re-check with my patch applied? That's because there is no greater precision than double precision on MIPS and HPPA (for the latter I am not 100% sure), so you can't loose precision on the mantissa when converting to double precision. I have looked quickly at your patch, it looks like the right approach to define target specific things at only one place in the file. I will get a closer tomorrow. -- .''`. Aurelien Jarno | GPG: 1024D/F1BCDB73 : :' : Debian developer | Electrical Engineer `. `' aurel32@debian.org | aurelien@aurel32.net `- people.debian.org/~aurel32 | www.aurel32.net