A possible bug in parsing floating point numbers.
tm
tm@mail.kloo.net
Wed Apr 17 17:20:00 GMT 2002
On Wed, 3 Apr 2002, Zack Weinberg wrote:
> On Tue, Apr 02, 2002 at 01:29:21AM -0800, Kazu Hirata wrote:
> >
> > The first patch breaks the build of the h8300 port during compilation
> > of libgcc2.c. With the second patch, the h8300 port builds again, but
> > I get ".long 0" in an assembly output for any floating point constant.
> > Since you seem to have done some cleanup/fix on the lexical analysis
> > of floating point numbers, I am wondering if you could give me some
> > insight into this problem. Here is what's happening.
>
> Please try this patch.
>
> zw
I believe this breaks all targets where sizeof(double) != 8.
The problem occurs because the patch blindly assumes the datatype to be
converted is a 64-bit double precision float. On targets such as the
H8/300H where sizeof(double) = 4, the compiler retains all
floating-point values as float.
Succinctly, here's what happens:
1) Compiler encodes 1.0f as 0x3f80 0x0000
2) Patched code blindly calls e53toe() with 0x3f80 0x0000. This is bad,
because e53toe() is expecting a double-precision float value, which
would be 0x3ff0 0x0000 0x0000 0x0000 for 1.0.
3) e53toe() reads 8 bytes of which the last 4 bytes are garbage
(0x3f80 0x0000 (garbage bytes 1-4)) and converts it to an 18-byte
expanded precision value which has garbage bits at the end.
4) Later on, the compiler converts the corrupted 18-byte expanded
precision value back to a float, and the value is either
0x3f80 0x0001 or 0x3f80 0x0002 depending on the value of
(garbage byte 1)
Basically, this patch causes a buffer overrun on 32-bit double
targets.
I would like to request this patch be fixed ASAP or the entire patch set
backed out until this problem is resolved.
Toshi
More information about the Gcc-bugs
mailing list