Possible compiler bug

Hello,

I’ve been testing PGI Fortran on our electronic structure code (elk.sourceforge.net) and I may have found a compiler bug.

I’m using
pgf90 17.5-0 64-bit target on x86-64 Linux -tp haswell
on our cluster.

Here’s the smallest code I can make which still gives the bug:

program test
implicit none
integer, parameter :: lmax=1
integer lmmax
complex(8), allocatable :: d(:,:)

lmmax=(lmax+1)**2
allocate(d(lmmax,lmmax))

call ylmrot(lmax,lmmax,d)

print *,d

end program

subroutine ylmrot(lmax,ld,d)
implicit none
! arguments
integer, intent(in) :: lmax,ld
complex(8), intent(out) :: d(ld,*)
! local variables
integer lmmax,l,m1,m2,lm1,lm2
! allocatable arrays
real(8), allocatable :: dy(:,:)
lmmax=(lmax+1)**2
allocate(dy(lmmax,lmmax))
lm1=0
do l=0,lmax
  do m1=-l,l
    lm1=lm1+1
    lm2=l**2
    do m2=-l,l
      lm2=lm2+1
      d(lm1,lm2)=cmplx(0.d0,1.d0,8)
    end do
  end do
end do
deallocate(dy)
return
end subroutine

Compiling with

pgf90 -O2 test.f90

results in

Segmentation fault

The problem goes away if you compile with -O1.

Intel Fortran and gfortran work fine with all optimisation levels.

It appears that pgf90 is optimising the evaluation of variables lm1 and lm2 incorrectly. These indices then point to a memory address outside the array d.

If you put in a print statement somewhere in the l, m1, m2 loops, then the problem disappears.

Kay.

Hi Kay,

I’m seeing the same behavior on 17.5 and the newer versions. I’ve opened a ticket to track the issue. I’ll keep you posted when we’ve resolved the issue.

Thanks for bringing it to our attention.

Fixed with PGI 19.7 and above.