From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:56979) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzhDB-00070X-Nj for qemu-devel@nongnu.org; Wed, 25 Jun 2014 03:01:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WzhDA-0000n9-Q7 for qemu-devel@nongnu.org; Wed, 25 Jun 2014 03:01:41 -0400 Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:39773) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WzhDA-0000jv-JK for qemu-devel@nongnu.org; Wed, 25 Jun 2014 03:01:40 -0400 Date: Wed, 25 Jun 2014 08:01:17 +0100 From: Al Viro Message-ID: <20140625070117.GD18016@ZenIV.linux.org.uk> References: <20140624043423.GX18016@ZenIV.linux.org.uk> <20140624165244.GY18016@ZenIV.linux.org.uk> <53A9C47C.2050002@twiddle.net> <20140624203244.GZ18016@ZenIV.linux.org.uk> <53A9E650.2020709@twiddle.net> <20140624212450.GB18016@ZenIV.linux.org.uk> <53A9EE7E.4020802@twiddle.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53A9EE7E.4020802@twiddle.net> 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: qemu-devel@nongnu.org On Tue, Jun 24, 2014 at 02:32:46PM -0700, Richard Henderson wrote: > On 06/24/2014 02:24 PM, Al Viro wrote: > > Al, off to figure out the black magic TCG is using to generate calls... > > If you've a helper > > DEF_HELPER_1(halt, void, i64) > > then > > gen_helper_halt(...) > > will generate the tcg ops that result in the call. Another fun issue: CVTTQ is both underreporting the overflow *AND* reports the wrong kind - FOV instead of IOV. * it misses reporting overflows for case when it *knows* that overflow will happen - the need to shift up by more than 63 bits. Trivially fixed, of course. There overflow cases leave wrong result as well - should be 0. * it also misses reporting overflows for case when value is in ranges 2^63..2^64-1 and -2^64+1..-2^63-1. And yes, it's asymmetric - 2^63 is an overflow, -2^63 isn't. * overflow is reported by float_raise(float_flag_overflow, &FP_STATUS). Wrong flag - it should be IOV, not FOV. And it should be set in FPCR regardless of the trap modifier (IOV, this VI thing is wrong - we should deal with that only when we generate a trap). * All overflow cases should raise INE as well. Could we steal bit 1 in float_exception_flags for IOV? It is (currently?) unused - enum { float_flag_invalid = 1, float_flag_divbyzero = 4, float_flag_overflow = 8, float_flag_underflow = 16, float_flag_inexact = 32, float_flag_input_denormal = 64, float_flag_output_denormal = 128 }; That would allow to deal with that crap nicely - we could have it raise the new flag, then have helper_fp_exc_raise_... for default trap mode mask it out (and yes, we need to set FPCR flags in default mode, as well as /U and /V - confirmed by direct experiment *and* by TFM). If we can't... well, we could put that flag separately, but it would be more unpleasant. Folks?