-Compiler failed to translate accelerator region (see -Minfo messages): Unexpected Data Type in Deep Copy

I am attempting to convert a CPU code to GPU. It is written in FORTRAN and uses alot of derived types (mostly nested) and pointers to the derived types.
When I try to copy the derived type’s pointer data to the Device using OpenACC directives, I get the following error.
-Compiler failed to translate accelerator region (see -Minfo messages): Unexpected Data Type in Deep Copy

I have reproduced a small toy program where I encounter the same error. I am new to GPU programming and maybe making a mistake. I read posts about pointer data transfer but couldn’t resolve the error.
The toy program has three modules which are given as follows:

Module # 01
module Ptr_HEADER

type :: t_mol_data
integer(8) :: id = 0
character(len=30) :: name = “”
logical :: has_mp = .false.
real(8) :: density = 0.0
integer(8) :: n_atoms = 0
real(8), allocatable :: density_atom_gram(:)
integer(8), allocatable :: atom_identifiers(:)

contains
procedure :: copy_from => copy_molecule_from
procedure :: alloc => allocate_molecule
end type t_mol_data

type :: t_compound_container
type(t_mol_data), allocatable :: constituent_material(:)
contains
procedure :: get => get_molecule
end type t_compound_container

contains

subroutine copy_molecule_from(this, m)
implicit none
class(t_mol_data) :: this
type(t_mol_data) :: m
integer :: i

this % has_mp = m % has_mp
this % name = m % name
this % n_atoms = m % n_atoms
call this % alloc()
this % density = m % density
do i = 1, 3
this % atom_identifiers(i) = m % atom_identifiers(i)
this % density_atom_gram(i) = m % density_atom_gram(i)
end do

end subroutine copy_molecule_from

subroutine get_molecule(this, id, m)
implicit none
class(t_compound_container), target :: this
integer :: id
type(t_mol_data), pointer :: m

m => this % constituent_material(id)

end subroutine get_molecule

subroutine allocate_molecule(this)
implicit none
class(t_mol_data) :: this
integer(8) :: s
integer(8) :: i

s = 3
allocate(this % atom_identifiers(1:s))
allocate(this % density_atom_gram(1:s))
do i = 1, s
this % atom_identifiers(i) = i
this % density_atom_gram(i) = 0.0
end do

end subroutine allocate_molecule

end module Ptr_HEADER

Module # 02
module Ptr_GLOBAL
use Ptr_HEADER

type(t_compound_container), target, save :: c_mat

end module Ptr_GLOBAL

Module # 03
Module Ptr_INITALIZE
use Ptr_HEADER
use Ptr_GLOBAL

contains
subroutine Initializer(SIZER)
implicit none
integer(8) :: i,j,k, SIZER
type(t_mol_data), pointer :: pm

allocate(c_mat%constituent_material(SIZER))

do i=1,SIZER
pm => c_mat % constituent_material(i)
pm%id = 1
pm%density = 6.6+ real(i)
pm%n_atoms = i
allocate(pm%density_atom_gram(3))
allocate(pm%atom_identifiers(3))
end do
print*, ‘All the initialization is successful’
End subroutine Initializer

end Module Ptr_INITALIZE

Program
Program Ptr_EXECUTOR
use Ptr_HEADER
use Ptr_GLOBAL
use Ptr_INITALIZE
use openacc

implicit none
integer(8)   :: i, my_size = 6
real(8)      :: temp
type(t_mol_data), pointer :: pm

call Initializer(my_size)
call c_mat % get(1, pm)

temp = 0.0
!$acc enter data create(pm)
!$acc data copy(pm%n_atoms) 
!$acc parallel loop reduction(+: temp)
do i=1, my_size
   temp = temp + pm % n_atoms
end do
!$acc end parallel loop
!$acc end data
!$acc exit data delete(pm)

print*, 'Normal Ending of the executor program ...'

End Program Ptr_EXECUTOR

The HPC SDK version is 22.1 and I am using the deepcopy option while compiling.
Any help would be appreciated.

Dear Khokhar,

I checked your code and found that you are using character(len=30) type of variables in your Ptr_HEADER module. I think it is not allowed to use such kind of data type on device, hence the error. After I removed given lines, the code managed to compile and run without any problem. The logs are below:

siarhei@: nvfortran -fast -acc -gpu=cc86,deepcopy -cpp -Mlarge_arrays -Minfo -o=Ptr_tester Ptr_MATERIAL_H.f90 Ptr_GLOBAL.f90 Ptr_INITALIZE.f90 Ptr_executor.f90 
Ptr_MATERIAL_H.f90:
copy_material_from:
     67, Loop not fused: different loop trip count
         Loop not fused: no successor loop
         Loop not vectorized: unprofitable for target
     72, Loop unrolled 3 times (completely unrolled)
     76, Loop not fused: no successor loop
         Loop not vectorized: data dependency
allocate_material:
    126, Loop not fused: different loop trip count
         Loop not vectorized: unprofitable for target
    127, Loop not fused: function call before adjacent loop
         Loop not vectorized: unprofitable for target
    137, Loop unrolled 3 times (completely unrolled)
Ptr_GLOBAL.f90:
INITIALIZE.f90:
initializer:
     12, Loop not vectorized/parallelized: contains structure move
         Loop unrolled 4 times
     13, Loop not vectorized/parallelized: contains structure move
         Loop unrolled 4 times
     15, Loop not vectorized/parallelized: contains structure move
     26, Loop unrolled 4 times (completely unrolled)
     28, Loop unrolled 2 times (completely unrolled)
Ptr_executor.f90:
executor:
     15, Generating enter data create(pm)
     16, Generating copy(pm%mgxs) [if not already present]
     17, Generating NVIDIA GPU code
         18, !$acc loop gang, vector(128) ! blockidx%x threadidx%x
             Generating reduction(+:beta0)
     17, Generating implicit copy(beta0,pm) [if not already present]
     18, Loop not fused: no successor loop
         Loop not vectorized: unprofitable for target
     23, Generating exit data delete(pm)
siarhei@: ./Ptr_tester
 All the initialization is successful
 Normal Ending of the executor program ...
Segmentation fault
siarhei@:

My system is: Windows 11 Pro, WSL 2, Ubuntu 20.04.3, HPC SDK 22.1, nVidia RTX 3090.

Not sure about the reason of Segmentation fault, though, but it appears at the very end of the program runtime and does not break any operation.

I understand that sometimes it is crucial to have character variables but maybe you could work around this issue by using numerical data types instead and encoding/decoding them on the host side.

Best Regards,
Siarhei

1 Like

Aaah, my bad. Thank you. Sometimes its such a small mistake that is easily overlooked.
Thanks alot.
I will look into resolving the segmentation fault.

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.