When MODULO is called with two positive arguments, it should always produce a nonnegative value. However, the following code, when compiled with "-xCORE-AVX2 -O1" using ifort 17.0.2, produces a negative value!
SUBROUTINE modchk(x,n) REAL*4 :: x, z INTEGER*4 :: n z = x*n z = MODULO(z,1.e0) IF (z < 0.e0) THEN PRINT '("MODULO(v,1.e0) is negative! z=",E17.10)', z ELSE PRINT '("MODULO(v,1.e0) is nonnegative, z=",E17.10)', z END IF RETURN END SUBROUTINE modchk PROGRAM drv INTEGER*4 :: n REAL*4 :: x n = 42 x = 2.3809524e0 CALL modchk(x,n) END PROGRAM drv
$ ifort -xCORE-AVX2 -O1 modulobug.f90 -o modulobug
MODULO(v,1.e0) is negative! z=-0.9536743164E-06
Here is some info about my processor and compiler:
$ uname -a
Linux orpheus 4.4.0-53-generic #74-Ubuntu SMP Fri Dec 2 15:59:10 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ ifort -v
ifort version 17.0.2
This is quite a serious problem because it directly violates the MODULO documentation. Many numerical codes (e.g. table based interpolation) use MODULO and do not check the sign of the return value when it is known that the arguments will be positive.
Thank you for the report. I reproduced this with current and new compilers and escalated it to Development. It appears related to FMA optimizations. As noted this only occurs with -xCORE-AVX2 -O1 but not with other lower/higher opt-levels. It can also be avoided with -O1 by adding -no-fma.
(Internal tracking id: DPD200419968)
Thank you for your help. To clarify, this also occurs with "-xCORE-AVX2 -O2" and "-xCORE-AVX2 -O3", but you need to put the driver program and the modchk() routines in separate compilation units. Otherwise, ifort will evaluate all expressions at compile-time, giving the illusion that the bug is not present at those optimization levels.