forums.silverfrost.com

sigment · Joined: 17 Dec 2007 Posts: 9

Hi,

I'm trying to see if I can use the great-sounding FTN95 /CHECKMATE dynamic testing support with a mid-size (55K LOC) legacy Fortran 77 application but with no luck so far. No matter how large I seem to make the stack I still get a stack overflow, and increasing the stack gives very long startup times.

My current build BAT file includes this:

ftn95 /NO_BANNER /132 /ALT_KINDS /COLOUR /ERROR_NUMBERS /NO_OBSOLETE /P6 /SAVE /FULL_DEBUG /CHECKMATE %F95Source% %2 %3 %4

slink %F95Object% -stack:0x25600000,0x16000

As you can see the stack size I'm trying now is quite large. The Intel Visual Fortran debug build uses <30MB peak in a run. Removing /CHECKMATE and even /FULL_DEBUG doesn't seem to help and the memory use was over 300MB when it ran out of stack.

The program has almost 200 COMMON blocks that are declared in the MAIN, some of which are initialized in BLOCK DATA units. I assume that it is the initialization of all the globals that is giving the long startup times. Maybe there is some way to restructure the code to reduce the stack needed and the startup time. Or maybe there is a known problem with FTN95 causing this?

Thanks!

PaulLaidler · Posted: Sun Jan 13, 2008 5:40 pm Post subject:

Are you sure that you need the /SAVE command line option.
This could bump up the memory requirements dramatically.
If you need to SAVE some local variables and arrays then do this in context using a Fortran SAVE command locally.

(For information about the effect of the Fortran SAVE command, see a standard Fortran text book.)

sigment · Joined: 17 Dec 2007 Posts: 9

Paul, thanks for the quick response. Right now /SAVE is required but I agree that using explicit SAVE declarations in the code is preferred and I plan to migrate the code to that over time (I didn't author this code).

Unfortunately, removing /SAVE as well as /FULL_DEBUG and /CHECKMATE doesn't help anyway: it goes up to 300+MB and then I get a stack overflow error. Can you think of anything else that could be causing this?

Thanks.

PaulLaidler · Posted: Mon Jan 14, 2008 8:53 am Post subject:

It is possible that the "virtual common" command in SLINK may help.

sigment · Joined: 17 Dec 2007 Posts: 9

Thanks, but it seems as though virtual common wouldn't be compatible with /CHECKMATE since I assume you have to initialize all COMMON variables in order to detect use of them when uninitialized. And my whole reason for trying FTN95 is for /CHECKMATE. Am I wrong about this?

PaulLaidler · Posted: Mon Jan 14, 2008 2:07 pm Post subject:

As far as I can tell you should have no problem even if you are using a BLOCK DATA program unit. As far as the linker is concerned, all data is uninitialised.

sigment · Joined: 17 Dec 2007 Posts: 9

Thanks Paul. With -VC it now runs with /CHECKMATE and /FULL_DEBUG with modest memory use! I'll give it a workout next week and see how it does.

Thanks for all the help.

sigment · Joined: 17 Dec 2007 Posts: 9

Well I spoke too soon. After making a few minor changes to the app the stack overflow is back, despite using -vc with slink and no matter how large I make the stack.

I wanted to purchase a FTN95 license and use it for its testing support but unless this is really fixable I'm going to have to go another route. I'd be happy to try a patched version and to work with support to find a fix.

Anyone have any ideas?

Thanks.