Gfortran compiling options

[fortran4r]

My workflow involves importing Fortran subroutines into R to work with very large vectors and matrices. My gfortran compiling options are as follows:
gfortran -fimplicit-none -ffree-line-length-0 -fdefault-integer-8 -fdefault-real-8 -fpic -shared fortran_file.f95 -o fortran_file.so

I find these options very convenient to use. I would like to ask whether these options can bring unexpected errors. I am not concerned about portability since I only distribute the so files and other R users just call them from R.

[fortran4r]

So the implicit none and free line length options are ok, right? Regarding the default bit options, what are the potential issues?

[themos]

It looks like you you are not sure whether you have sprinkled enough IMPLICIT NONE in your sources. Please do yourself a favour and do so.

It is also not clear whether you have enabled explicit interfaces for your subprogram references. Again, same advice applies.

The -fdefault-X-Y options are abhorrent to me, for reasons explained above.

[fortran4r]

@kargl

my recommended gfortran options

does the order of these options matter?

[pcosta]

Thanks! I like to use -finit-real=snan combined with the -ffpe-trap=… to catch operations performed with variables that were not initialized.

[CRquantum]

For ‘release’ use, I usually only use -Ofast -mach=native
If anyone have better flags for ‘release’ mode, please advise too.

For ‘debug’ use, possibly could just use whatever flags you want.

I usally use intel fortran first, then use gfortran to compile and to fix some possible issues which intel fortran is happy but gfortran is unhappy about.

[CRquantum]

Thank you very much!

Do you have suggestions about what flags to use for ‘release mode’?

By the way, in my another topic,

Why solving two differential equations is 8 times slower than solving one?

compiler flag: /nologo /debug:full /O3 /QxHost /assume:buffered_io /heap-arrays0 /Qipo /debug-parameters:all /module:“x64\Release\” /object:“x64\Release\” /Fd"x64\Release\vc150.pdb" /traceback /libs:static /threads /Qmkl:cluster /c linker flag: /OUT:“x64\Release\stochastic_RK.exe” /INCREMENTAL:NO /NOLOGO /MANIFEST /MANIFESTFILE:“x64\Release\stochastic_RK.exe.intermediate.manifest” /MANIFESTUAC:“level=‘asInvoker’ uiAccess=‘false’” /DEBUG /PDB:“D:\Works CHLA\stochastic_RK\stochastic_RK\stochast…

It seems really the 8 times slow down is caused by my random number generator. Thank you very much for bring that to my attention!

[zaikunzhang]

@kargl

Using -Ofast may be a bad idea. See the documentation and look up a summation with carry algorithm for why it is a bad idea. Getting the wrong answer fast may not be the desired result.

@CRquantum

-Ofast turns on -ffinite-math-only among (many) others. -ffinite-math-only orders the compiler to assume that all the numbers involved in the calculations are finite — no Inf, no NaN. This is fine if you have only a few lines of code, and they deal with only numerically easy (well-conditioned) problems. Otherwise, Inf and NaN will likely pop out at places that we may not be able to imagine until we see them.

If -Ofast is intended, then it may be a good idea to put at least -fnofinite-math-only afterwards.

See:

Optimize Options (Using the GNU Compiler Collection (GCC))

[fortran4r]

I understand that Fortran highly values backward compatibility. How about gfortran? Is it possible that some of these gfortran options be deprecated in the future?

[Harper]

I also avoid the gfortran option -freal-M-real-N (where M = 4 or 8, N = 4, 8, 10 or 16, but N /= M) because it doesn’t do everything I wanted it to. Selected_real_kind ignored these options and so did literal constants with _kind, e.g. 1.0_4, when I last tried them a few years ago. I don’t know whether more recent gfortran versions have fixed those problems.