From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43)
	id 1H6QEi-0001pT-Uv
	for qemu-devel@nongnu.org; Mon, 15 Jan 2007 06:42:49 -0500
Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43)
	id 1H6QEe-0001oa-Ou
	for qemu-devel@nongnu.org; Mon, 15 Jan 2007 06:42:48 -0500
Received: from [199.232.76.173] (helo=monty-python.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1H6QEe-0001oT-1n
	for qemu-devel@nongnu.org; Mon, 15 Jan 2007 06:42:44 -0500
Received: from [66.139.79.212] (helo=tapir.sajinet.com.pe)
	by monty-python.gnu.org with esmtp (Exim 4.52) id 1H6QEd-0004EZ-Lr
	for qemu-devel@nongnu.org; Mon, 15 Jan 2007 06:42:43 -0500
Date: Mon, 15 Jan 2007 05:54:10 -0600
From: Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
Subject: Re: [Qemu-devel] [BUG] QEMU x86_64 SSE bug in modf()
Message-ID: <20070115115410.GA25141@tapir.sajinet.com.pe>
References: <45AB54D9.9020207@linbox.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <45AB54D9.9020207@linbox.com>
Reply-To: qemu-devel@nongnu.org
List-Id: qemu-devel.nongnu.org
List-Unsubscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.gnu.org/pipermail/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <http://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: qemu-devel@nongnu.org

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