The current Intel Fortran compiler for Linux (12.1.4.319 Build 20120410) exhibits an optimizer bug on the following program, which is a simplified version of the one posted by mira.sulc (inconsistent results with -O2 as compared to -O1).
[fortran]module parameters INTEGER :: ND, NG end module ! PROGRAM gdr USE parameters REAL, ALLOCATABLE :: SS(:, :) ND = 2 NG = 4 ALLOCATE(SS(NG, NG)) CALL compute_H(ND) DEALLOCATE(SS) CONTAINS SUBROUTINE compute_H(N) INTEGER, INTENT(IN) :: N REAL :: H(1:N, 1:N), v3(1:N, 1:N, 1:N) INTEGER :: l, k v3(1, 1, 1) = 1.1 v3(2, 2, 1) = 2.1 v3(1, 1, 2) = 1.2 v3(2, 2, 2) = 2.2 DO k = 1, N DO l = 1, N H(l, k) = v3(l, l, k) END DO END DO WRITE(*, '(1P,2(2E10.1,/))') H RETURN END SUBROUTINE END PROGRAM [/fortran] Compiled with -O0 or -O1, it gives (correctly)
[bash] 1.1E+00 2.1E+00 1.2E+00 2.2E+00 [/bash] Compiled with -O2 or -O3, it gives the incorrect output
[bash] 1.1E+00 1.7E-43 1.2E+00 9.0E-44 [/bash] The values in the second column are taken from uninitialized ("undefined") memory, and may vary from run to run.
Curiously (at least to people not familiar with optimizer bugs), the bug goes away if
(i) the declarations in the module are moved to the program itself, or
(ii) if the declarations and statements containing the irrelevant array SS are removed, or
(iii) the DO K loop is removed and array assignment, H(L,1:N) = V3(L,L,1:N) is used instead.
