From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33347) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2MR9-0005AT-CH for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:27:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1X2MR0-0000rX-BH for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:27:07 -0400 Received: from mail-pa0-x230.google.com ([2607:f8b0:400e:c03::230]:43791) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1X2MR0-0000rT-3L for qemu-devel@nongnu.org; Wed, 02 Jul 2014 11:26:58 -0400 Received: by mail-pa0-f48.google.com with SMTP id et14so12676720pad.7 for ; Wed, 02 Jul 2014 08:26:57 -0700 (PDT) Sender: Richard Henderson Message-ID: <53B424BD.6070705@twiddle.net> Date: Wed, 02 Jul 2014 08:26:53 -0700 From: Richard Henderson MIME-Version: 1.0 References: <20140625070117.GD18016@ZenIV.linux.org.uk> <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> <20140702055027.GL18016@ZenIV.linux.org.uk> <20140702061723.GM18016@ZenIV.linux.org.uk> In-Reply-To: <20140702061723.GM18016@ZenIV.linux.org.uk> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [RFC] alpha qemu arithmetic exceptions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Al Viro Cc: Peter Maydell , QEMU Developers On 07/01/2014 11:17 PM, Al Viro wrote: > If we don't want FE_INEXACT seen by fetestexcept() after rounding 4.5, we'd > better not use FPCR.INE - *all* variants of actual hardware (at least from > 21064A to 21264) set that sucker, and 4.7 in Architecture Reference Manual > very clearly requires such behaviour for any subset that isn't completely > without floating point support. Um, where do you see that? I see: # 4.7.6.4 IEEE-Compliant Arithmetic Without Inexact Exception # This model is similar to the model in Section 4.7.6.3, except this # model does not signal inexact results either by the inexact status # flag or by trapping. [...] This model is implemented by using IEEE # floating-point instructions with the /SU or /SV trap qualifiers. The important words to me being "does not signal" and "inexact status flag". Thus in sysdeps/alpha/fpu/s_nearbyint.c I explicitly use cvttq/svd and not cvttq/svid. By my reading that means no inexact shall be raised. r~