From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:57296)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X1pmK-00046F-Ba
	for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:34:49 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X1pmJ-0003a4-HP
	for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:34:48 -0400
Received: from zeniv.linux.org.uk ([2002:c35c:fd02::1]:36555)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <viro@ftp.linux.org.uk>) id 1X1pmJ-0003ZQ-A5
	for qemu-devel@nongnu.org; Tue, 01 Jul 2014 00:34:47 -0400
Date: Tue, 1 Jul 2014 05:34:45 +0100
From: Al Viro <viro@ZenIV.linux.org.uk>
Message-ID: <20140701043445.GH18016@ZenIV.linux.org.uk>
References: <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>
	<20140625070117.GD18016@ZenIV.linux.org.uk>
	<20140626055541.GF18016@ZenIV.linux.org.uk>
	<53B1AEEF.8010108@twiddle.net>
	<20140630205635.GG18016@ZenIV.linux.org.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20140630205635.GG18016@ZenIV.linux.org.uk>
Sender: Al Viro <viro@ftp.linux.org.uk>
Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Richard Henderson <rth@twiddle.net>
Cc: qemu-devel@nongnu.org

On Mon, Jun 30, 2014 at 09:56:35PM +0100, Al Viro wrote:
> FWIW, it might be better to do what float64_to_int64_round_to_zero() is doing -
> i.e.
> 	if (shift >= 0) {
> 		if (shift < 64)
> 			ret = frac << shift;
> 		if (shift < 11 || a == LIT64(0xC3E0000000000000))
> 			exc = 0;
> 	}
> since frac is between 1ULL<<52 and (1ULL<<53)-1, i.e. shift greater than 11
> is guaranteed to overflow, shift less than 11 is guaranteed not to and shift
> exactly 11 won't overflow only in one case - frac == 1ULL<<52, sign = 1 (i.e.
> when we have -2^63 there).  BTW, shift == 63 is interesting - we certainly
> overflow, but we want the result to be 0 or 2^63 depending on the least
> significant bit of mantissa, not "always 0".  IOW, 0x4720000000000000 should
> yield IOV|INE, with result being 0 and 0x4720000000000001 - IOV|INE and
> result 0x8000000000000000.  Again, verified on actual hardware; the last
> patch I posted had been incorrect in the last case (both cases yield 0 with it,
> same as in mainline qemu).

While we are at it, CVTTQ yields INV on +-infinity, just as it does for NaNs.
IOW, in inline_cvttq()
        exc = (frac ? float_flag_invalid
               : float_flag_int_overflow | float_flag_inexact);
should be simply
	exc = float_flag_invalid;

VAX operations are serious mess, but I'm not sure if we have them actually
used anywhere in Linux kernel or userland.  Always possible, of course, but...