- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Example output:
$ ifort -xCORE-AVX2 -O1 modulobug.f90 -o modulobug
$ ./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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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)
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Kevin D.,
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Ok, I see that now. Thank you for clarifying.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page