* [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
@ 2007-01-15 10:18 Ludovic Drolez
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
2007-01-15 12:02 ` [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Thiemo Seufer
0 siblings, 2 replies; 9+ messages in thread
From: Ludovic Drolez @ 2007-01-15 10:18 UTC (permalink / raw)
To: qemu-devel
Hi !
I've found a bug in Qemu: conversion of floats to strings fails
in some cases. For example, Ganglia (cluster monitoring software), shows
random values and as well as PHP5 programs.
Float to string conversion uses modf() but this function fails under QEMU and
SLES 64, as you can see in this small test program below:
===========
#include <stdio.h>
#include <math.h>
int main()
{
double x = 1.1;
double y;
double z;
printf("Calling modf() for %f\n", x);
z = modf(x,&y);
printf("fractional part = %f\ninteger part = %f\n", z, y);
return 0;
}
===========
Under QEMU/Sles 10 64 you get:
Calling modf() for 1.100000
fractional part = 1.100000 <---???
integer part = 1.000000
But with a real x64 system or under QEMU/Debian 64 you get the right result:
Calling modf() for 1.100000
fractional part = 0.100000
integer part = 1.000000
The SLES's glibc uses lots of SSE instructions as you can see in the dump
below (gcc 4.1.0):
===========SLES 64 modf()==========
000000000002ed00 <modf>:
2ed00: f2 0f 11 44 24 f8 movsd %xmm0,0xfffffffffffffff8(%rsp)
2ed06: 48 8b 44 24 f8 mov 0xfffffffffffffff8(%rsp),%rax
2ed0b: 66 0f 28 c8 movapd %xmm0,%xmm1
2ed0f: 48 89 c6 mov %rax,%rsi
2ed12: 48 b8 ff ff ff ff ff mov $0x7fffffffffffffff,%rax
2ed19: ff ff 7f
2ed1c: 48 89 f2 mov %rsi,%rdx
2ed1f: 48 21 c2 and %rax,%rdx
2ed22: 48 b8 ff ff ff ff ff mov $0x433fffffffffffff,%rax
2ed29: ff 3f 43
2ed2c: 48 39 c2 cmp %rax,%rdx
2ed2f: 76 3f jbe 2ed70 <modf+0x70>
2ed31: 48 b8 00 00 00 00 00 mov $0x7ff0000000000000,%rax
2ed38: 00 f0 7f
2ed3b: 48 39 c2 cmp %rax,%rdx
2ed3e: 0f 87 82 00 00 00 ja 2edc6 <modf+0xc6>
2ed44: 48 b8 00 00 00 00 00 mov $0x8000000000000000,%rax
2ed4b: 00 00 80
2ed4e: f2 0f 11 07 movsd %xmm0,(%rdi)
2ed52: 48 21 c6 and %rax,%rsi
2ed55: 48 89 74 24 f8 mov %rsi,0xfffffffffffffff8(%rsp)
2ed5a: f2 0f 10 44 24 f8 movsd 0xfffffffffffffff8(%rsp),%xmm0
2ed60: 66 0f 28 c8 movapd %xmm0,%xmm1
2ed64: 66 0f 28 c1 movapd %xmm1,%xmm0
2ed68: c3 retq
2ed69: 66 data16
2ed6a: 66 data16
2ed6b: 66 data16
2ed6c: 90 nop
2ed6d: 66 data16
2ed6e: 66 data16
2ed6f: 90 nop
2ed70: 48 b8 ff ff ff ff ff mov $0x3fefffffffffffff,%rax
2ed77: ff ef 3f
2ed7a: 48 39 c2 cmp %rax,%rdx
2ed7d: 77 15 ja 2ed94 <modf+0x94>
2ed7f: 48 b8 00 00 00 00 00 mov $0x8000000000000000,%rax
2ed86: 00 00 80
2ed89: 66 0f 28 c1 movapd %xmm1,%xmm0
2ed8d: 48 21 c6 and %rax,%rsi
2ed90: 48 89 37 mov %rsi,(%rdi)
2ed93: c3 retq
2ed94: 48 8d 04 36 lea (%rsi,%rsi,1),%rax
2ed98: b9 33 04 00 00 mov $0x433,%ecx
2ed9d: 48 c1 e8 35 shr $0x35,%rax
2eda1: 29 c1 sub %eax,%ecx
2eda3: 48 c7 c0 ff ff ff ff mov $0xffffffffffffffff,%rax
2edaa: 48 d3 e0 shl %cl,%rax
2edad: 48 21 c6 and %rax,%rsi
2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0
2edb5: 48 89 74 24 f0 mov %rsi,0xfffffffffffffff0(%rsp)
2edba: 48 89 37 mov %rsi,(%rdi)
2edbd: f2 0f 5c c8 subsd %xmm0,%xmm1
2edc1: 66 0f 28 c1 movapd %xmm1,%xmm0
2edc5: c3 retq
2edc6: f2 0f 58 c8 addsd %xmm0,%xmm1
2edca: f2 0f 11 07 movsd %xmm0,(%rdi)
2edce: 66 0f 28 c1 movapd %xmm1,%xmm0
2edd2: c3 retq
====================================
And the Debian one, a little less (gcc 4.1.3):
=========== Debian 64 modf() ===============
000000000002e360 <modf>:
2e360: f2 0f 11 44 24 f8 movsd %xmm0,0xfffffffffffffff8(%rsp)
2e366: 48 8b 54 24 f8 mov 0xfffffffffffffff8(%rsp),%rdx
2e36b: 48 89 d6 mov %rdx,%rsi
2e36e: 41 89 d0 mov %edx,%r8d
2e371: 48 c1 ee 20 shr $0x20,%rsi
2e375: 89 f0 mov %esi,%eax
2e377: c1 f8 14 sar $0x14,%eax
2e37a: 25 ff 07 00 00 and $0x7ff,%eax
2e37f: 8d 88 01 fc ff ff lea 0xfffffffffffffc01(%rax),%ecx
2e385: 83 f9 13 cmp $0x13,%ecx
2e388: 7f 38 jg 2e3c2 <modf+0x62>
2e38a: 85 c9 test %ecx,%ecx
2e38c: 0f 88 ae 00 00 00 js 2e440 <modf+0xe0>
2e392: ba ff ff 0f 00 mov $0xfffff,%edx
2e397: d3 fa sar %cl,%edx
2e399: 89 d0 mov %edx,%eax
2e39b: 21 f0 and %esi,%eax
2e39d: 44 09 c0 or %r8d,%eax
2e3a0: 75 7e jne 2e420 <modf+0xc0>
2e3a2: f2 0f 11 07 movsd %xmm0,(%rdi)
2e3a6: 81 e6 00 00 00 80 and $0x80000000,%esi
2e3ac: 89 f0 mov %esi,%eax
2e3ae: 48 c1 e0 20 shl $0x20,%rax
2e3b2: 48 89 44 24 f8 mov %rax,0xfffffffffffffff8(%rsp)
2e3b7: 66 0f 12 4c 24 f8 movlpd 0xfffffffffffffff8(%rsp),%xmm1
2e3bd: f2 0f 10 c1 movsd %xmm1,%xmm0
2e3c1: c3 retq
2e3c2: 83 f9 33 cmp $0x33,%ecx
2e3c5: 7f 39 jg 2e400 <modf+0xa0>
2e3c7: 8d 88 ed fb ff ff lea 0xfffffffffffffbed(%rax),%ecx
2e3cd: b8 ff ff ff ff mov $0xffffffff,%eax
2e3d2: d3 e8 shr %cl,%eax
2e3d4: 85 c2 test %eax,%edx
2e3d6: 74 ca je 2e3a2 <modf+0x42>
2e3d8: f7 d0 not %eax
2e3da: 21 c2 and %eax,%edx
2e3dc: 48 89 f0 mov %rsi,%rax
2e3df: 48 c1 e0 20 shl $0x20,%rax
2e3e3: 48 09 d0 or %rdx,%rax
2e3e6: 48 89 44 24 f8 mov %rax,0xfffffffffffffff8(%rsp)
2e3eb: 48 89 07 mov %rax,(%rdi)
2e3ee: 66 0f 12 4c 24 f8 movlpd 0xfffffffffffffff8(%rsp),%xmm1
2e3f4: f2 0f 5c c1 subsd %xmm1,%xmm0
2e3f8: f3 c3 repz retq
2e3fa: 66 data16
2e3fb: 66 data16
2e3fc: 90 nop
2e3fd: 66 data16
2e3fe: 66 data16
2e3ff: 90 nop
2e400: 81 f9 00 04 00 00 cmp $0x400,%ecx
2e406: f2 0f 11 07 movsd %xmm0,(%rdi)
2e40a: 75 9a jne 2e3a6 <modf+0x46>
2e40c: 89 f0 mov %esi,%eax
2e40e: 25 ff ff 0f 00 and $0xfffff,%eax
2e413: 41 09 c0 or %eax,%r8d
2e416: 74 8e je 2e3a6 <modf+0x46>
2e418: eb de jmp 2e3f8 <modf+0x98>
2e41a: 66 data16
2e41b: 66 data16
2e41c: 90 nop
2e41d: 66 data16
2e41e: 66 data16
2e41f: 90 nop
2e420: 89 d0 mov %edx,%eax
2e422: f7 d0 not %eax
2e424: 21 f0 and %esi,%eax
2e426: 48 c1 e0 20 shl $0x20,%rax
2e42a: 48 89 44 24 f8 mov %rax,0xfffffffffffffff8(%rsp)
2e42f: 48 89 07 mov %rax,(%rdi)
2e432: 66 0f 12 4c 24 f8 movlpd 0xfffffffffffffff8(%rsp),%xmm1
2e438: f2 0f 5c c1 subsd %xmm1,%xmm0
2e43c: c3 retq
2e43d: 66 data16
2e43e: 66 data16
2e43f: 90 nop
2e440: 81 e6 00 00 00 80 and $0x80000000,%esi
2e446: 89 f0 mov %esi,%eax
2e448: 48 c1 e0 20 shl $0x20,%rax
2e44c: 48 89 07 mov %rax,(%rdi)
2e44f: c3 retq
=======================
Would someone be able to track down this SSE QEMU bug seen only in SLES's
modf() function ?
Cheers,
--
Ludovic DROLEZ Linbox / Free&ALter Soft
http://lrs.linbox.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
2007-01-15 10:18 [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Ludovic Drolez
@ 2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
2007-01-15 14:00 ` [Qemu-devel] " Ludovic Drolez
2007-01-15 14:16 ` [Qemu-devel] " Julian Seward
2007-01-15 12:02 ` [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Thiemo Seufer
1 sibling, 2 replies; 9+ messages in thread
From: Carlo Marcelo Arenas Belon @ 2007-01-15 11:54 UTC (permalink / raw)
To: qemu-devel
On Mon, Jan 15, 2007 at 11:18:01AM +0100, Ludovic Drolez wrote:
>
> Float to string conversion uses modf() but this function fails under QEMU
> and SLES 64, as you can see in this small test program below:
pressume you mean running SLES 10 64bit as a guest under QEMU here.
which version of qemu for the host? and what platform/arch?
> The SLES's glibc uses lots of SSE instructions as you can see in the dump
> below (gcc 4.1.0):
the gcc that is used for the glibc in the guest should be irrelevant if all
the emulated instructions are correctly compiled in the host and there are no
bugs on them of course.
the host has to be compiled with gcc 3, gcc 4.x won't work even if it
compiles.
> ===========SLES 64 modf()==========
> 000000000002ed00 <modf>:
> 2ed00: f2 0f 11 44 24 f8 movsd
> %xmm0,0xfffffffffffffff8(%rsp)
> 2ed06: 48 8b 44 24 f8 mov 0xfffffffffffffff8(%rsp),%rax
> 2ed0b: 66 0f 28 c8 movapd %xmm0,%xmm1
movapd is actually an SSE2 instruction, and that seem to be the main
difference between this function and the one from Debian (which uses only SSE)
just like the one from my host (Gentoo)
> Would someone be able to track down this SSE QEMU bug seen only in SLES's
> modf() function ?
hopefully you already did.
Carlo
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
2007-01-15 10:18 [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Ludovic Drolez
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
@ 2007-01-15 12:02 ` Thiemo Seufer
2007-01-15 13:54 ` Ludovic Drolez
1 sibling, 1 reply; 9+ messages in thread
From: Thiemo Seufer @ 2007-01-15 12:02 UTC (permalink / raw)
To: Ludovic Drolez; +Cc: qemu-devel
Ludovic Drolez wrote:
[snip]
> Would someone be able to track down this SSE QEMU bug seen only in SLES's
> modf() function ?
Please test if this patch for qemu changes the behaviour.
Thiemo
Index: Makefile.target
===================================================================
RCS file: /sources/qemu/qemu/Makefile.target,v
retrieving revision 1.136
diff -u -p -r1.136 Makefile.target
--- Makefile.target 7 Jan 2007 22:04:40 -0000 1.136
+++ Makefile.target 15 Jan 2007 11:59:15 -0000
@@ -70,7 +70,7 @@ OP_CFLAGS = -Wall -O2 -g -fno-strict-ali
ifeq ($(ARCH),i386)
HELPER_CFLAGS+=-fomit-frame-pointer
-OP_CFLAGS+=-mpreferred-stack-boundary=2 -fomit-frame-pointer
+OP_CFLAGS+=-fomit-frame-pointer
ifeq ($(HAVE_GCC3_OPTIONS),yes)
OP_CFLAGS+= -falign-functions=0 -fno-gcse
else
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
2007-01-15 12:02 ` [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Thiemo Seufer
@ 2007-01-15 13:54 ` Ludovic Drolez
0 siblings, 0 replies; 9+ messages in thread
From: Ludovic Drolez @ 2007-01-15 13:54 UTC (permalink / raw)
To: Thiemo Seufer; +Cc: qemu-devel
Thiemo Seufer wrote:
> Ludovic Drolez wrote:
> [snip]
>
>>Would someone be able to track down this SSE QEMU bug seen only in SLES's
>>modf() function ?
>
>
> Please test if this patch for qemu changes the behaviour.
>
Strange... With this, qemu does not run at all (qemu process stuck with 100%
CPU used).
Ludo.
>
> Thiemo
>
>
> Index: Makefile.target
> ===================================================================
> RCS file: /sources/qemu/qemu/Makefile.target,v
> retrieving revision 1.136
> diff -u -p -r1.136 Makefile.target
> --- Makefile.target 7 Jan 2007 22:04:40 -0000 1.136
> +++ Makefile.target 15 Jan 2007 11:59:15 -0000
> @@ -70,7 +70,7 @@ OP_CFLAGS = -Wall -O2 -g -fno-strict-ali
>
> ifeq ($(ARCH),i386)
> HELPER_CFLAGS+=-fomit-frame-pointer
> -OP_CFLAGS+=-mpreferred-stack-boundary=2 -fomit-frame-pointer
> +OP_CFLAGS+=-fomit-frame-pointer
> ifeq ($(HAVE_GCC3_OPTIONS),yes)
> OP_CFLAGS+= -falign-functions=0 -fno-gcse
> else
>
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf()
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
@ 2007-01-15 14:00 ` Ludovic Drolez
2007-01-15 14:16 ` [Qemu-devel] " Julian Seward
1 sibling, 0 replies; 9+ messages in thread
From: Ludovic Drolez @ 2007-01-15 14:00 UTC (permalink / raw)
To: qemu-devel
Carlo Marcelo Arenas Belon wrote:
> On Mon, Jan 15, 2007 at 11:18:01AM +0100, Ludovic Drolez wrote:
>
>>Float to string conversion uses modf() but this function fails under QEMU
>>and SLES 64, as you can see in this small test program below:
>
>
> pressume you mean running SLES 10 64bit as a guest under QEMU here.
> which version of qemu for the host? and what platform/arch?
Hi !
As said in other posts, the guest is a SLES 10 64 bits, the host under a
Debian sarge 32 bits, and I use qemu 0.8.2. I also tried the latest CVS, and
the same bug is present.
> the gcc that is used for the glibc in the guest should be irrelevant if all
> the emulated instructions are correctly compiled in the host and there are no
> bugs on them of course.
Yes, I was thinking of a bug in qemu sse/sse2 emulation.
> the host has to be compiled with gcc 3, gcc 4.x won't work even if it
> compiles.
Compiled with gcc 3.3.5.
Ludovic.
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
2007-01-15 14:00 ` [Qemu-devel] " Ludovic Drolez
@ 2007-01-15 14:16 ` Julian Seward
2007-01-16 11:22 ` [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug Ludovic Drolez
1 sibling, 1 reply; 9+ messages in thread
From: Julian Seward @ 2007-01-15 14:16 UTC (permalink / raw)
To: qemu-devel
> > Would someone be able to track down this SSE QEMU bug seen only in SLES's
> > modf() function ?
The Valgrind sources contain test programs, including expected outputs,
for all SSE/SSE2/SSE3 instructions on amd64 (see none/tests/amd64/insn-sse
and insn-sse2). Running those on QEMU might be a quick and easy first
check for something wrong in the SSE department. They are not completely
comprehensive but may find obvious arithmetic errors and instruction
decoding errors.
J
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
2007-01-15 14:16 ` [Qemu-devel] " Julian Seward
@ 2007-01-16 11:22 ` Ludovic Drolez
2007-01-16 16:19 ` Ludovic Drolez
0 siblings, 1 reply; 9+ messages in thread
From: Ludovic Drolez @ 2007-01-16 11:22 UTC (permalink / raw)
To: qemu-devel
Julian Seward wrote:
>>>Would someone be able to track down this SSE QEMU bug seen only in SLES's
>>>modf() function ?
>
>
> The Valgrind sources contain test programs, including expected outputs,
> for all SSE/SSE2/SSE3 instructions on amd64 (see none/tests/amd64/insn-sse
> and insn-sse2). Running those on QEMU might be a quick and easy first
> check for something wrong in the SSE department. They are not completely
> comprehensive but may find obvious arithmetic errors and instruction
> decoding errors.
>
Hi !
I've run the valgrind tests on Qemu 0.8.2, in particular insn_basic, insn_fpu,
_mmx, _sse, _sse2. No bugs were found in SSE and FPU emulation, but one was
found in MMX !:
~/tests/none/tests/amd64 # diff insn_mmx.r insn_mmx.stdout.exp
1,6c1,2
< movd_1 ... not ok
< result0.sd[0] = 1234 (expected 1234)
< result0.sd[1] = 0 (expected 5678)
< movd_2 ... not ok
< result0.sd[0] = 1234 (expected 1234)
< result0.sd[1] = 0 (expected 5678)
---
> movd_1 ... ok
> movd_2 ... ok
Which comes from the following test:
#
# %mm <-> ireg64
#
movd mm.sd[1234,5678] r64.sd[1111,2222] => 1.sd[1234,5678]
movd r64.sd[1234,5678] mm.sd[1111,2222] => 1.sd[1234,5678]
So one MMX bug when using 64 bits regs has been found, but the SSE2 bug is
still a mystery :-(
Cheers,
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org tel: +33 3 87 50 87 90
152 rue de Grigy - Technopole Metz 2000 57070 METZ
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
2007-01-16 11:22 ` [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug Ludovic Drolez
@ 2007-01-16 16:19 ` Ludovic Drolez
2007-01-16 17:50 ` Aurelien Jarno
0 siblings, 1 reply; 9+ messages in thread
From: Ludovic Drolez @ 2007-01-16 16:19 UTC (permalink / raw)
To: qemu-devel
I've also found the buggy SSE instruction by tracing modf() with gdb.
It's similar to the MMX bug found below: only the 32 bits part of the register
is stored instead of the whole 64 bits.
The bug is in the movd instruction in 64 bits emulation.
Under gdb, just before the movd I had %rsi=0x3FF0000000000000
and, after movd, %xmm0=0 ! Only the 32bits part seems to be copied when
the source is a 64bits register.
2edaa: 48 d3 e0 shl %cl,%rax
2edad: 48 21 c6 and %rax,%rsi
2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0
So in fact the valgrind mmx bug and the modf() bug have the same cause.
Anyone knows where to fix this bug ?
Cheers,
Ludovic.
>
> Hi !
>
> I've run the valgrind tests on Qemu 0.8.2, in particular insn_basic,
> insn_fpu, _mmx, _sse, _sse2. No bugs were found in SSE and FPU
> emulation, but one was found in MMX !:
>
> ~/tests/none/tests/amd64 # diff insn_mmx.r insn_mmx.stdout.exp
> 1,6c1,2
> < movd_1 ... not ok
> < result0.sd[0] = 1234 (expected 1234)
> < result0.sd[1] = 0 (expected 5678)
> < movd_2 ... not ok
> < result0.sd[0] = 1234 (expected 1234)
> < result0.sd[1] = 0 (expected 5678)
> ---
> > movd_1 ... ok
> > movd_2 ... ok
>
> Which comes from the following test:
> #
> # %mm <-> ireg64
> #
> movd mm.sd[1234,5678] r64.sd[1111,2222] => 1.sd[1234,5678]
> movd r64.sd[1234,5678] mm.sd[1111,2222] => 1.sd[1234,5678]
>
>
> So one MMX bug when using 64 bits regs has been found, but the SSE2 bug is
> still a mystery :-(
>
> Cheers,
>
>
--
Ludovic DROLEZ Linbox / Free&ALter Soft
www.linbox.com www.linbox.org
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug
2007-01-16 16:19 ` Ludovic Drolez
@ 2007-01-16 17:50 ` Aurelien Jarno
0 siblings, 0 replies; 9+ messages in thread
From: Aurelien Jarno @ 2007-01-16 17:50 UTC (permalink / raw)
To: qemu-devel
Ludovic Drolez a écrit :
> I've also found the buggy SSE instruction by tracing modf() with gdb.
> It's similar to the MMX bug found below: only the 32 bits part of the register
> is stored instead of the whole 64 bits.
>
> The bug is in the movd instruction in 64 bits emulation.
> Under gdb, just before the movd I had %rsi=0x3FF0000000000000
> and, after movd, %xmm0=0 ! Only the 32bits part seems to be copied when
> the source is a 64bits register.
>
> 2edaa: 48 d3 e0 shl %cl,%rax
> 2edad: 48 21 c6 and %rax,%rsi
> 2edb0: 66 48 0f 6e c6 movd %rsi,%xmm0
>
> So in fact the valgrind mmx bug and the modf() bug have the same cause.
>
I have just looked at the documentation from AMD. I confirm that in
32-bit mode, the 32 bits of the register have to be copied in the lower
part of mmx or xmm register. In 64-bit mode, the 64 bits of the register
have to be copied in the mmx register or in the lower part of the xmm
register.
So that confirms the implementation in QEMU is wrong.
--
.''`. Aurelien Jarno | GPG: 1024D/F1BCDB73
: :' : Debian developer | Electrical Engineer
`. `' aurel32@debian.org | aurelien@aurel32.net
`- people.debian.org/~aurel32 | www.aurel32.net
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2007-01-16 17:50 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-01-15 10:18 [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Ludovic Drolez
2007-01-15 11:54 ` Carlo Marcelo Arenas Belon
2007-01-15 14:00 ` [Qemu-devel] " Ludovic Drolez
2007-01-15 14:16 ` [Qemu-devel] " Julian Seward
2007-01-16 11:22 ` [Qemu-devel] Re: [BUG] QEMU x86_64 SSE bug in modf() + MMX bug Ludovic Drolez
2007-01-16 16:19 ` Ludovic Drolez
2007-01-16 17:50 ` Aurelien Jarno
2007-01-15 12:02 ` [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf() Thiemo Seufer
2007-01-15 13:54 ` Ludovic Drolez
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).