OPTIONS

I need to find which devilry makes me crashes all this week.

How correctly make just one function in the module to be compiled with, say, several directives like /CHECK etc while the rest of module to leave compiled with /NOCHECK?

If i use OPTIONS(CHECK) in front of one specific function will it also affect all other functions/subroutines in the module after it? Is it even legal to do that in the module which has many functions inside of it and is a single file?

In the days of Fortran77 with its clear LEGO-like structure when modules did not exist this was easily done. You could also without any troubles extract your specific subroutine into the external file. Now with modules you rapidly run into the hell if you try to extract any function out of the module into another module and try cross reference by using something from one in another

Now no matter where i place the line

OPTIONS(CHECK)

(before function, inside function, I always get diagnostics

*** Error 398: OPTIONS must not appear inside a sub-program definition

Then how to make just one subroutine/function inside one large module which is also one file to compiled with special compilation conditions ?

And that line appears the the wrong place of the error report (by the way do anyone else last couple years gets also this problem when the error is shown in the wrong place ?)

The OPTIONS directive can only be used

1. before a main program or
2. before an external subroutine or function or
3. before a module definition.

If /CHECK is required but only for a particular module subprogram (or contained subprogram) then a temporary change to the code must be made in order to replace the body of the subprogram by a call to an external subprogram that does the same same task. /CHECK can then be applied to the external subprogram.

Argument checking requires that extra code be planted by the compiler at both the calling point and within the subprogram that is called. Also the compiler design allows for both checked and unchecked code to exist side by side. Given that this requires considerable ingenuity, certain restrictions are naturally required.

Paul, Currently when you compile with /checkmate or /check or /debug or /undef the code runs 2-5 times slower and separating the offending function becomes a problem with modules.

Adding the functionality to make any function/subroutine debuggable adding OPTIONS/ENDOPTIONS command while all other subroutines in the same module are compiled with NOCHECK for speeding up the run would substantially increase debugging simplicity and fast run speed.

/* I have even more tricky stream of devious things actually. My program with /NOCHECK works ok taking only 40 GB RAM while when I try to use anything like /DEBUG, /CHECK or /UNDEF it fails to allocate derived type structure. Or deallocate it. Or if i remove deallocate it makes a memory leak and a total almost 1 TB of RAM+SWAP is not enough and when initially program starts ok, it eventually exhausts all the memory and crashes.

Separating offending place from module into other module is really a hell. Fortran with modules lost its inherent simplicity

I am also puzzled how gfortran for example if you set to it highest level optimization 'FFLAGS = -O3 -march=native' even with AVX512 for getting fastest run speeds still succeeds to keep the debugging information and when error occurs shows you the error line and the fault reason?

I havn't tested lately, but /DEBUG does(did) provide some debugging 'handles' but does not have the performance penalty. If you use /check or /undef with large arrays, this can have a significant performance penalty.

/check did modify the way ALLOCATE arrays are managed, by not releasing memory. If you have /check with large ALLOCATE arrays, deallocate > allocate did cause problems.

Does Gfortran provide /undef functionality ?

Dan

As John says, /DEBUG on its own can be used to step through your code.

Also OPTIONS can be used to switch ON and switch OFF as illustrated here...

options(check)
subroutine sub()
USE ISO_FORTRAN_ENV
print*, compiler_options()
end subroutine

options(-check)
program main
USE ISO_FORTRAN_ENV
print*, compiler_options()
call sub()
end program

I am not offering to extend this to internal subprograms. It would require a major investment of resources whilst a simple modification to the user's code would provide the desired functionality.

The ability to run checked code alongside unchecked code is an extension to the basic design of FTN95 where /CHECK is intended for one-off checking when the code is first written. That is, write the code and step through line-by-line using the debugger and checking options whilst testing evey path through the code. Then switch off for production runs.

Thanks Paul for the hints. I understand that OPTIONS is an extended functionality. But this actually gets sense for long running codes and large codes with modules as opposed to older style with separate subroutines with COMMON blocks. Because we can in one minute add couple lines like this to the code

OPTIONS (checkmate)

instead of moving files (took me a day) because with modules it is much harder to separate files. And this will slow down only small portion of the code as opposed to entire file if you use /Checkmate as the best debugging option. It take me 2 hours to load the files and at the end i get the crash. Just the /DEBUG is fast but catches only major basic errors. Noticed last days terrible swearing and yelling heard from the streets and the floor shattering? That was me.

John, Yes, gfortran now has analog of /undef. The only what it missing is modern visual IDE debugger which is a lot to miss. Intel has IDE but it is so bad that i never succeeded to use it. And no IDE for Linux if think on the long run. Still numerous problems i had lately losing 2 weeks in two months on unexplained crashes (and still do not know if this was me, FTN95 or Clearwin mostly causing that or all of the above) pushed me to think to modify the code to be compatible with gFortran and Intel to have second opinion which is always helpful. Thanks for the info that just the single /DEBUG works even with /NOCHECK code, does not slow down the run and still shows debug information. I always use /DEBUG either with /CHECK or /UNDEF or both with /CHECKMATE (as well as /FULL_DEBUG /CHECK_WINIO and of course /NO_TRUNCATE). That catch most of bugs but also slows the run