unexpected result about an array when ifort is used with -ipo option (possibly a bug)

[Norio_Takemoto]

Hello gurus, experts, and fellows,

I encountered unexpected results about the values of array elements when the following simple source codes were compiled by Intel ifort. As far as I have tried, I get wrong results when the "-ipo" option is set.

Now, here is the code written in two files, main.f90 and moduleA.f90.

main.f90:

[fortran]PROGRAM norio_20110920_chkifort3
  USE modA
  IMPLICIT NONE

  INTEGER                              :: m2,m1, i2,i1
  COMPLEX, DIMENSION(:,:), ALLOCATABLE :: mat

  ! Reading the array dimensions from standard input.
  read(*,*) m1
  read(*,*) m2 
  
  allocate(mat(m1,m2))

  ! Assign values to the array elements and print them out.
  do i2=1,m2
     call set_vec(i2,mat(:,i2))
  end do
  write(*,*) '# i1  i2  RE[mat] IM[mat] (main I)'
  do i1=1,m1
     do i2=1,m2
        write(*,'(1X,2I10,2E25.15)') i1, i2,  mat(i1,i2)
     end do
     write(*,'(1X)') 
  end do

  ! Repeat the same thing again.
  do i2=1,m2
     call set_vec(i2,mat(:,i2))
  end do
  write(*,*) '# i1  i2  RE[mat] IM[mat] (main II)'
  do i1=1,m1
     do i2=1,m2
        write(*,'(1X,2I10,2E25.15)') i1, i2,  mat(i1,i2)
     end do
     write(*,'(1X)') 
  end do

  deallocate(mat)
  
END PROGRAM norio_20110920_chkifort3
[/fortran]

moduleA.f90:

[fortran]MODULE modA
  IMPLICIT NONE
  PRIVATE

  PUBLIC set_vec

CONTAINS

  SUBROUTINE set_vec(iparam,vec) 
    INTEGER,               INTENT(IN)  :: iparam
    COMPLEX, DIMENSION(:), INTENT(OUT) :: vec
    INTEGER                            :: j1
    COMPLEX, PARAMETER                 :: I_IMG = (0.0d0, 1.0d0)

    forall(j1=1:size(vec))
       vec(j1) = -0.7d0*j1+0.3d0*iparam +I_IMG*(0.7d0*j1-0.3d0*iparam)
    end forall

  END SUBROUTINE set_vec

END MODULE modA
[/fortran]

The program assigns values to an array "mat" by using "set_val" subroutine in "modA" module, and outputs the values. This procedure is exactly repeated once. Therefore, with m1=3 and m2=2, the output should look like this:

[bash] # i1  i2  RE[mat] IM[mat] (main I)
          1         1   -0.400000005960464E+00    0.400000005960464E+00
          1         2   -0.100000001490116E+00    0.100000001490116E+00

          2         1   -0.110000002384186E+01    0.110000002384186E+01
          2         2   -0.800000011920929E+00    0.800000011920929E+00

          3         1   -0.179999995231628E+01    0.179999995231628E+01
          3         2   -0.150000000000000E+01    0.150000000000000E+01

 # i1  i2  RE[mat] IM[mat] (main II)
          1         1   -0.400000005960464E+00    0.400000005960464E+00
          1         2   -0.100000001490116E+00    0.100000001490116E+00

          2         1   -0.110000002384186E+01    0.110000002384186E+01
          2         2   -0.800000011920929E+00    0.800000011920929E+00

          3         1   -0.179999995231628E+01    0.179999995231628E+01
          3         2   -0.150000000000000E+01    0.150000000000000E+01

[/bash]

The "(main I)" and "(main II)" blocks should be the same. I obtained this result with the compiler options, "-stand f03 -O3 -no-prec-div -xHost".

However, when I use the compiler options, "-stand f03 -ipo -O3 -no-prec-div -xHost", I obtained a strange output as following:

[bash] # i1  i2  RE[mat] IM[mat] (main I)
          1         1   -0.400000005960464E+00    0.400000005960464E+00
          1         2   -0.100000001490116E+00    0.100000001490116E+00

          2         1   -0.110000002384186E+01    0.110000002384186E+01
          2         2   -0.800000011920929E+00    0.800000011920929E+00

          3         1   -0.179999995231628E+01    0.179999995231628E+01
          3         2   -0.150000000000000E+01    0.150000000000000E+01

 # i1  i2  RE[mat] IM[mat] (main II)
          1         1   -0.100000001490116E+00    0.100000001490116E+00
          1         2   -0.100000001490116E+00    0.100000001490116E+00

          2         1   -0.800000011920929E+00    0.800000011920929E+00
          2         2   -0.800000011920929E+00    0.800000011920929E+00

          3         1   -0.179999995231628E+01    0.179999995231628E+01
          3         2   -0.150000000000000E+01    0.150000000000000E+01

[/bash]

The "(main II)" block does not repeat the "(main I)" block.

I think this might be a bug of the compiler, but I would like you to point it out if I am doing something wrong.

The version of ifort I am using is
ifort (IFORT) 12.0.4 20110427
The operating system is
Linux 2.6.34.8-0.2-desktop x86_64
openSUSE 11.3 (x86_64)

If that is actually a bug, I would like to know how I can inform it to the Intel development team and request a fix in the future. I would also like to know if there is a good work around for the moment. If you could provide me with any insights how this is happening, I will be very glad.

Thanks,
Norio

[Kevin_D_Intel · Accepted solution]

Thank you for the convenient reproducer, Norio. Posting to our forum is sufficient for informing us of the issue. It does appear to be an IPO related compiler defect. The program produces expected results with our upcoming update that is tentatively scheduled for release in mid-October.

I do not know exactly what part of your code is affected by the defect at this moment, so I'm unsure whether a source code work around is available or not. That will require some additional triage.

Could you avoid the IPO optimization as a work around for now and plan to upgrade your compiler next month?

[Norio_Takemoto]

Hi Kevin,

thank you for your prompt reply. It is nice that the problem will be fixed in the next update. Yes, I can live without IPO for the moment.

Thanks,
Norio