Hello
When upgrading from ifort to ifx 2025.1.0 recently, We ran into a strange issue when compiling a specific piece of code with optimizations enabled. Running on Rocky Linux 9.5 with Intel Xeon Gold 6248 CPU. Below is a minimal working example:
program test
real(kind=8) :: A(13)
real(kind=8) :: B(13)
integer :: i
open(8,file='table.txt')
DO i=1,13
read (8,*) B(i)
A(i) = B(i)
ENDDO
print *, "compare", A(1), B(1)
end program test
'table.txt' is a text file containing one number per line, and is longer than 13 elements. An example is attached.
When compiling this small program with -O2 or -03 optimizations, the assignment A(i) = B(i) is not performed correctly, and A contains all zeroes, i.e. the program prints
compare 0.000000000000000E+000 20.0000000000000
When compiling with -O1 or -O0, behavior is normal, and the program prints
compare 20.0000000000000 20.0000000000000.
We have the same issue with ifx 2024.0.0, whereas the program works correctly in ifort or gfortran.
We inspected the assembly generated by ifx, and found that the instructions corresponding to the assignment A(i) = B(i) are all moved to the beginning of the loop and done in vectorized form. The assignments are therefore done before the file is read, and A remains all zeroes. It seems that the compiler is simply ignoring the fact that B is being written to in the read operation.
Small changes to the code can also affect whether this incorrect optimization is being done or not. For example, when looping 12 or fewer iterations (instead of 13 or more), or when adding print *, i inside the loop, the program works as intended again. When we add print *, "compare", A(i), B(i) inside the loop, after the assignment, the code still works incorrectly with ifx 2025.0.4, but correctly in 2024.0.0.
It is easy to fix the issue in this case, by moving the assignments after the loop for example, but there are many other places in our code with similar structures, where a bug like this might go unnoticed. We would therefore like to know what the cause of the problem is, and whether we could solve it on the compiler level without falling back to -O1 optimizations.
Thanks in advance!
