Stack; Heap; Save

[randystonesifer]

In porting a UNIX fortran code to PC Windows I have run into a stack overflow problem. I am using CVF 6.

It seems a variable that is "SAVE"ed(explicit SAVE or by default) alwaysends up on the heap rather than the stack. But it seems that a variable that is not SAVEd (explicit or by default) may end up on the heap or the stack. Is this correct?

Is there a way to force the compiler to SAVE allvariables (i.e., place them on the heap rather than the stack) without making changes to the source code?

In the CVFmanual it very clearly describes what variables are SAVEd by default. I can find no similar discussion of which variables are placed on the heap and which are placed on the stack. Is there such a discussion available?

Steve's article on stack problems (link broken) recommends using allocatable arrays to reduce stack usage and further says allocatable arrays are automatically deallocated upon routine exit unless explicitly SAVEd. This implies that any allocatable variables must always end up onthe heap rather than the stack. Is this true?

Steve'sarticle suggests that passing noncontiguous arrays may lead to stack problems and refers to Chris Boyd's article in Newsletter I. Is there acurrent link available for this article?

Thanks for any clarifications or ideas for identifying the possible reasons for my stack overflow.

Randy

[Steven_L_Intel1]

Nothing at all is put on the heap unless it was created by ALLOCATE. SAVEd variables, unless they are ALLOCATABLE, are given static allocations (fixed by the linker). The only way to put a variable on the heap is for it to be a POINTER or ALLOCATABLE and then you allocate it. There is no way to cause this to happen automatically.

[randystonesifer]

Thanks Steve for the clear and concise explanation of what goes on the heap!

Is there as simple an explanation for what goes on the stack (assuming the compiler default of /static)? Stackoverflow is my problem.

Other than the inconvenience of needing to give a specific stack size to the linker, is there any performance issues with stack usage (especially when virtual memory comes into play)?

Is there any downside to specifying a very large stack size say equal to or even greater than physical memory plus page file size?

Any current links for Chris Boyd'sstack related article?

Thanks,

Randy

[Jugoslav_Dujic]

By default (unless you compile with /recursive or /automatic), very little of your variables goes to the stack, with notable exception of automatic arrays (but they'reseldom used and even then seldom oversized).

The most likely culprit are array operations, where compiler frequently generates temporary arrays which go to the stack. Earlier versions of CVF (and even the latest, 6.6C) were notoverly smart in deducing when a temporary copy is required. For example:

x(1:n-1) = x(1:n-1) + x(2:n)

is IMO likely to produce a temporary stack copy (check out for yourself by rewriting it using a do-loop and comparing speeds)

write(42) x(1:n)

produces an unnecessary stack copy in CVF's up to 6.6C, and maybe even there

subroutine foo(x)

real x(*)

...

call foo(x(1:n:2))

must produce a copy per standard; the solution is to use an assumed-shapeargument and provide an explicit interface.

call foo(x(:))

should not produce a copy, but CVF will often generate it.

etc. Why don't you debug your code and see for yourself where your stack overflow emerges?

Newer CVF's have option /check:arg_temp_created (Project/Settings/Fortran/Run-time/Actual Arguments use Temporary Storage) which detects (some of) stack copies on run-time.

HTH

Jugoslav

[Steven_L_Intel1]

That would be Chris Bord's article. I'll post it when I get back to the office on Friday.

There's no real harm in setting a large stacksize, but stack comes out of your process address space which is limited to 2GB on 32-bit versions of Windows, so I don't recommend going crazy here.