copy of component structure results in stack overflow

[Pietro_P_]

hi,

i have an allocatable, rank=1 structure containing an allocatable component which is a real*8, rank=3 array, defined as follows:

db=kind(1.0d0) 
type griddata
    real(kind=db), dimension(:,:,:), allocatable :: u
end type
type(griddata), allocatable, dimension(:) :: gd

i allocate two griddata structures:

ngrids=2
allocate(gd(ngrids))

then if i try to copy the components from grid 1 to grid 2, and all of the following versions of the copy result in a stack overflow:

kgf=1
kg=2
! version 1 :
gd(kgf)%u = gd(kg)%u 
! version 2 :
gd(kgf)%u(1:nx(kgf),1:ny(kgf),1:nz(kgf)) = gd(kg)%u(1:nx(kgf),1:ny(kgf),1:nz(kgf))
! version 3 :
gd(kgf)%u(:,:,:) = gd(kg)%u(:,:,:) 

they work only if I hardcode the grid number:  gd(2)%u = gd(1)%u

instead, looping over the three dimensions of the component and performing the copy of the element works just fine:

kgf=1
kg=2
do i
do j
do k
  gd(kgf)%u(i,j,k) = gd(kg)%u(i,j,k)
enddo
enddo
enddo

what is happening?

[andrew_4619]

What will be happening is that in doing versions 1 , 2 and 3 the compiler is choosing to make a temporary copy of of some U data. You don't say what size the U's are allocated as but they must be significant in size I would expect. The compiler makes temporary copies when (for example) it is not sure or can't determine if the array data is contiguous. If this is sensible in this case I am not sure without further study.... 

[andrew_4619]

That said an array that has been allocated should always be contiguous as that is a  requirement from  F2008..... maybe the compiler is being dumb or maybe it is because at compile time is does not know the shape of the different U's - they may be different????

[Pietro_P_]

andrew_4619 wrote:

That said an array that has been allocated should always be contiguous as that is a  requirement from  F2008..... maybe the compiler is being dumb or maybe it is because at compile time is does not know the shape of the different U's - they may be different????

are you saying there is bug in the compiler?

[Steve_Lionel]

Not a bug, but a missed opportunity. This is an aspect that has been gradually improved over the years. I recall that assignments of allocatable components was an area in need of improvement in the past. Which compiler version are you using?

I would suggest setting the option /heap-arrays (Fortran > Optimization Heap Arrays > 0) to avoid the stack issue.

[Pietro_P_]

Steve Lionel (Ret.) wrote:

Not a bug, but a missed opportunity. This is an aspect that has been gradually improved over the years. I recall that assignments of allocatable components was an area in need of improvement in the past. Which compiler version are you using?

I would suggest setting the option /heap-arrays (Fortran > Optimization Heap Arrays > 0) to avoid the stack issue.

Intel® Parallel Studio XE 2016 Update 4 Composer Edition for Fortran Windows*     Package ID: w_comp_lib_2016.4.246

Intel® Parallel Studio XE 2016 Update 4 Composer Edition for Fortran Windows* Integration for Microsoft Visual Studio 2010, Version 16.0.0063.2010

does the heap array workaround (btw it works great, thanks!) cause any issue regarding performance/ram usage? 

[Kevin_D_Intel]

I created a reproducer based on the OP's outline that confirms array copies are created. I submitted this to Development for further analysis regarding the missed opportunity Steve noted.

(Internal tracking id: DPD200417570)

[Steve_Lionel]

Kevin, you might also want to check to see if there are existing issues I filed on this in the past. It sounds very familiar.

[Kevin_D_Intel]

Thank you Steve. Those I found thus far were fixed/closed. I'll update the associated internal tracking id for this thread if an existing case is found.