From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2418 invoked by alias); 2 Jan 2008 17:01:03 -0000 Received: (qmail 2382 invoked by uid 22791); 2 Jan 2008 17:01:02 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 02 Jan 2008 16:55:31 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0EAA39811F; Wed, 2 Jan 2008 16:55:21 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id CA39B98118; Wed, 2 Jan 2008 16:55:20 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.68) (envelope-from ) id 1JA6sB-00072S-QO; Wed, 02 Jan 2008 11:55:19 -0500 Date: Wed, 02 Jan 2008 17:01:00 -0000 From: Daniel Jacobowitz To: Luis Machado Cc: Andreas Schwab , gdb-patches@sourceware.org Subject: Re: GDB/libiberty support for IBM long double Message-ID: <20080102165519.GA26437@caradoc.them.org> Mail-Followup-To: Luis Machado , Andreas Schwab , gdb-patches@sourceware.org References: <200711090107.lA917ZGs027733@d12av02.megacenter.de.ibm.com> <1198783208.7822.51.camel@gargoyle> <1198852288.7822.56.camel@gargoyle> <20071230043845.GC24220@caradoc.them.org> <1199290287.13275.3.camel@gargoyle> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1199290287.13275.3.camel@gargoyle> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00026.txt.bz2 On Wed, Jan 02, 2008 at 02:11:27PM -0200, Luis Machado wrote: > Hi, > > > I wonder if we really need to use floatformat_to_double instead of > > floatformat_to_doublest for the split_half cases. It seems like that > > relies unnecessarily on the host double format. Do things work better > > if you use floatformat_to_doublest and DOUBLEST variables, instead > > of floatformat_to_double (likewise floatformat_from_doublest)? > > The attached patch replaces the use of floatformat_to_double with > floatformat_to_doublest, fixing the problem. > > There are other uses of floatformat_to_double in the function, by i'm > not sure if we should just replace every call of that function with the > "doublest" version (likewise with the floatformat_from_double -> > floatformat_from_doublest replacement). There is one other call, for NaN and infinity. That one should be left alone, since we don't duplicate the necessary bits and the precision is irrelevant. However, could you test also replacing the two floatformat_from_double calls in convert_doublest_to_floatformat? -- Daniel Jacobowitz CodeSourcery