IFORT 11.1 bug (?) -O3 kills loops (LINUX and WINDOWS)

[ghfecher]

Using -O3 causes that the following loop does not work

do j=1,5
do i=1,5
aext(i,j) = amat(ij(i),ij(j))
end do
end do

however, if using

aext(1:5,1:5) = 0.d0
do j=1,5
do i=1,5
aext(i,j) = amat(ij(i),ij(j))
end do
end do

it works but not in the following way

aext(1:5,1:5) = 0.d0
...
some more statements
....
do j=1,5
do i=1,5
aext(i,j) = amat(ij(i),ij(j))
end do
end do

The problem appears with Versions 11.1.078 (Linux) as well as 11.1.056 (Windows)
The code had no such problems with any 11.0 or older, down to very very old Versions (last millenium).

The following is a part of code from a very large project that demonstrates the problem.
Compiler directives for Windows were set in a simalar way.
(it is not a direct issue of -xHost, as tested on XEONs, Quadcores and Laptops)

The code is not the most modern one but it should work.
This is an servere issue because much scientific code contains, for sure, similar code.


program matrottest
implicit none
!
! it depends in subroutine inva where aext is set to 0 !!!!
! see below line 60-62
! Linux: -FR -w -mp1 -pc80 -xHost -O3 -ip -m64 -traceback
!
real(8) cb(3,3),cb2(3,3), detcb
integer ierr, label
logical equal

cb(1,1)=1.d0
cb(1,2)=1.d0
cb(1,3)=1.d0

cb(2,1)=1.d0
cb(2,2)=2.d0
cb(2,3)=1.d0

cb(3,1)=1.d0
cb(3,2)=1.d0
cb(3,3)=2.d0

! detcb should be 1.0

call inva(cb,cb2,detcb, ierr)

if(ierr.eq.1)then
write(6,*)'warning !!! det(cb) =',detcb
else
write(6,*)'correct: det(cb) =',detcb
end if

end

subroutine inva(a,ainv,deta,ierr)
implicit none
! este programa calcula la inversa de una matriz de 3*3

real(8) a(3,3), ainv(3,3)
real(8) aext(5,5), adja(3,3)
integer ij(5)
real(8) deta, qq
integer ierr, j, i

ierr = 0
ainv(1:3,1:3) = 0.d0
deta = 0.0
!
adja(1:3,1:3) = 0.d0
aext(1:5,1:5) = 0.d0
ij(1:5) = 0
!
ij(1)=1
ij(2)=2
ij(3)=3
ij(4)=1
ij(5)=2
!
! if you set aext here (line 62) to zero then it works
! if you comment the next line (62) it fails ????? (note line 51 is doing already the same like 62)
aext(1:5,1:5) = 0.d0
do j=1,5
do i=1,5
aext(i,j)=a(ij(i),ij(j))
end do
end do
! calculo la adjunta de a
do j=1,3
do i=1,3
adja(i,j)=aext(i+1,j+1)*aext(i+2,j+2)-aext(i+1,j+2)*aext(i+2,j+1)
end do
end do
! calculo el determinante de a
do i=1,3
deta=deta + a(1,i)*adja(1,i)
end do

qq=abs(deta)
if(qq.lt.0.000001)then
ierr=1
return
else
! calculo la inversa de a :
do j=1,3
do i=1,3
ainv(i,j)=adja(j,i)/deta
end do
end do
end if

return
end subroutine

[mecej4]

The bug disappears if, instead of keeping line-62 active, we add, just before the comment "! calculo la adjunta de a", a WRITE statement:

[fortran]      write(*,77)((a(i,j),j=1,3),i=1,3)
   77 format(1x,3F12.4)
[/fortran]

That makes me suspect that this is yet another instance of a known bug in the Intel Fortran optimizer .

[jimdempseyatthecove]

As an experiment try adding recursive to...

recursive subroutine inva(a,ainv,deta,ierr)

thencomment out

!aext(1:5,1:5) = 0.d0

What this will do is place the array descriptor on the stack, as opposed to being SAVE.

See what happens. Your code should work either way, but this would take a different compiler decision path.

Jim Dempsey

[ghfecher]

Thanks for the reply,
I can also put the write statement directly after the loops: result is correct
or put a write statement for the 5x5 array after the loops and have a correct result.
If I put it at the end of the subroutine the problem is back.

I think its not a good idea to "remove a bug" by putting in any junk-code (some if's doing nothing seemingly remove the trouble, too) that prevents the optimizer to do foolish things, what I gave was just one possibility how to confuse it or not, the bug stays a bug.

Its interesting to note that, depending where one puts in some useless code the first double loop
may do a correct job, but then one of the following loops crashes.

Ciao
Lets see what future brings.

[Kevin_D_Intel]

Thank you for the convenient reproducer. This looks to be a different root-cause than the issue mecej4 referred to because the fix for that earlier issue does not address the incorrect results in this case.

For cases where the identified code modification work-around may not be feasible, one can (with some potential impact on performance) compile the test case cited in this thread using O2 to obtain correct results.

I will report this issue to Development (provide an internal tracking id below) and update this post as I learn more.

(Internal tracking id: DPD200157071)

(Resolution Update on 08/31/2010): This defect is fixed in the Intel Fortran Compiler Professional Edition 11.1 Update 7 (11.1.073 - Linux, 11.1.067 - Windows).

[Kevin_D_Intel]

I confirmed this defect (at -O3) is fixed in our internal 11.1 development compiler. I expect the fix to be in the next 11.1 Update 7 tentatively scheduled for later this month.

[Kevin_D_Intel]

The 11.1 Update 7 (11.1.073 - Linux, 11.1.067 - Windows) containing this fix is now available from the Intel Registration Center: https://registrationcenter.intel.com