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