floating point inconsistency
Andrew Haley
aph@redhat.com
Tue Feb 16 14:14:00 GMT 2010
On 02/16/2010 01:17 PM, Cedric Roux wrote:
> Christoph Groth wrote:
>> Now the question remains whether this is a bug in gcc or not.
>
> I doubt it.
> ----------------------------------------------------------
> .text
>
> .globl _start
> _start:
> fldl angle
> fcos
> fstpl result
> mov $4, %eax
> mov $1, %ebx
> mov $result, %ecx
> mov $8, %edx
> int $0x80
> movl $1, %eax
> xorl %ebx, %ebx
> int $0x80
>
> .data
> .align 8
> .globl angle
> .globl result
> angle:
> .byte 0x3f, 0x73, 0x11, 0xf7, 0xa3, 0x38, 0xe3, 0x3f
>
> result:
> .byte 0, 0, 0, 0, 0, 0, 0, 0
> ----------------------------------------------------------
> gives that:
>
> on the AMD:
> /users/cro> ./a.out |od -tx1
> 0000000 75 d8 82 70 13 66 ea 3f
> 0000010
>
> on the intel:
> /users/cro> ./a.out |od -tx1
> 0000000 76 d8 82 70 13 66 ea 3f
> 0000010
>
> on my 32b computer, it's same result as intel 64b.
> Maybe a rounding issue on the AMD?
> (one should do the computation by hand or with some
> soft mathematical library to get more precision and
> see what the next bit is so to know for sure what
> truncation has to be done...)
I've just checked, and the 64-bit glibc version of sincos does indeed
do
ENTRY (BP_SYM (__sincos))
ENTER
movsd %xmm0, -8(%rsp)
fldl -8(%rsp)
fsincos
...
Andrew.
More information about the Gcc-help
mailing list