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

Daniel Jacobowitz
2003-12-03T18:17:51Z

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