Compiler Bug in 14.0 for OSX

[Richard_Gordon]

Dear all,

I was running a routine test program that failed. I have boiled it down to this simple example:

module tmpmod
  implicit none
contains
  function eye(n) result(mat)
  implicit none
  integer, intent(in) :: n
  real(8), dimension(n,n) :: mat
  ! local
  integer :: i

  mat = 0d0
  do i = 1,n
    mat(i,i) = 1d0
  end do

end function eye
end module tmpmod

program main
  use tmpmod
  implicit none
  real(8) :: B(2,2)

  B = eye(2)

  print*,'B',B

end program

When compiled with "ifort -O3 -openmp -g compilerbug.f90" the output is 

B 0.000000000000000E+000 0.000000000000000E+000 0.000000000000000E+000
0.000000000000000E+000

which is wrong. Dropping -O3 or -openmp or -g produces the correct output:

B 1.00000000000000 0.000000000000000E+000 0.000000000000000E+000
1.00000000000000

[Richard_Gordon]

I should add that the correct output is produced in version 13.0.3 and 13.0.0.

[Sait_U_]

I just spend half a day tracking down a bug in a very large code of mine and it ended up being in a

simple loop where a summation was done for a 1-d array indexed by the loop index, e.g.

                 a(i) = a(i) + ......

just replacing a(i) with a dummy variable ax gives the correct answer. This is with 14.0

and using -xHost and -O3.

[Steven_L_Intel1]

Richard, thanks for the example. I can reproduce the problem and will escalate it to development.

Sait, please show us a test case as Richard did.

[Steven_L_Intel1]

Richard, your issue is escalated as ID DPD200248150. I will update this thread with any news. I was able to reproduce the problem in compiler versions 13.0 and 13.1, but not 12.1.

[Richard_Gordon]

Thank you very much. I am surprised 13.0 reproduces the result as it didn't for me (versions 13.0.0 and 13.0.3).

[Sait_U_]

I am sorry but I cannot reproduce the error outside of my code as a test case. I will keep checking to see if updates solve the issue if some other bug is related to it. The code is very large and is not easliy transportable.

[Sait_U_]

I realized something more amuzing. The section of the code that is giving the error is:

==============================================================

            ecoul(inuc) = 0.0_wp
            ecx = 0.0_wp
            If(icoul /= 0) Then
               Do ix = 1, ncolx
                  Do iy = 1, ncoly
                     Do iz = 1, ncolz
                        ecoul(inuc) = ecoul(inuc) + 0.5_wp * wx(ix) * wy(iy) * wz(iz) * wcoul(ix, iy, iz) * rho(ix, iy, iz, 2)
                        ecx = ecx + 0.5_wp * wx(ix) * wy(iy) * wz(iz) * wcoul(ix, iy, iz) * rho(ix, iy, iz, 2)
                     End Do
                  End Do
               End Do
!               ecoul(inuc) = ecx
               write(*,*) inuc, ecoul(inuc), ecx
            End If
============================================================

where "inuc" is a loop index  far above this section. As you see ecoul(inuc) and ecx calculate exactly the same thing (I actually duplicated the same line and changed it). The printout from the loop is:

           1   2.47281415402703        9.89125661610727    
           2   2.47281415404400        9.89125661617510    

BUT HERE IS THE AMAZING THING, ENUC(INUC)/ECX = 4 EXACTLY!

[Sait_U_]

Bug still present in 14.0.1.......O3 gives wrong answer, O2 gives correct with the exact ratio correct//wrong=4.

[Sait_U_]

OK....another data point: reordering the ix, iy, iz loops as iz, iy, ix (namely ix the inner loop) gives correct answer with O3. In the original order the vect/opt report says that it is permuting the loop and vectorizing. So, something  very subtle is going on with the optimizer.

[Steven_L_Intel1]

Sait, we will need a test case to investigate your problem. Otherwise, you have to just keep trying to see if it got fixed due to a different report.