Compiler Fails to Identify Division by Zero

[chauvjo]

I am using ifort (IFORT) 13.1.1 20130313 under Red Hat Enterprise Linux 5.3.  The target program was compiled using the following options:

-O2 -fpe0 -extend-source 132 -save -zero -traceback -diag-disable 8290,8291

The target program is generating a "forrtl: error (65): floating invalid" error message. We have traced the problem to a division by zero error on a line of code above the line number provided by the compiler traceback.  Why is the compiler not flagging this error as a divisoin by zero error and stopping on the correct line?  Our understanding is the -fpe0 option should behave as follows: Underflow gives 0.0; trap on other IEEE exceptions.

The compiler should have generate a "error (73): Floating divide by zero" message.

Here is the source that triggered the error and the values:

A = B / C  where

B=   0.00000000000000000000    C=0.00000000000000000000

Thanks,

John

[Steven_L_Intel1]

Interesting. I'll take a closer look at this tomorrow.

[Casey]

I wrote a small test program and note that when calculating A = B/C (where C = 0.0) if B is 0 the runtime error is (65): floating invalid, but if B is not 0, then error (73): floating divide by zero is reported.   The traceback for my simple example reports the correct line in my case.  You may be getting a later line due to optimizations made by the compiler changing exactly where that 0/0 is evaluated.  

Edit: The document at http://software.intel.com/file/18075/ (Intel Fortran Floating-point Operations) defines the Divide-by-zero exception as having a "finite non-zero dividend" and specifically defines division of zeros as an invalid operation, which implies the observed behavior is correct.  Without -fpe0 the (<>0)/0 case returns +/-Infinity and the 0/0 case returns NaN, which also agrees with the document.

[chauvjo]

Casey..Thanks for the information. Just a comment.  The purpose of a compiler error message is to help the developer identify and fix a problem. In this case, it would be much more informative to flag this error as division by zero than floating invalid which can have many different causes. The division by zero error message immediately gives you an important piece of information. The line of code contains division. In our case, the compiler stopped on a line which contained no division. A division by zero error message would have told us the compiler had stopped on the incorrect line and save alot of time.

[Casey]

I agree that the divide by zero exception would be more intuitive for debugging (is debugging ever intuitive though?) this case, but I don't think that will change since in addition to intel's docs, the fortran standard (ISO/IEC 1539-1:2010 draft) defines the divide by zero fp exception as having non-zero numerators.

[Ron_Green]

Casey,

One minor comment:  in your compiler options you'll probably want to add -debug <level> option.  This puts debug symbol information into the code so the traceback is human readable.  And yes, you can add debug info to optimized code, you need not be at O0 for debug symbols to be added.  I tend to use -debug full or -debug minimal.

ron

[Casey]

Ronald,

Thanks for the clarification on that point as I was not clear in my thoughts.  What I was trying to suggest to the OP is that higher optimization levels might have caused the traceback to report a line number after the the line in source where 0/0 occurred (since the compiler is not producing 1:1 source:assembly when optimizing).

For example, the code [fortran]B = 0.0

C = 0.0

A = B/C

print *,A[/fortran]

will produce a traceback (-fpe0) starting at line 3 with -O0 but at line 4 with -O3.