From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6262 invoked by alias); 3 Dec 2003 18:17:51 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6176 invoked from network); 3 Dec 2003 18:17:50 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sources.redhat.com with SMTP; 3 Dec 2003 18:17:50 -0000 Received: from drow by nevyn.them.org with local (Exim 4.24 #1 (Debian)) id 1ARbZN-00013K-Jv; Wed, 03 Dec 2003 13:17:49 -0500 Date: Wed, 03 Dec 2003 18:17:00 -0000 From: Daniel Jacobowitz To: Ian Lance Taylor Cc: gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com Subject: Re: RFA: Support infinity, NaN, and denormalized numbers in floatformat.c Message-ID: <20031203181749.GA19055@nevyn.them.org> Mail-Followup-To: Ian Lance Taylor , gcc-patches@gcc.gnu.org, gdb-patches@sources.redhat.com References: <20031203181245.3896.qmail@gossamer.airs.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20031203181245.3896.qmail@gossamer.airs.com> User-Agent: Mutt/1.5.1i X-SW-Source: 2003-12/txt/msg00084.txt.bz2 On Wed, Dec 03, 2003 at 01:12:45PM -0500, Ian Lance Taylor wrote: > Here is a patch to improve the support for infinity, NaN, and > denormalized numbers in floatformat.c. It's not clear how to handle > these for non-IEEE formats. But the old code did entirely the wrong > thing even when using IEEE formats, which are used by pretty much all > modern processors. So I think we might as well do the right thing > here. > > These patches cause the following compilation warnings on a Red Hat > Linux 7.3 system: > > ../../gcc/libiberty/floatformat.c: In function `floatformat_to_double': > ../../gcc/libiberty/floatformat.c:319: warning: traditional C rejects the 'u' suffix > ../../gcc/libiberty/floatformat.c:319: warning: traditional C rejects initialization of unions > ../../gcc/libiberty/floatformat.c:321: warning: traditional C rejects the 'f' suffix > > These are all cases in which the code is using macros which are > defined by the standard header (namely INFINITY and NAN). So > these warnings do not indicate actual code problems. I don't see any > obvious way to avoid them. > > After writing these patches, I decided to see what uses the > floatformat routines. I discovered only one use: the m68k > disassembler. gdb uses different routines which probably started as a > copy of the floatformat routines, but use the type DOUBLEST which can > be `long double' instead of `double'. The code has diverged, and > there is some support there for denormalized numbers. It doesn't look > right to me, but I haven't investigated much further. For the record, that's not 100% correct - GDB doesn't use floatformat_to_double or floatformat_from_double, but we do use the rest of the file (is_valid, and all the actual floatformats). This is fairly obvious after re-reading what you said but it gave me a turn the first time :) > It seems to me that the gdb code should move into libiberty. We can > easily add floatformat_to_long_double and > floatformat_from_long_double, which would only be available if the > long double type is available. gdb would then call the appropriate > function from libiberty. There is other gdb floatformat code which > could move over as well, such as floatformat_is_negative() and > floatformat_is_nan(). > > Any other opinions on the best way to merge the libiberty and gdb > implementations? That sounds reasonable to me. floatformat_to_doublest could contain a check on HAVE_LONG_DOUBLE and call one or the other. -- Daniel Jacobowitz MontaVista Software Debian GNU/Linux Developer