On Thu, 7 Nov 2013, Uros Bizjak wrote: > However, this insn also raised FE_INEXACT flag (also on x86_64), > probably not what you wanted. Your code that generates FE_UNDERFLOW > will also raise FE_INEXACT. (and FE_DENORMAL).
If the compound assignment raised overflow or underflow, it will also have raised inexact, so it's not a problem that this code raises inexact along with overflow/underflow (and then raises it again - ISO C expressly "does not require support for trap handlers that maintain information about the order or count of floating-point exceptions"). I raised the case of exact underflow in <http://www.open-std.org/jtc1/sc22/wg14/13103>, but it's a matter to be dealt with when standard C gets bindings for non-default exception handling (probably in TS 18661-5, not yet written) rather than now. If GCC were to implement such bindings, the issues with delayed x87 exceptions might also need addressing for them - but given the lack of support for exceptions and rounding modes following C99/C11 Annex F, I don't really expect support for new bindings for exceptions and rounding modes any time soon. (Separately, C99/C11 also leave it implementation-defined whether feraiseexcept raises inexact along with overflow and underflow - but here we're dealing with exceptions we know came from floating-point arithmetic, rather than an arbitrary user-specified argument to feraiseexcept.) -- Joseph S. Myers jos...@codesourcery.com
