From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Fseix-0002ln-1i for qemu-devel@nongnu.org; Tue, 20 Jun 2006 07:48:51 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Fseiu-0002lN-Hg for qemu-devel@nongnu.org; Tue, 20 Jun 2006 07:48:49 -0400 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Fseiu-0002l3-7j for qemu-devel@nongnu.org; Tue, 20 Jun 2006 07:48:48 -0400 Received: from [81.103.221.48] (helo=mtaout02-winn.ispmail.ntl.com) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FsetP-0001E2-T7 for qemu-devel@nongnu.org; Tue, 20 Jun 2006 07:59:40 -0400 Received: from aamtaout04-winn.ispmail.ntl.com ([81.103.221.35]) by mtaout02-winn.ispmail.ntl.com with ESMTP id <20060620114842.LMPM27023.mtaout02-winn.ispmail.ntl.com@aamtaout04-winn.ispmail.ntl.com> for ; Tue, 20 Jun 2006 12:48:42 +0100 Received: from suse10.valgrind.org ([82.21.96.252]) by aamtaout04-winn.ispmail.ntl.com with ESMTP id <20060620114842.YPPF16086.aamtaout04-winn.ispmail.ntl.com@suse10.valgrind.org> for ; Tue, 20 Jun 2006 12:48:42 +0100 From: Julian Seward Subject: Re: [Qemu-devel] cvttps2dq, movdq2q, movq2dq incorrect behaviour Date: Tue, 20 Jun 2006 12:48:35 +0100 References: <200606201154.40985.jseward@acm.org> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606201248.36106.jseward@acm.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org On Tuesday 20 June 2006 12:29, malc wrote: > The signature of movdq2q is Pq, VRq and for movq2dq - Vo, PRq it appears > that translate.c gets it backwards, attached patch should deal with it. Cool. > As for cvttps2dq i ran it with interpreter which uses outdated(i.e. non > soft-float) conversion routines and it passed, so my guess would be that > this is float32_to_int32_round_to_zero vs (int32_t) cast issue. I had a feeling this is a garbage-in-memory (or regs, or somewhere) problem. Reason is that the wrong results kept changing as I cut the full test program down to just the small one I posted. Can you try on a vanilla build of i386-softmmu from cvs? J