- 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