Compiler Bug in 14.0 for OSX

Compiler Bug in 14.0 for OSX

Portrait de 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
  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)


end program

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

B 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

11 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.
Portrait de Richard Gordon

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

Portrait de 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.

Portrait de Steve Lionel (Intel)

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.

Portrait de Steve Lionel (Intel)

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.

Portrait de 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).

Portrait de 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.

Portrait de 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    


Portrait de Sait U.

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

Portrait de 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.

Portrait de Steve Lionel (Intel)

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.


Connectez-vous pour laisser un commentaire.