From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:57325) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPiIy-0005EK-CE for qemu-devel@nongnu.org; Sat, 20 Oct 2012 19:18:09 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TPiIw-0000We-Vj for qemu-devel@nongnu.org; Sat, 20 Oct 2012 19:18:08 -0400 Received: from hall.aurel32.net ([88.191.126.93]:47238) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TPiIw-0000WI-Ow for qemu-devel@nongnu.org; Sat, 20 Oct 2012 19:18:06 -0400 Date: Sun, 21 Oct 2012 01:17:57 +0200 From: Aurelien Jarno Message-ID: <20121020231757.GC23114@hall.aurel32.net> References: <1350744508-7066-1-git-send-email-aurelien@aurel32.net> <50832A54.5020609@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <50832A54.5020609@twiddle.net> Sender: Aurelien Jarno Subject: Re: [Qemu-devel] [PATCH] Revert "target-sparc: Make cpu_dst local to OP=2 insns" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Blue Swirl , qemu-devel@nongnu.org On Sun, Oct 21, 2012 at 08:48:52AM +1000, Richard Henderson wrote: > On 2012-10-21 00:48, Aurelien Jarno wrote: > > I am not sure it is the real problem, but at least the optimization of > > using the destination register as a temporary is wrong when the > > instruction might trigger an exception. In that case the result is > > written to the destination register while it should have not. > > > > This reverts commit 5793f2a47e201d251856c7956d6f7907ec0d9f1f. > > Which insn might trigger an exception? Most OP=2 insns don't. There's > divide, but that's done out-of-line, so the assignment to dst does not > happen before the exception... Indeed there a are a few one triggering exception, but I looked too quickly and indeed they do the assignment before. There should be another problem elsewhere as reverting this patch fixes the issue. > Is this sparc64? I assume so, since I did test sparc32... > Yes it's with a sparc64 kernel. I can reproduce the problem with both a 32 and 64-bit userland, though it happens earlier with a 32-bit userland. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net