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~
