From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: ac131313@cygnus.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa(arm)/rfc] Eliminate HOST_{FLOAT,DOUBLE,...}_FORMAT
Date: Fri, 29 Jun 2001 09:01:00 -0000
Message-id: <4839-Fri29Jun2001185737+0300-eliz@is.elta.co.il>
References: <3B3C1A5C.3060906@cygnus.com> <5137-Fri29Jun2001120040+0300-eliz@is.elta.co.il> <3B3C9C03.7000704@cygnus.com>
X-SW-Source: 2001-06/msg00525.html

> Date: Fri, 29 Jun 2001 11:17:23 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> > 
> > You could lose information if the original value's bit pattern is not
> > a valid FP number.  Does floatformat_to_doublest handle these
> > situations 110% correctly?  I see at least one FIXME comment in the
> > code there.
> 
> 
> At present this loss happens randomly depending on the host / target 
> combination.  I would prefer GDB to at least have slightly more 
> consistent behavour.

I agree with the goal, but I don't think we could explain to users of
native debuggers that they have NaN's being converted to Inf's in the
name of consistency ;-)

>  /* Note that if exponent indicates a NaN, we can't really do anything useful
>     (not knowing if the host has NaN's, or how to build one).  So it will
>     end up as an infinity or something close; that is OK.  */

Perhaps we should allow each native platform to provide a function
that produces a NaN for every FP type it supports?  Then utils.c won't
need to bother about doing things it doesn't know about.