This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
RE: A possible bug in parsing floating point numbers.
- From: Kazu Hirata <kazu at hxi dot com>
- To: 'Zack Weinberg' <zack at codesourcery dot com>, tm <tm at mail dot kloo dot net>
- Cc: gcc-bugs at gcc dot gnu dot org
- Date: Thu, 18 Apr 2002 14:06:56 -0400
- Subject: RE: A possible bug in parsing floating point numbers.
Hi Zack,
> * real.h: Kill single-letter macros in definition of
> REAL_VALUE_TYPE. New macro REAL_VALUE_TYPE_SIZE, is either 96
> or 160. Use it to define REAL_WIDTH; use REAL_WIDTH to size
> REAL_VALUE_TYPE. The upshot is, REAL_VALUE_TYPE is always
> either 96 or 160 bits wide, such that real.c's "UEMUSHORT e[NE]"
> format always fits it exactly. Provide CONST_DOUBLE_FORMAT.
> Issue #error for unsupported REAL_WIDTH rather than relying on
> later syntax errors.
> * real.c: Nuke EMU_NON_COMPILE (which would have gone by
> silently until the link failed) in favor of #error.
> Disentangle calculation of NE; document that it's always
> either 96 or 160 bits. Cause compile to fail if
> REAL_VALUE_TYPE doesn't fit UEMUSHORT e[NE] exactly. Always
> define GET_REAL and PUT_REAL as bare memcpy-s.
>
> * gengenrtl.c, rtl.c: Delete logic to calculate REAL_WIDTH and
> CONST_DOUBLE_FORMAT; now provided by real.h.
Thanks for the patch. I just ran the testsuite with h8300-hms as a
target. The regressions caused late March now seem to be all gone.
Although I haven't checked actual encoding of floating point numbers
in assembly code, I suppose they are all right.
Kazu Hirata