Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.

Possible bug: SHAPE(function_which_returns_pointer) causes stack overflow for pointer to large arrays

Joachim_Herb
Beginner
340 Views

Hello,

I observed a problem, if the SHAPE function is used directly on the return value of a function, which returns a pointer. If the pointer is stored in a local variable before using it as argument for the SHAPE function, the program works. Here is a small program to reproduce the error:

module test
    contains
    
    function getPtr(ar)
        integer*4, dimension(:,:), target :: ar
        integer*4, dimension(:,:), pointer :: getPtr
        
        getPtr => ar
        
    end function
end module

   
program Console2
    
    use test
    implicit none
    integer*4, dimension(:,:), allocatable, target :: ar1, ar2
    integer*4, dimension(:,:), pointer :: ptr1, ptr1a, ptr2, ptr2a


    allocate(ar1(100, 2000))
    
    print *, 'shape ar1'
    print *, shape(ar1)
    
    ptr1 => ar1
    print *, 'shape ptr1'
    print *, shape(ptr1)
    
    ptr1a => getPtr(ar1)
    print *, 'shape ptr1a'
    print *, shape(ptr1a)

    print *, 'shape getPtr(ar1)'
    print *, shape(getPtr(ar1))

    allocate(ar2(100, 20000))
    
    print *, 'shape ar2'
    print *, shape(ar2)
    
    ptr2 => ar2
    print *, 'shape ptr2'
    print *, shape(ptr2)

    ptr2a => getPtr(ar2)
    print *, 'shape ptr2a'
    print *, shape(ptr2a)

    print *, 'shape getPtr(ar2)'
    print *, shape(getPtr(ar2))

end program Console2

The output of the program is:

shape ar1
         100        2000
shape ptr1
         100        2000
shape ptr1a
         100        2000
shape getPtr(ar1)
         100        2000
shape ar2
         100       20000
shape ptr2
         100       20000
shape ptr2a
         100       20000
shape getPtr(ar2)
forrtl: severe (170): Program Exception - stack overflow
Image              PC        Routine            Line        Source
Console2.exe       00124497  Unknown               Unknown  Unknown
Console2.exe       0012428F  Unknown               Unknown  Unknown
Console2.exe       0012469C  Unknown               Unknown  Unknown
kernel32.dll       7540336A  Unknown               Unknown  Unknown
ntdll.dll          77119902  Unknown               Unknown  Unknown
ntdll.dll          771198D5  Unknown               Unknown  Unknown

So if the array is too large(?) a stack overflow is caused by the call to shape(getPtr(ar2)),whereas it works for a smaller array. It also works, if the returned pointer is stored in a local variable before used as argument for SHAPE.

I tested the program with ifort 14.0.6, ifort 16.0.3 and ifort 17.0.0, both Win32 and x64, both Release and Debug and all versions produce this error. Using ifort 16.0.3 for Linux, this problem does not show up. Interestingly, the call to shape(getPtr(ar2)) seems to take much longer, also depending on the size of the array. So is there some copying going on? I also tested the program with gfortran 4.9.2 and there is no "waiting" for the call to shape(getPtr(ar2)).

Thank you for your help

Joachim

 

0 Kudos
7 Replies
andrew_4619
Honored Contributor II
340 Views

I would expect having the getptr call within the shape function will almost certainly cause a temp array to be created. You need to increase the stack or use the heap arrays compiler options.

 

0 Kudos
Steven_L_Intel1
Employee
340 Views

I would not expect a temp here - I can reproduce the problem and will send it on to the developers.

The function just returns a pointer - there's no need to reconstruct the data to get the shape of that.

0 Kudos
andrew_4619
Honored Contributor II
340 Views

OK I get that.

0 Kudos
Steven_L_Intel1
Employee
340 Views

Issue ID is DPD200414549.

0 Kudos
Joachim_Herb
Beginner
340 Views

Thank you for confirming the problem. Can I see the progress of the issue somewhere or how do I get to know if/when it has been solved?

Steve Lionel (Intel) wrote:

Issue ID is DPD200414549.

0 Kudos
Steven_L_Intel1
Employee
340 Views

This thread will be updated when there is news.

0 Kudos
Joachim_Herb
Beginner
340 Views
This problem still exists in Intel(R) Visual Fortran Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 18.0.0.065 Beta Build 20170320
0 Kudos
Reply