From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IpUc5-0008A3-TM for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:01:29 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IpUc2-00088N-5R for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:01:28 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IpUc2-000884-0R for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:01:26 -0500 Received: from bangui.magic.fr ([195.154.194.245]) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1IpUc1-000477-BA for qemu-devel@nongnu.org; Tue, 06 Nov 2007 15:01:25 -0500 Subject: Re: [Qemu-devel] [PATCH] Fix NaN handling in softfloat From: "J. Mayer" In-Reply-To: <20071103212816.GA31686@hall.aurel32.net> References: <20071103173548.GA16847@hall.aurel32.net> <20071103180604.GA14403@caradoc.them.org> <20071103212816.GA31686@hall.aurel32.net> Content-Type: text/plain Date: Tue, 06 Nov 2007 21:01:13 +0100 Message-Id: <1194379274.31210.100.camel@rapid> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Aurelien Jarno 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 Never organized