Version 7 (modified by p_tanski, 13 years ago) (diff)

update for #1042 fix

Cmm: Implementing Exception Handling

The IEEE 754 specification for floating point numbers defines exceptions for certain floating point operations, including:

  • range violation (overflow, underflow);
  • rounding errors (inexact);
  • invalid operation (invalid operand, such as comparison with a NaN value, the square root of a negative number or division of zero by zero); and,
  • zero divide (a special case of an invalid operation).

Many architectures support floating point exceptions by including a special register as an addition to other exception handling registers. The IBM PPC includes the FPSCR ("Floating Point Status Control Register"); the Intel x86 processors use the MXCSR register. When the PPC performs a floating point operation it checks for possible errors and sets the FPSCR. Some processors allow a flag in the Foating-Point Unit (FPU) status and control register to be set that will disable some exceptions or the entire FPU exception handling facility. Some processors disable the FPU after an exception has occurred while others, notably Intel's x86 and x87 processors, continue to perform FPU operations. Depending on whether quiet NaNs (QNaNs) or signaling NaNs (SNaNs) are used by the software, an FPU exception may signal an interrupt for the software to pass to its own exception handler.

Some higher level languages provide facilities to handle these exceptions, including Ada, Fortran (F90 and later), C++ and C (C99, fenv.h, float.h on certain compilers); others may handle such exceptions without exposing a low-level interface. There are three reasons to handle FPU exceptions, and these reasons apply similarly to other exceptions:

  • the facilities provide greater control;
  • the facilities are efficient--more efficient than a higher-level software solution; and,
  • FPU exceptions may be unavoidable, especially if several FPU operations are serially performed at the machine level so the higher level software has no opportunity to check the results in between operations.

There has been at least one problem in GHC that would benefit from exception handling--in some cases, for Integrals. See bug ticket #1042. The bug occurs in showing the number, in [GhcFile(libraries/base/GHC/Show.lhs) GHC.Show], showSignedInt, before conversion from base_2 to base_10, where a negative Int (always Int32) is negated in order to process it as a positive value when converting it to a string, base_10, causing an overflow error on some architectures. Note that the exception example in #1042 does not occur on PowerPC machines, which dutifully print the two's complement of (-2147483648::Int) `div` (-1::Int): 0. (-2147483648 is the minimum bound for signed Ints, so negating it should properly become, bitwise, a positive 2147483647 (all but bit 31 set); once negated again when divided by -1 this would be 0; -0 is converted to 0.) On some architectures such as Intel 64 and IA-32, negating the minimum bound does not wrap around to 0 but overflows, which is reported as a floating point "overflow" (#O) exception. The workaround was to avoid negating minBound Ints.

There was a long message thread on the Haskell-prime mailing list, "realToFrac Issues," beginning with John Meacham's message and ending with Simon Marlow's message. The following code for converting a Float to a Double will fail to produce a floating point exception or NaN on x86 machines (recall that 0.0/0.0 is NaN and a definite FPU exception):

[in GHCi-6.6 on PowerPC, OS X]:

Prelude> 0.0/0.0

Prelude> realToFrac (0.0/0.0) :: Double

Prelude> realToFrac (0.0/0.0 :: Float)

Prelude> realToFrac (0.0/0.0 :: Float) :: Double

Prelude> realToFrac (1.0/0.0)
Prelude> realToFrac (1.0/0.0 :: Float)

This bug is not due to the lack of FPU exceptions in Cmm but bears mention as the internal conversion performed in 'realToFrac' on 'Float's would benefit from FPU exceptions: with Haskell-support for FPU exceptions this realToFrac would be able to issue an exception for NaN, Infinity or rounding errors when converting a Float to a Double and vice versa. There is a related problem with rounding errors in the functions 'encodeFloat', 'decodeFloat', 'encodeDouble' and 'decodeDouble', see ReplacingGMPNotes/TheCurrentGMPImplementation.