Hi: I've been trying to improve the robustness of our code. To that end, I enabled (maybe unmasked is the right word) floating point exceptions. However, when optimization is turned on, the code seems to generate spurious exceptions. Here is the simplified routine:
program example real :: a(3), b(3), c(3) integer :: d(3) a = (/ 1., 2., 3. /) b = (/ 0., 0., 0. /) c = (/ 1., 1., 1. /) call subr ( a, b, c, d ) end program example subroutine subr ( a, b, c, d ) real, intent(in) :: a(3), b(3), c(3) integer, intent(out) :: d(3) d = int( ( a - b ) / c ) end subroutine subr
If I compile this with "ifort -fpe0 example.f90" I get:
$ ./a.out forrtl: error (65): floating invalid ... traceback ...
The nub seems to be that the compiler generates "divps" for the division in subr() but it has only loaded two values into the low order floats in the XMM registers; the high order floats are zero. This leads to division of 0 by 0 (i.e. NaN). But, the high order XMM floats aren't saved so the calculation ultimately produces the correct answer.
This happens both with version 13.1.3 20130607 on linux and 18.104.22.168 Build 20140422 on windows.