Re: [Qemu-devel] tcg problem running SPARC program on x86

["Anton Salikhmetov" <salikhmetov@gmail.com>]

> From:  <rob1weld@aol.com>
> Date: 2008/10/13
> Subject: Re: [Qemu-devel] tcg problem running SPARC program on x86
> To: qemu-devel@nongnu.org
>
>
> When I run the current trunk (revision 5478) with
> "/usr/local/bin/qemu-system-mips -cpu 24Kc -M malta ..." I get a
> similar error (calls tcg_abort() ) to the one described by Vince:
>
>
> /build/qemu/trunk/tcg/tcg.c:1484: tcg fatal error
> Aborted
>
>
> If I use exactly the same command but use the "Lenny Debian
> GNU/Linux's repository version" of qemu-system-mips (version 0.9.1-6)
> the error does not occur. Thus, this error is occurring on the MIPS
> platform (host x86) as well as the SPARC.
>
> Rob

I'm having the same error when using qemu-system-mips (-M malta). By
bisection, the revisions 5252 and 5253 were found (5252 is working
fine, while 5253 is not). All the revisions after 5253 have the same
problem with "tcg fatal error" for me. By the way, the only file
target-mips/translate.c is changing while updating the source code
from 5252 to 5253. Hope it helps to close the bug.

Anton

>
> On 8/19/08, Blue Swirl <blauwirbel@xxxxxxxxx> wrote:
>>
>> On 8/18/08, Vince Weaver <vince@xxxxxxxxxxxxxxx> 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.
>
> I have isolated the problem to andi op. The attached patch makes the
> bug go away by disabling the offending andi, but it's of course not a
> real fix. Why andi fails with op flag enabled, I have no idea.
>