- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page