A possible bug in parsing floating point numbers.

[tm]

On Thu, 4 Apr 2002, Kazu Hirata wrote:

> Hi Zack,
> 
> > > 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.
> 
> Thanks for the patch.  I just tried your patch.  It seems to fix float
> problems, thus reducing so many regressions, but double remains to be
> an issue.  double is supposed to be the same as float on h8300 port,
> both 4-byte wide.

Actually, this patch does not really fix the float problem.

Consider:

float b = 1.0f;
int func(double a)

{
        return a < 1.0;
}

Compiled with -O2 -mint32 -mh -S this produces:

_b:
        .long   1065353218
        .section .rodata
        .align 2
.LC0:
        .long   1065353217
        .section .text
        .align 1
        .global _func
_func:
        push.l  er6
        mov.l   er7,er6
        push.l  er4
        sub.l   er4,er4
        mov.l   @.LC0,er1
        jsr     @___ltsf2
...

If you look closely, the value 1.0f has been encoded twice in TWO
different ways.

The first one is the static initialization of b which is encoded as
1065353218. In hexadecimal this value is 0x3f800002 which is incorrect.

The second value is one of the arguments passed to ___ltsf2. This value
is 106535217 which is hexadecimal 0x3f800001 which is also incorrect.

If I compile the same source code for x86 with gcc-3.0.4
the output looks like this:

b:
        .long   0x3f800000
        .text
        .align 16
.globl func
        .type   func,@function
func:
        pushl   %ebp
        movl    %esp, %ebp
        subl    $8, %esp
...

gcc-3.0.4 for the x86 target correctly encodes 1.0f as 0x3f800000.

This is very strange that gcc for H8 doesn't encode 1.0f correctly,
and even stranger that it doesn't encode it consistently.

Toshi