Stack overflow on pointer array assignment

[Uwe_H_]

Hi, the following program stops with a stack overflow when the size of the array exceeds 1/4 of the stack reserve size:

! Stack Reserve Size: 67108864
program Console1
  implicit none
  real*4,pointer,dimension(:) :: zground      => Null()
  ! real*4,allocatable,dimension(:) :: zground
  real*4,pointer,dimension(:) :: temp_ref     => Null()
  ! real*4,allocatable,dimension(:) :: temp_ref
  integer :: i, size
  
  do i=700, 725    
    size = 10.**(i/100.)
    write(*,*),size
    allocate(zground(size), temp_ref(size))
    zground = i * 1.1
    temp_ref = zground
    deallocate(zground, temp_ref)
  enddo
end program Console1

So it seems a temporary stack array is created during the assignment. Is this by design? Interestingly there is no stack overflow when just one of the arrays is declared as an allocatable. I know it's mostly preferable to use allocatables anyway, but there is too many instances in my real program I´d have to change. If there is no better suggestion I´ll therefore use /heap-arrays0 instead.

[Arjen_Markus]

Slight correction to the title: it is not a pointer assignment. You allocate the arrays and then you copy the data. A pointer assignment would be: temp_res => zground

I have seen such problems before - this may be a missed opportunity to optimise the handling of the array operation.

[Steve_Lionel]

When you use POINTER, the compiler has to assume that the left and right side might overlap and therefore it creates a temp. ALLOCATABLE avoids that. /heap-arrays is certainly another choice.

[jimdempseyatthecove]

Steve, the creation of unnecessary stack temporaries has been a long time bane of IVF users. The use of the stack temporary is an easy way to perform the operation. C has had at its inception both memcpy and memmove where memmove handles cases of overlapping memory. Fortran would have to extend this for cases where the pointer has stride other than 1. Supporting non-stack temp pointer copies should be a relatively easy task to support.

While the programmer should use allocatables whenever possible, I also want the compiler to be as efficient as possible.

Jim Dempsey

[Steve_Lionel]

Jim, I don't disagree. In some cases, ifort uses a callable routine that can handle overlaps but often in cases such as this it just generates vectorized code directly. In the C case the user is explicitly calling routines that have overlap-aware semantics. Fortran assignment semantics are that the right side is completely evaluated before the left is modified.

Yes, more thorough analysis and special-casing in the compiler can help here. but last I knew the Intel compiler didn't try to do that for POINTER cases.