From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1IZq7n-0006Y9-1j for qemu-devel@nongnu.org; Mon, 24 Sep 2007 11:45:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1IZq7l-0006Tp-6l for qemu-devel@nongnu.org; Mon, 24 Sep 2007 11:45:30 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1IZq7k-0006TR-Rt for qemu-devel@nongnu.org; Mon, 24 Sep 2007 11:45:28 -0400 Received: from nan.false.org ([208.75.86.248]) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1IZq7k-0006mH-En for qemu-devel@nongnu.org; Mon, 24 Sep 2007 11:45:28 -0400 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id CC19C982AD for ; Mon, 24 Sep 2007 15:45:27 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id 9231E98153 for ; Mon, 24 Sep 2007 15:45:27 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1IZq7i-0004xo-Dd for qemu-devel@nongnu.org; Mon, 24 Sep 2007 11:45:26 -0400 Date: Mon, 24 Sep 2007 11:45:26 -0400 From: Daniel Jacobowitz Subject: Re: [Qemu-devel] Another MIPS quiet NaN fix Message-ID: <20070924154526.GA19061@caradoc.them.org> References: <20070924133729.GA13307@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 On Mon, Sep 24, 2007 at 04:05:45PM +0200, Andreas Schwab wrote: > Daniel Jacobowitz writes: > > > Glibc's test-float failed on my qemu testing. I tracked it down to > > these routines: if you count the bits carefully, you'll see that > > 0x7FC00000 sets the quiet NaN bit (on most hardware - signalling NaN > > in the MIPS case); so does a.high >> 41, which copies it from the > > original NaN. I think this routine should not force a quiet or > > signalling NaN, but just preserve the input NaN's signalling-ness. > > You may need to make sure that at least one mantissa bit is set. I think - but am not quite sure - that this will already be the case because the NaN will have come from some other NaN representation. Good point, though - we can easily set the next bit, as long as we don't fiddle with the signalling bit. -- Daniel Jacobowitz CodeSourcery