Exception types recognized by the Arm® floating-point environment
The Arm® floating-point environment recognizes a number of different types of exception.
NoteThe Arm Compiler toolchain does not support floating-point exception trapping for AArch64 targets.
The following types of exception are recognized:
- Invalid Operation exception
This occurs when there is no sensible result for an operation. This can happen for any of the following reasons:
- Performing any operation on a signaling NaN, except the simplest operations (copying and changing the sign).
- Adding plus infinity to minus infinity, or subtracting an infinity from itself.
- Multiplying infinity by zero.
- Dividing 0 by 0, or dividing infinity by infinity.
- Taking the remainder from dividing anything by 0, or infinity by anything.
- Taking the square root of a negative number (not including minus zero).
- Converting a floating-point number to an integer if the result does not fit.
- Comparing two numbers if one of them is a NaN.
If the Invalid Operation exception is not trapped, these operations return a quiet NaN. The exception is conversion to an integer. This returns zero because there are no quiet NaNs in integers.
- Divide by Zero exception
This occurs if you divide a finite nonzero number by zero. Be aware that:
- Dividing zero by zero gives an Invalid Operation exception.
- Dividing infinity by zero is valid and returns infinity.
If Divide by Zero is not trapped, the operation returns infinity.
- Overflow exception
This occurs when the result of an operation is too big to fit into the format. This happens, for example, if you add the largest representable number to itself. The largest float value is
If Overflow is not trapped, the operation returns infinity, or the largest finite number, depending on the rounding mode.
- Underflow exception
This can occur when the result of an operation is too small to be represented as a normalized number (with
Expat least 1).
The situations that cause Underflow depend on whether it is trapped or not:
- If Underflow is trapped, it occurs whenever a result is too small to be represented as a normalized number.
If Underflow is not trapped, it only occurs if the result requires rounding. So, for example, dividing the
0x00800000by 2 does not signal Underflow, because the result
0x00400000is exact. However, trying to multiply the float number
0x00000001by 1.5 does signal Underflow.
NoteFor readers familiar with the IEEE 754 specification, the chosen implementation options in the Arm Compiler are to detect tininess before rounding, and to detect loss of accuracy as an inexact result.
If Underflow is not trapped, the result is rounded to one of the two nearest representable denormal numbers, according to the current rounding mode. The loss of precision is ignored and the system returns the best result it can.
The Inexact Result exception happens whenever the result of an operation requires rounding. This would cause significant loss of speed if it had to be detected on every operation in software, so the ordinary floating-point libraries do not support the Inexact Result exception. The enhanced floating-point libraries, and hardware floating-point systems, all support Inexact Result.
If Inexact Result is not trapped, the system rounds the result in the usual way.
The flag for Inexact Result is also set by Overflow and Underflow if either one of those is not trapped.
All exceptions are untrapped by default.