From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:37659) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2arr-0000M8-Gn for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:51:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2arq-0004mf-HN for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:51:39 -0400 Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:49192) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2arq-0004kG-9M for qemu-devel@nongnu.org; Thu, 03 Jul 2014 02:51:38 -0400 Date: Thu, 3 Jul 2014 07:51:04 +0100 From: Al Viro Message-ID: <20140703065104.GP18016@ZenIV.linux.org.uk> References: <20140626055541.GF18016@ZenIV.linux.org.uk> <53B1AEEF.8010108@twiddle.net> <20140630205635.GG18016@ZenIV.linux.org.uk> <53B2E9CA.4040802@twiddle.net> <20140701175036.GJ18016@ZenIV.linux.org.uk> <53B2FE3B.6050306@twiddle.net> <20140702040508.GK18016@ZenIV.linux.org.uk> <53B41E36.30906@twiddle.net> <20140702152027.GN18016@ZenIV.linux.org.uk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20140702152027.GN18016@ZenIV.linux.org.uk> Sender: Al Viro Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Richard Henderson Cc: Peter Maydell , QEMU Developers More bugs: addl/v should sign-extend the result, as addl does. As it is, we have uint64_t helper_addlv(CPUAlphaState *env, uint64_t op1, uint64_t op2) { uint64_t tmp = op1; op1 = (uint32_t)(op1 + op2); if (unlikely((tmp ^ op2 ^ (-1UL)) & (tmp ^ op1) & (1UL << 31))) { arith_excp(env, GETPC(), EXC_M_IOV, 0); } return op1; } IOW, #include long r; void __attribute__((noinline)) f(void) { asm __volatile( "subl $31, 1, $0\n\t" "addl $0, $0, $1\n\t" "addl/v $0, $0, $0\n\t" "subq $0, $1, $0\n\t" "stq $0, %0\n\t" : "=m"(r): :"$0", "$1"); } main() { f(); printf("%ld\n", r); } ends up printing 0 on actual hardware (all variants) and 4294967296 on qemu. Similar problem with subl/v - #include long r; void __attribute__((noinline)) f(void) { asm __volatile( "subl $31, 1, $0\n\t" "subl/v $31, 1, $1\n\t" "subq $0, $1, $0\n\t" "stq $0, %0\n\t" : "=m"(r): :"$0", "$1"); } main() { f(); printf("%ld\n", r); } prints 0 on actual hw and -4294967296 on qemu. What constraints do we have on qemu host, anyway? Two's-complement, (int32_t)(uint32_t)x == x for any int32_t x? helper_mullv() seems to assume that... Oh, crap - our mull/v is sensitive to upper 32 bits of multiplicands. If you put 1UL<<32 into one register, 1 into another and say mull/v, result will be 0 and no overflow. qemu does int64_t res = (int64_t)op1 * (int64_t)op2; if (unlikely((int32_t)res != res)) { arith_excp(env, GETPC(), EXC_M_IOV, 0); } return (int64_t)((int32_t)res); which leads to overflow trap triggered for no good reason... Incidentally, all those guys ({add,sub,mul}[lq]/v) *do* assign the result (same as the variant without /v would) before entering the trap. So arith_excp() is wrong here. FWIW, why not just generate trunc_i64_i32 tmp, va trunc_i64_i32 tmp2, vb muls2_i32 tmp2, tmp, tmp, tmp2 ext32s_i64 vc, tmp2 maybe_overflow_32 tmp where maybe_overflow throws IOV unless tmp is 0 or -1? That would appear to suffice for mull/v. mulq/v would be muls2_i64 vc, tmp, va, vb maybe_overflow_64 tmp addl/v: trunc_i64_i32 tmp, va trunc_i64_i32 tmp2, vb add2_i32 tmp2, tmp, tmp, zero, tmp2, zero ext32s_i64 vc, tmp2 maybe_overflow_32 tmp etc. We'd need two helpers, differing only in argument type. Simple if (unlikely(arg && ~arg)) arith_excp(env, GETPC(), EXC_M_IOV, 0); would do. Not sure what flags would be needed in DEFINE_HELPER_... for those, though. Comments?