Gfortran vs ifort/ifx¶
In both case, please ensure that you are using the most recent version. The gfortran can be found by typing
gfortran --versionIn general, the GCC website provides the latest version
For Mac OS one can check for example The Mac HPC website. Alternatively, one can use Homebrew or MacPorts.
Gfortran and ifort are the two most popular Fortran77/95/2003 compilers on both MacOS and Linux machines. ProDiMo have users on both systems. Unfortunately both compilers made subtle choices to generate the binaries, which can cause runtime errors or not matching output. This discussion aims at listing the major issues.
Heap and stack overflow¶
Ifort allocates automatic arrays on stack (limited) whereas gfortran allocates them on the heap. For example, Blas and Lapack routines use large automatic arrays. One way to alleviate the problem is to use the -heap-array flag when Lapack routines are compiled. However, often just increasing the limit on the stacksize works fine (see OS environment).
Automatic save¶
Many old Fortran routines were written with implicit save option in mind. Neither gfortran nor ifort have save as default. If you add a 'old' Fortran77 routine in ProDiMo, we might need to compile it with the gfortran flag -fno-automatic. Gfortran will treat each program unit as if the SAVE statement was specified for every local variable and array referenced in it. Does not affect common blocks. (Some Fortran compilers provide this option under the name `-static'.) Variables with save statement are assigned to the heap.
Warning: the flag -fno-automatic cannot be used at the same time than -fopenmp, which implies the flag -frecursive. As a consequence, one has to look at the Fortran code carefully, add the necessary save statements and use !$omp threadprivate for the variables with a save statement. Gfortran requires to explicitly call the library -lgcc_eh in the linking phase if threadprivate is used (see Parallel ProDiMo).
Automatic conversion to boolean¶
For ifort .true.=-1, for gfortran .true.=1