IEEE ISO IEC 60559-2020 pdf download – Floating-point arithmetic.
7. Exceptions and default exception handling 7.1 Overview: exceptions and flags This clause specifies five kinds of exceptions that shall be signaled when they arise; the signal invokes default or alternate handling for the signaled exception. For each kind of exception the implementation shall provide a corresponding status flag. This clause also specifies default non-stop exception handling for exception signals, which is to deliver a default result, continue execution, and raise the corresponding status flag (except in the case of exact underflow, see 7.5). Clause 8 specifies alternate exception handling attributes for those signals; a language standard might specify that some of those attributes be implemented and then define means for users to enable them. Default or alternate exception handling for one exception might also signal other exceptions (see overflow and underflow, 7.4 and 7.5). Therefore, a status flag might be raised by default, by alternate exception handling, or by explicit user action (see 5.7.4). With default exception handling, a raised status flag usually indicates that the corresponding exception was signaled and handled by default. Exceptions are handled without raising status flags only in the case of exact underflow and status flags are raised without an exception being signaled only at the user’s request. Status flags shall be lowered only at the user’s request. The user shall be able to test and to alter the status flags individually or collectively, and shall further be able to save and restore all at one time (see 5.7.4).
A program that does not inherit status flags from another source begins execution with all status flags lowered. Language standards should specify defaults in the absence of any explicit user specification, governing: ― Whether any particular flag exists (in the sense of being testable by non-programmatic means such as debuggers) outside of scopes in which a program explicitly sets or tests that flag. ― When a flag has scope greater than within an invoked function, whether and when an asynchronous event, such as raising or lowering the flag in another thread or signal handler, affects the flag tested within that invoked function; this includes events arising from explicit asynchronicity in the program and also events arising from asynchronicity introduced by language or implementation. ― When a flag has scope greater than within an invoked function, whether that flag’s state can be determined by non-programmatic means (such as a debugger) within that invoked function. ― Whether flags raised in invoked functions raise flags in invoking functions. ― Whether flags raised in invoking functions raise flags in invoked functions. ― Whether to allow, and if so the means, to specify that flags shall be persistent in the absence of any explicit program statement otherwise: ― The flags standing at the beginning of execution of a particular function are inherited from an outer environment, typically an invoking function. ― On return from or termination of an invoked function, the flags standing in an invoking function are the flags that were standing in the invoked function at the time of return or termination.