Intel® Fortran Compiler
Build applications that can scale for the future with optimized code designed for Intel® Xeon® and compatible processors.
29242 Discussions

Deallocating memory across subroutines

tmcole
Beginner
587 Views
Thanks to Jugoslav, I have output to a dialog working (and it really looks nice - a vast improvement on write statements to a QuickWin window). However, I now find myself in another dilema. In order to get the dialog box to work correctly, I had to start my computational code in another thread. Jugoslav nicely provided a way to stop the computation and then rerun it. However, in order to rerun the code, I have to deallocate a very large number of variables across a number of subroutines.

The problem comes in that variables allocated locally and then "saved" in subroutines require me to put them in modules accessible globally and then USE them in a separate subroutine accessible from the dialog thread in order to deallocate them. This has required me to move all the local type declarations into modules that can be USEd. The problem is that now I have variables that were formerly local variables that are now defined globally with a large number of resulting name conflicts.

Is there any easy way to deallocate all variables across all subroutines without having to do the above and then go back and rename all conflicting variables?

If there is no way, then I would like to disable the 30 error messages and ending the compilation. Is there any way to make it compile the code and list all error messages?
0 Kudos
2 Replies
Steven_L_Intel1
Employee
587 Views
There is no "global deallocate".

There is a /noerror_limit compiler switch.

Steve
0 Kudos
Jugoslav_Dujic
Valued Contributor II
587 Views
Tom, have in mind that local (non-module) ALLOCATABLE arrays are automatically deallocated on return, unless they have SAVE attribute. Threads have nothing to do with it. Thus, all you need to do about deallocation in general (but you'd probably have to do it if you used plain CALLs instead of CreateThread) is to DEALLOCATE all global (module) arrays and local ALLOCATABLEs with SAVE attribute.

The only potential thread-related interaction is if you called ExitThread or TerminateThread -- they kill the thread before it reaches normal RETURN so run-time library does not come to auto-deallocate local arrays.

Jugoslav
0 Kudos
Reply