RFA: Support infinity, NaN, and denormalized numbers in floatformat.c

[Daniel Jacobowitz]

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 <math.h> 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