Gfortran compiling options

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.

1 Like

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

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.

3 Likes

does the order of these options matter?

1 Like

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

4 Likes

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.

Thank you very much!

Do you have suggestions about what flags to use for ā€˜release modeā€™?

By the way, in my another topic,

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!

@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:

4 Likes

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?

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.