Articles on handling integer and FP exceptions?

WSinc · ‎09-17-2007

Hi;

I know they are out there, but doing a search does not reveal where.

I have Visual Studio 2005, but everything comes up Visual Basic - nothing about Fortran. And within Fortran, there is nothing about exception handling when I do a search.

The following code fragment:

I=1

Do while (.true.)

I = I*3

End Do

should generate an overflow exception, but how do I trap that?

It just runs forever without any interrupts.

Thanks; Bill S.

Steven_L_Intel1 · ‎09-17-2007

Integer overflow detection requires different code to be generated to detect the overflow and currently Intel Fortran does not support this. Please submit a feature request for this to Intel Premier Support - while it's on our "wish list", it's not a simple thing and the more customers who ask for it, the more likely it is to get done.

For floating-point, there is a chapter on error handling in the on-disk documentation which covers various approaches.

jimdempseyatthecove · ‎09-18-2007

Generally one cannot enable trap on all integer overflows. The reason for this is many sections of the code generated produce integer overflow by design. Management of internal array descriptors, in particular base and stride will naturally produce an integer overflow. Example

real :: A(100)
integer :: I
do I=1,100
A(I) = 0.0
end do

The code generated to manage that loop will typically load -Base address, in this case A is A(1:100) therefore -Base is -1, then add the indexing variable I. In this example you will always see an overflow. This overflow is perfectly valid and expected. Therefor a trap on all integer overflows would be unworkable.

Integer overflows could be added as an additionalruntime check by use of additional code inserted by the compiler. At first glance you might assume that this would be just what you want. My educated guess is if you enabled this option for an entire application, or potentially just one subroutine/function that you would find many unintended traps.

IMHO a better route would be for you to insert code, which is often called sanity checks, or ASSERTs, that are conditionally compiled into your code. Release mode might not perform the ASSERT while various Debug configurations may include the ASSERT.

My preference is to use the Fortran PreProcessor. In this case, I would also add a C helper routine to test for integer overflow.

#ifdef _DEBUG
#define ASSERT(c,x) if(.not. (c)) call assert_error(x)
#define ASSERT_NO_OVERFLOW(x) if(IflagsOverflow()) call assert_error(x)
#else
#define ASSERT(c,x) if(.not. (c))
#define ASSERT_NO_OVERFLOW(x)
#endif

...
I=1
do while(.true.)
ASSERT((I .GT. 0),"Invalid index in ABC.F90")
I=I*3
ASSERT_NO_OVERFLOW("Overflow #1 in ABC.F90")
end do

Jim Dempsey

WSinc · ‎09-18-2007

Hi Jim;

Thanks for your response. I tried running your example, but the compiler doesn't like the syntax of the preprocessor statements. This is what I get:

Warning1 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F902
Warning2 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F903
Warning3 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F904
Warning4 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F905
Warning5 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F906
Warning6 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F907
Warning7 Warning: Bad # preprocessor lineC:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F908
Error8 Error: Syntax error, found END-OF-STATEMENT when expecting one of: => = . ( %C:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F9013
Error9 Error: Syntax error, found END-OF-STATEMENT when expecting one of: => = . ( %C:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F9015
Error10Compilation Aborted (code 1)C:Documents and SettingsWilliamMy DocumentsVisual Studio 2005ProjectsConsole5Console5int_trap.F901

Should I also insert something else?

Thanks; Bill S.

jimdempseyatthecove · ‎09-18-2007

Bill,

The preprocessor (FPP) is disabled by default in IVF. In the Project settings under Fortran you will find a property for Preprocessor. Open that and select Preprocess File as Yes. Also, make sure your preprocessor lines (#) start at col 1. My code:

program assert
  implicit none  integer :: I
  logical :: IflagsOverflow
#ifdef _DEBUG#define ASSERT(c,x) if(.not. (c)) call assert_error(x)#define ASSERT_NO_OVERFLOW(x) if(IflagsOverflow()) call assert_error(x)#else
#define ASSERT(c,x) if(.not. (c))#define ASSERT_NO_OVERFLOW(x) #endif
  I=1
  do while(.true.)
    ASSERT((I .GT. 0),"Invalid index in ABC.F90")
    I=I*3
    ASSERT_NO_OVERFLOW("Overflow #1 in ABC.F90")
  end doend program assert
logical function IflagsOverflow()
  IflagsOverflow = .false.end function IflagsOverflow
subroutine assert_error(x)
  character(*) :: x
  write(*,*) x
  stop
end subroutine assert_error
The IflagsOverflow is a dummy function here.
Please substitute with valid C function.
When testing the above, the Invalid index...
will trap. The Overflow will trap only after
you supply the proper C function.
Jim Dempsey

Steven_L_Intel1 · ‎09-18-2007

On the Intel architectures, integer overflow is something that requires an extra instruction to detect - it is not a processor-raised exception as floating overflow is. It is certainly possible for a compiler to generate the proper code to test for integer overflow where appropriate and to omit it where not needed - CVF did this. For the Intel compilers, there was not the code generator infrastructure to do it when we first released. This is one of the things we're looking at for a future release. If you want it, be sure to let us know with a formal feature request submission to support.

WSinc · ‎09-18-2007

Hi;

I played around with this a little bit, and found that testing the sign bit of the index does not generate an error in all cases. For example, you can multiply two integers together that would normallygenerate anoverflow, but the result can still be positive.

So testing the RESULT does not always catch the error.

If the Intel processor does not detect this, what other recourse do we have?

jimdempseyatthecove · ‎09-18-2007

Steve,

If you do talk to the developers regarding integer overflow code you might consider the following (I already suggested this some time ago).

SETNO eax; eax=1=No Overflow, eax=0=Overflow
DIV eax,eax; Div 0 only if was Overflow

This produces an integer divide by 0 if Overflow were set. Very little overhead is involved with using this coding sequence. For processors without SETcc a little different technique will be involved.

Note, if Div 0 occures after above sequence then assume trap is for Integer Overflow.

Jim Dempsey

jimdempseyatthecove · ‎09-18-2007

The C helper function is not testing the Result (product in sample case).

Instead the C helper function is called (without modifying the processor FLAGS register) and the FLAGS register is consulted for the Overflow condition.

Jim