From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33168) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTYrq-0002PN-FT for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:02:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TTYrl-0006nL-Iy for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:02:02 -0400 Received: from mail-pa0-f45.google.com ([209.85.220.45]:39907) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TTYrl-0006nA-CU for qemu-devel@nongnu.org; Wed, 31 Oct 2012 10:01:57 -0400 Received: by mail-pa0-f45.google.com with SMTP id fb10so952514pad.4 for ; Wed, 31 Oct 2012 07:01:56 -0700 (PDT) Sender: Paolo Bonzini Message-ID: <50912F4D.7060500@redhat.com> Date: Wed, 31 Oct 2012 15:01:49 +0100 From: Paolo Bonzini MIME-Version: 1.0 References: <508EC28A.5060706@redhat.com> <20121029182958.GB29866@ohm.aurel32.net> <508F8CBB.8090101@redhat.com> <509053A2.6010504@weilnetz.de> <20121030235636.GB32197@hall.aurel32.net> <20121031124018.GB3855@ohm.aurel32.net> In-Reply-To: <20121031124018.GB3855@ohm.aurel32.net> Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] 64-on-32 TCG broken List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Aurelien Jarno Cc: Stefan Weil , qemu-devel Il 31/10/2012 13:40, Aurelien Jarno ha scritto: >>> I just tested with latest qemu-system-x86_64 on 32 bit Linux. >>> >>> It also hangs during boot (BIOS), so it looks like this >>> is not a MinGW only problem. >>> >>> Your test with x86_64-linux-user indicates that, too. >>> >>> I also get the problem with TCI. Therefore I expect that any >>> 32 bit TCG target will show it. >>> >> >> It ended up to be a merge issue. The newly added special cases >> for half-dead operations also need to be changed with the liveness >> analysis rework. >> >> The attached patch fixes the issue on a 32-bit linux host. I haven't >> tried win32 yet, maybe someone will beat me. >> > > I have just been able to try, and I confirm it fixes the problem on > win32. Thanks! In general, do not rebase a branch unless you were able to test the rebase fully. Use "git merge" instead. This does not apply to people without commit access (unless they use pull requests---perhaps we should use them more), but it is easy for you. If you hadn't rebased the series, "git bisect" would have pointed out that the original series worked, and that the merge was the problem. (Yes, this is less accurate than knowing *which* patch made invalid assumptions after the rebase. However, you can always do a temporary rebase to find that. A linearized history doesn't say what was the latest "master" commit on top of which you tested). Paolo