- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK I get that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Issue ID is DPD200414549.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This thread will be updated when there is news.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page