forums.silverfrost.com

[DanRRight]

With older Fortran with their COMMON blocks using OPTIONS to debug specific subroutine/function was very easy and straightforward. No any other compiler had anything even remotely similar to this genial approach and no matter how advanced in all that new Fortran Standard 20XX new features do not have it up to today.

Suppose you have large file with many subroutines. You compile this file with whatever compiler switch is needed like /check or /debug or /nocheck etc etc etc and then if you got an error you just add to the Fortran source text in this large file only one line with the new compiler settings called "OPTIONS" before of needed subroutine

OPTIONS (undef)

and this specific subroutine in the large file will be compiled differently checking undefined variables which slows the code run and debug but only for this specific subroutine. This way using SDBG you will quickly find the error. Some negative moment was that it was not clear how to undo these new OPTIONS after the end of this subroutine so it affected everything in the large file after the OPTIONS line. But it was easy to relocate the needed affected subroutine to the end of the large file.

But with MODULES this strategy stopped to work. The compiler does not like OPTIONS in front of any subroutine or inside of them for the subroutines inside the module. Tells "*** Error 398: OPTIONS must not appear inside a sub-program definition" be it inside or outside the subroutine. May be this does not work because I am doing something wrong ?

With modules approach to design Fortran programs it is not easy to separate affected subroutine/function from the module and compile it differently. One single monster module eventually swallows all subroutines into itself like into black hole. But may be actually it is not that hard? I am open for suggestions here too.

What I was trying to do is to compile the whole module with the /check to look if arrays sizes are violated during the run (and I know now they are because found the bug) but when I compile with /check one of other subroutines starts to complain during the run that DEALLOCATE fails:



So the idea was to make OPTIONS (nocheck) just for this failing subroutine. Or OPTIONS (check) for the other one with violating size arrays. Extracting any subroutine from the module and compile them separately will resemble heart surgery

[PaulLaidler]

OPTIONS can be used before a MODULE, PROGRAM, FUNCTION or SUBROUTINE but not within one of these and this includes after a CONTAINS.

For minimal impact I often use a local OPTIONS(debug) so that I can step through part of the code by setting a break point within that part.