Memory Question

[rensor]

Hi. I am currently using the newest version of the Intel Fortran Composer XE 2011 SP1 compiler together with Microsoft Visual Studio 2010. My question concerns how pointers are allocated in memory, but I believe it is best illustrated with an example. Se below.

module data
! When this is allocated, it is on the heap.
type(SomeType), pointer, dimension(:) , allocatable :: TypeData
end module data

program main
use data
!--------------Local variables(on the stack)--------------
type(SomeType), pointer, dimension(:) , allocatable :: TempData
integer :: n = 10

allocate(TypeData(n),TempData(n))
!Do some work on TempData and TypeData
! .
! .
! .
deallocate(TypeData)
TypeData => TempData

! Question: Is TypeData now pointing to memory on the stack? Or is it still on the heap?

end program

I hope you can answer my question.
Best regards Ren

[mecej4]

Entities and concepts such as stacks and heaps are "implementation details" from the point of view of Fortran. They need not even exist or have a useful meaning, and a portable program will not rely upon the properties of such entities.

For the particular compiler/platform of this Forum, however, these points may be useful:

A pointer variable may be associated with different targets at different times. The targets may be allocated differently.

Consider this program

[fxfortran]     program tptr
     integer, allocatable, target :: ijk(:)
     integer,target :: pqr(5)
     integer, pointer, dimension(:) :: ptr => NULL()
     
     allocate(ijk(3))
     ijk = (/7, 8, 9/)
     
     pqr = (/ 11, 12, 13, 14, 15 /)
     
     ptr => ijk
     write(*,*) ptr
     
     ptr => pqr
     write(*,*) ptr
     
     end program tptr
[/fxfortran]

The first pointer assignment is to a target on the heap, whereas the second is to a target on the stack, unless compiler options are used to cause local arrays to be allocated on the heap.

Some confusion is possible because Fortran does implicit deferencing unlike, say C, which uses the expllicit '*' dereferencing operator.

[jimdempseyatthecove]

mecej4,

>> whereas the second is to a target on the stack, unless compiler options are used to cause local arrays to be allocated on the heap

pqr is an array not scalar.

Therefor it is not guaranteed to be on stack.Many implementations willmake locally scopedarrays as if attributed with SAVE unless the subroutine or function is attributed as recursive or the program is compiled with OpenMP enabled, presumably attributing the code as recursive.

*** this also is the situation with an array descriptor

ijk(:) above, while the memory for the data of the array is allocated from the heap, the array descriptor may be SAVE. When you really need these items to be entirelystack situated then enable OpenMP or mark the subroutine/function as recursive .or. use the non-portable Intel supported AUTOMATIC attribute.

IMHO the standards committee should have worked this out long ago with an attribute of STACK or NOSAVE or LOCAL. As for this requiring a new keyword not so since in:

(typename) [, attribute [, attribute [...]]] :: varName

the attributes are in a different name space and ought not to collide with anything other than names in the attribute name space.

Jim Dempsey