Incorrect message when fpe0 is turned on

[Du__FJ]

Sample code:

program main
IMPLICIT NONE
write(*,*) 1D-300*1D-300
write(*,*) 0D0/0D0
end program main

Compile it with

ifort -debug -traceback -check all -fpe0 filename.f90

I get the following output

  0.000000000000000E+000
forrtl: error (74): floating underflow
Image              PC                Routine            Line        Source
a.out              000000010CA6944A  Unknown               Unknown  Unknown
libsystem_platfor  00007FFF6767CF5A  Unknown               Unknown  Unknown
a.out              000000010CA41A73  _MAIN__                     4  filename.f90
a.out              000000010CA4196E  Unknown               Unknown  Unknown
Abort trap: 6

The line "forrtl: error (74): floating underflow" seems a bit puzzling.  I was expecting "forrtl: error (65): floating invalid" to be the error message, since the underflow should not make the program abort.  Without the line "write(*,*) 0D0/0D0" and compile with the same options the code can run without an error.

ifort version 18.0.0 on MacOS 10.13.1

[Steve_Lionel]

You demonstrated that the floating underflow did NOT make the program abort. The abort happened on the zerodivide. I am puzzled, though, that the message says "floating underflow". When I try this on Windows (I don't have Linux), I get "floating invalid" for the diagnostic instead.

[jimdempseyatthecove]

From developer manual:

Because the exception flags are “sticky,” they provide a cumulative record of the exceptions that have occurred
since they were last cleared. A programmer can thus mask all exceptions, run a calculation, and then inspect the
exception flags to see if any exceptions were detected during the calculation.

The underflow would have been set at (through to) the point of the Divide by Zero (if other code did not clear it). On one of the builds, apparently the first error bit may have displayed. IOW The error flag was not .AND.'d with the (.NOT. exception mask).

At least that is one explanation.

Jim Dempsey