From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KVUCn-000581-DZ for qemu-devel@nongnu.org; Tue, 19 Aug 2008 12:37:13 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KVUCl-000572-6u for qemu-devel@nongnu.org; Tue, 19 Aug 2008 12:37:12 -0400 Received: from [199.232.76.173] (port=47045 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KVUCl-00056u-1L for qemu-devel@nongnu.org; Tue, 19 Aug 2008 12:37:11 -0400 Received: from wf-out-1314.google.com ([209.85.200.168]:9186) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KVUCk-0007Ym-Ki for qemu-devel@nongnu.org; Tue, 19 Aug 2008 12:37:11 -0400 Received: by wf-out-1314.google.com with SMTP id 27so43714wfd.4 for ; Tue, 19 Aug 2008 09:37:08 -0700 (PDT) Message-ID: Date: Tue, 19 Aug 2008 19:37:07 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86 In-Reply-To: <20080818153918.U9420@stanley.csl.cornell.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080818153918.U9420@stanley.csl.cornell.edu> 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 8/18/08, Vince Weaver wrote: > Hello > > I'm continuing on my quest to get the SPEC2000 benchmarks running under > sparc32-linux-user (so far 8 out of 48 work). > > Many of the benchmarks die early on with the following error: > > /fusion/research4/vince/qemu/svn/tcg/tcg.c:1455: tcg > fatal error > > This error is caused when tcg_reg_alloc_mov() is called but ts->val_type > is equal to 0 (which is TEMP_VAL_DEAD). So maybe the optimizer is > optimizing away something that it shouldn't? > > This happens in a block with multiple calls to the SPARC "mulscc" > instruction which is a complicated instruction, so maybe this is finding an > obscure corner case. > > I've attached a very small sample program that exhibits the bug when run > with ./sparc32-linux-user/qemu-sparc32plus Okay, I can finally reproduce this. Strangely it does not occur if -d flag is used and "op" is one of the log items. I have to check if older reports where I could not reproduce the bug were suffering from the same problem. But I haven't found any fix yet.