A possible bug in parsing floating point numbers.

[Kazu Hirata]

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.

The following testcase, simplified from execute/921208-1.c, fails.
Could you take a look?  I am wondering if the constants, LC0 and LC1,
are OK...

double
foo (double a)
{
  return a * a;
}

main()
{
  if (foo (2.0) != 4.0)
    abort ();
  exit (0);
}

	.section .text
	.align 1
	.global _foo
_foo:
	mov.l	er0,er1
	jsr	@___mulsf3
	rts
	.section .rodata
	.align 2
.LC0:
	.long	1073741827
	.align 2
.LC1:
	.long	1082130435
	.section .text
	.align 1
	.global _main
_main:
	mov.l	@.LC0,er0
	jsr	@_foo
	mov.l	@.LC1,er1
	jsr	@___nesf2
	mov.l	er0,er0
	beq	.L3
	jsr	@_abort
.L3:
	sub.w	r0,r0
	jsr	@_exit
	.end

Kazu Hirata