forums.silverfrost.com

[georisk]

I am a recent upgrade to 64 bit and ftn95

I used to compile code requiring large arrays using:

ftn77/stack 9999999 myprog.for -link

Code still compiles on old laptop.

If I try the same using ftn95 on new 64 bit machine it says I need to use /clr option. But when I use this it gives a lot of warnings (no errors) and won't compile.

Any ideas appreciated.

[JohnCampbell]

I think /clr invokes .net which is probably not what you want.

You have two main options.

1) Change the program to remove local big ARRAYS from the stack, puting them in common/modules.

For large global arrays, this can be done by moving large arrays to a COMMON or MODULE
( this is easy as you just list the large arrays in a named common as
COMMON /BIG_STACK/ array_1, array_2

or if they are temporary arrays in a subroutine, allocating them with ALLOCATE, rather than being just local arrays.

Example
! declare with
real*8, allocatable, dimension( :,: ) :: big_array ! if this is identified as a large local array
!
! early in the executable code : the dimensions can be variables
ALLOCATE (BIG_ARRAY(4000,5000))
!
! to be neat, at the ned
DEALLOCATE (BIG_ARRAY)

Typically you should have few arrays to implement this change.
The memory limit for FTN95 is about 1.6gb. If the program is old chances are it is nowhere near this. However if you are changing the size in anticipation of 64bit, that may explain the problem

2) change the way you compile and link
compile with >ftn95 myprog.for
link with >slink myprog.obj -stack:9999999

I have never had any success with /stack or -stack and would recommend analysing your program to remove large local arrays from the stack.
Also, avoid /ZERO or /SAVE if you can, as this increases the stack use.

You may be reluctant to change your F77 code, but the changes should not be significant, as you are only telling the compiler where to use memory.

John

Ps. I omitted ",allocatable" from the declaration.

[georisk]

John

Thought I try the easy option #2 first. It worked a treat. Thanks for your help.

Program was 3500 lines of F77 code that I have used for many years and has been tested and known to work. Always hesitant to change code when I know it works.

Once again thanks for your help.

Andrew

[JohnCampbell]

Andrew,

I would recommend that you investigate if you have large local arrays. Option /xref will list all variables and their size. You can import the list into excel and then calculate the size of all arrays, sorting to identify any possible targets.
Typically they are in the main program, where it is easy to group them into a common or a module, with little risk of changeing the program.
If they are in a subroutine or function, you should consider if they require /save or /zeroise to run; both of which approaches are non standard and not recommended. These arrays can be easily made as ALLOCATE or possibly included as a subroutine argument to better manage temporary variables from the main program.

I'm surprised that this occurs in F77 code, as memory was at a premium back then.

John