Whether the default handler treats floating-point exceptions as severe or non-severe depends upon the chosen /fpe and the /check:underflow compiler options. The /fpe option controls more than the behavior of the default exception handler, however.
The /fpe option selects a particular floating-point exception behavior. There are currently two supported behaviors:
The full consequences of the /fpe compiler option depend upon the type of application you are building. You only get the full support for the chosen behavior in a Fortran Console or QuickWin/Standard Graphics application, assuming you do not override the default run-time exception handler. The work to achieve the full behavior is done partly by each of the default run-time handler, the Fortran compiler, the math library, the underlying hardware, and the operating system.
The following sections discuss:
Floating-Point Exceptions in Fortran Console, Fortran QuickWin, and Fortran Standard Graphics Applications
When you build a console application, the compiler generates a few calls at the beginning of your Fortran main program to Fortran run-time routines that initialize the environment, either with default options or in accordance with your selected compile-time options.
Users can poll the floating-point status word with GETSTATUSFPQQ to see if an exception has occurred and can clear the status register with CLEARSTATUSFPQQ.
In a Fortran console or Fortran QuickWin application, the Visual Fortran run-time system provides a default handler unless you establish your own. For all exceptions except underflow, the run-time system just prints out an error message and aborts the application. For underflow, the run-time system replaces the result with zero. This treatment of denormalized numbers with /fpe:0 is called abrupt underflow to 0 (zero), as opposed to gradual underflow to 0 provided with /fpe:3.
There are no denormalized numbers with /fpe:0. Further, if you also select /check:underflow with /fpe:0, you get a message at run-time for each of the first two occurrences of a floating-point underflow and a total count of underflows when the application exits. The /check:underflow option is not supported with /fpe:3.
Fixing up underflow results to zero can significantly degrade the performance of your ia32 application. If you are experiencing a large number of underflows, consider changing your code to avoid underflows or consider masking underflow traps and allowing the hardware to operate on denormalized numbers. The ia32 hardware is designed to operate correctly in the denormalized range and doing so is much faster than trapping to fix up a result to zero.
Another important point to understand about selecting the /fpe option is that the generated code must support the trapping mode. When an ia32 floating-point instruction generates an exceptional result, you do not necessarily get a trap. The instruction must be followed by an fwait instruction or another floating-point operate instruction to cause the trap to occur.
The Visual Fortran compiler generates machine code to support these requirements in accordance with your selected /fpe option setting. In other words, the generated code must support the trapping mode. You can see this by compiling a simple test program and look at the machine code listing with /fpe:0 first, then /fpe:3. There are no fwait instructions in the /fpe:3 code. Even if you replace the default run-time exception handler with your own handler, you may still want to compile with /fpe:0 to generate code that supports trapping.
Floating-Point Exceptions in Fortran DLL Applications
In a DLL, there is no main Fortran program (unless you have written your main program in Fortran), so there is no automatic calling of run-time routines to initialize the environment. Even if you select /fpe:0, there is nothing that causes the run-time system to unmask traps in the hardware so you won't see traps. You will continue to see the hardware generated default IEEE results (Nan's, Infinities, and and denormalized numbers in your computations). The generated code will still do its part by supplying the fwait instructions, and so on, but unless the traps are unmasked somehow, no traps will occur. You can use SETCONTROLFPQQ or FOR_SET_FPE to unmask traps in the floating-point control word.
There is also no default exception handling in a DLL. The main application that calls the DLL must provide this, or the code in the DLL must provide something when it is called. Since underflow processing (fixup to 0, and so on) is done by the default Fortran run-time system handler, a DLL won't have that feature automatically.
A typical strategy is to compile with /fpe:0, but only unmask floating divide by zero, floating overflow, and floating invalid traps in the floating-point control word. By leaving floating-point underflow traps masked, the hardware will continue to provide gradual underflow through the denormalized range, but other floating-point exceptions will generate traps, which the user then handles as desired.
Floating-Point Exceptions in Fortran Windows Applications
In a Fortran Windows application, the situation is similar to a Fortran DLL application. You define a WinMain routine in your Fortran code as the main entry point for your application. The Fortran run-time system does not define the main routine as it does in a Fortran console or Fortran QuickWin (or Standard Graphics) application. Your code is not protected by the default handler and the default run-time initialization routines are not called.