Force Deallocation On Exit

[psublue]

We recently switched from the Lahey compiler to the Intel compiler and are in the process of converting some old makefiles to the Intel command line syntax. We have found replacements for almost everything but the "dal" flag, which basically forced deallocation of everything when the program (or individual subroutines, I don't remember) returned.

We've been looking through the 625-page command line flags document, but so far we haven't been able to come up with anything. Is there a way to do this with the Intel compiler?

Any help would be greatly appreciated. Thanks!

[Steven_L_Intel1]

I don't see that such an option is needed. When the program exits, Windows automatically frees all storage that was allocated during the run. As for individual routines, local variables that are ALLOCATABLE will be automatically deallocated on exit (unless they are SAVEd) because the Fortran language requires this. What other kind of storage did you want deallocated on routine return?

[psublue]

The code in question is a calculation engine that processes urban scenes. The user sets up a scene and its calculation parameters and requests output from the calculation engine, which is the Fortran code in question. The basic program flow is as follows:

• User's program sets things up
• User's program makes a call through the API to our Fortran code, passing it pointers to its input and (empty) output arrays
• Our Fortran code runs and writes its output to the output arrays
• User's program retrieves information from pointers and exits

The problem we have is that users now want to do multiple calculations in series. We're finding that the first calculation runs fine, but the second calculation tries to allocate arrays that have already been allocated. Additionally, at the start of the second run, many (but not all) variables remain set to their values after the first run. With the old Lahey compiler, this was not an issue since the compiler was forcing deallocation on exit.

Note: We know that this is not a good habit to get into, but this particular portion of code won't be around much longer anyway. We just need a temporary solution to hold us over during the Lahey->Intel and CPU->GPU switch for the calculation engine. We're really not terrible programmers, I swear.

[Steven_L_Intel1]

I'm still somewhat puzzled. Is your Fortran code in a DLL called from some other language? If so, what constitutes an "exit"? Is this how you did it with the Lahey compiler?

If you are using a DLL, there's no "exit" point that would cause everything to be reset back to the way it was on initial load.

Are these ALLOCATABLE arrays or POINTER arrays? Are they local to the routine you're calling? Is /Qsave among the compiler options in use?

[psublue]

Quoting - Steve Lionel (Intel)

I'm still somewhat puzzled. Is your Fortran code in a DLL called from some other language? If so, what constitutes an "exit"? Is this how you did it with the Lahey compiler?

If you are using a DLL, there's no "exit" point that would cause everything to be reset back to the way it was on initial load.

Are these ALLOCATABLE arrays or POINTER arrays? Are they local to the routine you're calling? Is /Qsave among the compiler options in use?

The Fortran code is in a DLL that is called from C++. With the Lahey compiler, it appeared that when a job would finish, the "-dal" compile option would kick in and deallocate everything.

The arrays themselves are ALLOCATABLE and are stored in a module called GLOBAL_DATA, which is used by every subroutine in the engine. Here's our line of compiler flags for our debuggable version (which is what we're currently working with):

/debug:all /error-limit:$(XFATALS) /Ge /arch:IA32 /nologo /nocheck /automatic /fpe:3 /traceback /lowercase /us /threads /c /heap-arrays

The more I think about it, I guess this is really a question of how to do the "on exit" deallocation, but "on demand" instead.

[Steven_L_Intel1]

I can't figure out what the Lahey compiler would define as "on exit" in that case. Intel Fortran does not have such a feature, since the only "exit" a DLL has is on unload, and that would take care of your problem automatically. Unfortunately, I am sure, your "user application" has no way to do an unload of the DLL and then reload it for the next "job".

I recommend adding an "initialize" routine which resets the state the way you want it.

[psublue]

Quoting - Steve Lionel (Intel)

I can't figure out what the Lahey compiler would define as "on exit" in that case. Intel Fortran does not have such a feature, since the only "exit" a DLL has is on unload, and that would take care of your problem automatically. Unfortunately, I am sure, your "user application" has no way to do an unload of the DLL and then reload it for the next "job".

I recommend adding an "initialize" routine which resets the state the way you want it.

I had to dig around a bit, but here's what Lahey's documentation says:

"Specify -dal to deallocate allocated arrays that do not appear in DEALLOCATE or SAVE statements when a RETURN, STOP, or END statement is encountered in the program unit containing the allocatable array."

That explains why we never had problems before, since the "exit" point was an END SUBROUTINE statement. I'll look into adding an initialization routine, which sounds like it should do the trick. Thanks for your help!

[Steven_L_Intel1]

I too just found the Lahey documentation. I also found this:

LF95 uses -dal by default; LF90 used -ndal. Automatic deallocation is standard in Fortran 95.

In other words, the Intel Fortran default behavior is the same as LF90's -dal. Non-SAVEd local allocatable arrays are automatically deallocated on routine exit. This behavior was not specified in Fortran 90 but was explicitly called out in Fortran 95. Intel Fortran implements the Fortran 95 behavior and does not provide an option to turn it off.

However, this would have no effect on ALLOCATABLE variables in modules, in either compiler. (If it did in the Lahey compiler, that would be a serious bug.)