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>
- Cc: gcc-bugs at gcc dot gnu dot org, tm at mail dot kloo dot net
- Date: Thu, 4 Apr 2002 07:57:39 -0500
- Subject: RE: A possible bug in parsing floating point numbers.
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