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.

[DanRRight]

Ideally of course would be if Silverfrost solved the problem with the current restrictions so that OPTIONS would work everywhere, inside the MODULEs, after CONTAINS, and if dream further -- ultimately even inside the SUBROUTINEs, inside DO loops or IF/ENDIFs.

Also interesting to me how fellow programmers solved the problem with multiple modules. The ultimate convenience is of course when you have just one module where all variables share all their properties. With just one big module you do not have to worry that all variables miss something as opposed to when you split the module into two and the variables miss some properties (which you may never find because of using local OPTIONS is missing and using global compiler directives make the code too slow) .

But with that one module you lose the ability to use OPTIONS for some local subroutines and you have to apply OPTIONS for the entire MODULE which is essentially as applying the same compiler directive to the entire code externally

One more question here : seems gFortran checks for array violations without slowing the code. As opposed to FTN95 which also does not slows the code if you use /DEBUG but does not check the array violations. To check for array violations you need to use /CHECK which tremendously slows the code

[PaulLaidler]

Checking can be made selective. /BOUNDS_CHECK does the array bounds checking (which is part of /CHECK) so you can use this with /DEBUG to avoid other time consuming checks.