I just found a compiler bug when using Fortran 2003 feature
associate in the scope of an ACC kernel.
Here is a very simple example for demonstrating this issue:
module mpoint type point real :: x, y, z real :: tmp end type point end module mpoint program main use mpoint implicit none integer, parameter :: n = 10 real, allocatable :: array(:) !-------------------------------- allocate(array(n)) array(:) = 1.0 call vecadd if(abs(array(2) - 9.0)>0.01) then write(*,*) 'GPU result is wrong!' else write(*,*) 'Test passed!' end if contains subroutine vecadd() integer :: i type(point) :: A associate( x => A%x, y => A%y, z => A%z, tmp => A%tmp) !$acc parallel loop do i = 1, n x = i y = i + 1 z = i + 2 tmp = x + y + z array(i) = tmp enddo !!$acc parallel loop !do i = 1, n ! A%x = i ! A%y = i + 1 ! A%z = i + 2 ! A%tmp = A%x + A%y + A%z ! array(i) = A%tmp !enddo end associate end subroutine vecadd end program main
nvfortran -acc -Minfo, it will crash at runtime:
Failing in Thread:1 call to cuStreamSynchronize returned error 700: Illegal address during kernel execution
However, if I comment out the loop and access the derived type component with a
% sign (as shown above in the commented out part), it will work.
In my understanding, the associate statement can be implemented by the compiler as simple as a text replacement before any IR being generated. Based on the experiment here, clearly
nvfortran has something more complicated.