On Wed, Jul 02, 2014 at 08:26:53AM -0700, Richard Henderson wrote: > 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.
What does that have to do with exceptions? cvttq/svd is not going to raise one; it *does* set that bit in FPCR, though. What happens afterwards is that fetestexcept() calls osf_getsysinfo(2) with GSI_IEEE_FP_CONTROL for op. Which does w = current_thread_info()->ieee_state & IEEE_SW_MASK; w = swcr_update_status(w, rdfpcr()); and hands the value of w to caller. Now, look at swcr_update_status() (in arch/alpha/include/uapi/asm/fpu.h these days) and note that on 21264 it will throw away the status bits of ->ieee_state and use 6 bits from FPCR instead. Note, BTW, that appendix B (IEEE conformance) claims (in B.1) conversions as hardware-implemented, with "Software routines support remainder, round to integer in floating-point format, and convert binary to/from decimal" right next to it.