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