Compilers and Compiler Options

The compiler version decides which options exist, and documentation sites are not always versioned the way the compiler is:

gfortran and flang are drivers. One command line is expanded into up to four programs, each with its own options, and the options you give are routed to the stage that understands them:

The flags that stop the pipeline early are the same for both compilers:

gfortran -dumpversion and gfortran -dumpmachine print 16.2.0 and aarch64-linux-gnu in the test container, and flang --version prints the Debian packaging version string. The file extension chooses the source form and whether the preprocessor runs: .f90, .f95, .f03 and .f08 are free form without preprocessing, .F90 and friends are free form with preprocessing, .f, .for, .ftn are fixed form (see Program Structure and Source Form), and -ffree-form/-ffixed-form override the guess in both compilers. The details of each stage are below; the build-system view (compiling_source, linking_pieces, runtime_libraries) is on the Fortran-lang build pages listed in the References.

The first decision for a portable code base is which language it promises. GNU Fortran takes the answer from -std=:

The unflagged default is -std=gnu, so a program that compiles silently with plain gfortran file.f90 can still be nonconforming. Flang’s -std= is far narrower: it accepts only f2018 and says so for every other value (error: Only -std=f2018 is allowed currently., printed for -std=f2023, -std=f2008, -std=f2003 and -std=legacy in LLVM 23.1.4). Its -pedantic option turns on portability warnings. Flang accepts the F2023 features it implements without any switch, so -std=f2018 is a diagnostics setting and not a feature gate. The next program uses sind, one of the degree-argument trigonometric functions that Fortran 2023 added; gfortran prints the edition in its own diagnostic.

The first line is gfortran with -std=f2023, the next two are gfortran with -std=f2018 (the warning and then the error it causes, because with the intrinsic switched off sind is an undefined external function and implicit none rejects it), the fourth line is Flang’s run and the last is the error from -std=f2023 in Flang. The four lines of the diagnostic have been shortened to the two messages, since gfortran also prints the source line and a caret for each. Source: J3/23-007r1, 16.9 Standard generic intrinsic procedures (SIND) and 4.2 Conformance.

The matching options elsewhere, as far as the vendor manuals name them: Intel ifx selects the checked standard with -stand (the issue baseline for this section names -stand f23), NAG has one switch per edition, and the Flang documentation notes that all the compilers' conformance options "issue warnings if non-standard features are used" (Flang OptionComparison page, which lists -Mstandard for classic Flang, -std=level for GNU and -stand level for Intel). The ifx page for -stand could not be read as text on 2026-10-19, so the argument list is not repeated here.

A conforming program should compile under -std=f2023 on gfortran with no warnings from -pedantic. That is the single most valuable portability test, and the one used for every example in this guide. It does not prove portability: the standard leaves much processor-dependent, and the other compilers support different subsets of Fortran 2023 (see the support table in History, Standards and Compilers).

Static warnings cannot see an index computed at run time. The cheapest way to find out-of-range subscripts, use of undefined values and floating-point exceptions is to run the real program with checks switched on, in a build used by tests and by developers, never in a performance run.

Optimization flags are the least portable part of any build, and the one where a wrong guess costs the most.

The effect on the heatflow kernel, a 1000 by 1000 Jacobi sweep run 400 times, built as two files so that link-time optimization has something to do:

Source: GCC 16.2 manual: Options that control optimization

Source: GCC 16.2 manual: Options that control optimization

Every build printed residual = 6.050E-02, so the answers agree to the printed digits. The times, from one run on one aarch64 container (so only the ratios mean anything; never copy timings from a table like this one into a decision):

The lessons are the usual ones, and the numbers support them: the jump from -O0 to -O2 is an order of magnitude, the extra flags beyond -O2 are a small or nil gain for this kernel, and the runtime checks cost little here because the loop accesses are simple (in a loop with an indirect access they can cost far more). Measure your own code. -march=native makes an executable that may not run on another CPU of the same family; do not use it for artifacts you ship.

A .mod file is produced for every module, next to the source by default. Two flags control where, and they are easy to get wrong:

The directory must already exist. gfortran prints Warning: Nonexistent include directory 'nodir' followed by the failure to write; Flang prints error: Error writing nodir/kernel_mod.mod: No such file or directory. The module files of different compilers are not interchangeable: a gfortran .mod is a gzip-compressed text file starting GFORTRAN module version '16', and a Flang .mod is plain text starting !mod$ v1. Giving one compiler the other’s module directory produces Fatal Error: File 'mod_fl/kernel_mod.mod' opened at (1) is not a GNU Fortran module file. The consequence for builds: use a separate module directory per compiler (and per major version), as in

all four commands succeeded; compiling bench_main.f90 for gfortran without -I mod_gf fails with Fatal Error: Cannot open module file 'kernel_mod.mod' for reading at (1): No such file or directory. The Intel and NAG module-directory options are in their manuals (not read or run here). Build tools set these for you: CMake’s Fortran_MODULE_DIRECTORY property and fpm’s per-compiler build folders both do exactly this. See Modules and Submodules for dependency order. Source: GNU Fortran 16.2 manual: Options for directory search.

The Fortran standard has no preprocessor (it has include lines, 6.4 in J3/23-007r1); everything on this section is vendor behavior. By convention .F90 runs the C-style preprocessor and .f90 does not.

Saved as pp_demo.F90:

Source: GNU Fortran 16.2 manual: Options controlling Fortran preprocessing

Saved as pp_lower.f90 instead, with no flags, gfortran treats the # lines as source and prints Warning: Illegal preprocessor directive for each one; Flang preprocesses the file but defines neither predefined macro, so it runs and prints compiled by another compiler; and gfortran -cpp pp_lower.f90 prints compiled by gfortran. The rule is therefore: -cpp (both compilers) or an upper-case extension switches on predefined macros; -nocpp switches them off; -D<macro>[=<value>] and -U<macro> define and remove macros, -I finds includes, -E shows the result, and -M, -MD, -MF, -MT write make-style dependency files in gfortran (see Building with Make, CMake and Meson). The macros __GFORTRAN__ and __flang__ identify the compiler. The preprocessor is a C one: it does not understand Fortran’s // concatenation or ' quotes, which causes real bugs in long lines. Prefer a plain-Fortran logical, parameter constant and if over conditional compilation, and keep #ifdef for platform and library differences. gfortran’s -fpre-include=<file> pre-includes a header in every unit.

Fortran is linked like C. Each compiler’s runtime provides the I/O, formatted output, intrinsics and error handling that a Fortran program calls, and the driver adds it to the link line. The example is the same module-and-external-subroutine program in three files, so that the symbol names and the link steps can be inspected.

Source: GNU Fortran 16.2 manual: Options for influencing the linking step

The symbol table (only the interesting rows) shows how the compilers name things:

Source: GNU Fortran 16.2 manual: Options for influencing the linking step

and the executable ran and printed area = 12.5664. The names are not standardized. gfortran mangles a module procedure as __module_MOD_name and appends one underscore to the name of an external procedure (report_area_; the -fno-underscoring option removes it and -fsecond-underscore adds another), and the Fortran main program is main. Flang produced _QMshapes_modPdisc_area for the module procedure and report_area_ for the external one. The two schemes for modules are different, so object files of module code from different compilers cannot be linked together, while objects containing only external procedures with bind(c) (see Interoperability with C) or with the common trailing underscore can. ldd shows what the executable needs at run time:

The driver chooses the libraries for you; gfortran -### shows that it adds -lgfortran -lm and the GCC runtime, and flang -### that it adds -lflang_rt.runtime -lm and the GCC runtime. A Fortran program that is linked by a C or C++ driver must add these itself (-lgfortran -lm or the Flang equivalents), which is the commonest link error in mixed builds (undefined reference to _gfortran_st_write). Libraries are searched in order, so put them after the objects that need them: gfortran main_link.o -L. -lshapes -o app_lib works (the archive was built with ar rcs libshapes.a shapes_mod.o legacy.o) while the reverse order does not resolve. A shared library needs position-independent code: gfortran -fPIC -shared shapes_mod.f90 legacy.f90 -o libshapes.so exported __shapes_mod_MOD_disc_area and report_area_ (checked with nm -D). Fortran code that uses coarrays also needs the coarray library: gfortran 16 takes -fcoarray=lib and links libcaf_shmem, and its valid values are none, single and lib only (see Coarrays, Images and Synchronization); Flang has an experimental -fcoarray. For BLAS and LAPACK see BLAS, LAPACK and Numerical Libraries.

When a user reports a numerical difference, the first question is what built the program. The intrinsic module iso_fortran_env provides compiler_version() and compiler_options() (J3/23-007r1, 16.10.2.6 and 16.10.2.7); both return a processor-dependent string that "should include relevant information that could be useful for diagnosing problems at a later date".

Two observations. gfortran lists the options it kept, not the command line: -march=native has been replaced by the expanded -mcpu=... string and the -pedantic and -Wextra options are not in the first line, because only the options that affect the generated code and the dialect are recorded. A line like this in a log is enough to reproduce a build. The Flang string is the command line, including -o provenance. Print both in the banner of a program and in the header of every output file; the heatflow CSV writer does this in its comment line. Source: J3/23-007r1, 16.10.2.6 COMPILER_OPTIONS and 16.10.2.7 COMPILER_VERSION.

The standard allows a processor to accept additional forms and relationships as long as they do not conflict with the standard ones (4.2), and every compiler does. A program that uses them is not standard-conforming and fails on the next compiler. Both compilers publish their lists: the GNU Fortran manual’s "Extensions" chapter has a list of "Extensions implemented in GNU Fortran" and one of "Extensions not implemented in GNU Fortran" (abbreviated GF Extensions in the outline of this guide), and the Flang documentation page "Fortran Extensions supported by Flang" (Extensions.html, FN Extensions) groups them as intentional violations of the standard, default-on extensions, opt-in extensions and unsupported features. The first gives a sense of how permissive each tool is by default:

Source: GNU Fortran 16.2 manual: Extensions and Fortran Extensions supported by Flang

The three blocks are gfortran under -std=f2023 (an error, and the follow-on error because the declaration is dropped), gfortran under -std=gnu with -pedantic (a warning), and Flang with -pedantic (a portability warning; without it Flang accepts real*8 silently). The second example is about intrinsic procedures that the standard does not define:

Source: GNU Fortran 16.2 manual: Extensions

Under -std=f2023 the GNU intrinsic is not recognized (with -Wintrinsics-std the compiler says it "will be treated as if declared EXTERNAL"); -fall-intrinsics brings it back, and Flang accepts it with no warning even under -pedantic, since it too provides getpid. The same is true of tab characters in free-form source: standard conformance does not allow them, gfortran under -std=f2023 warns for every one (Nonconforming tab character at (1) [-Wtabs]) and Flang accepts them silently, even with -pedantic.

The practical recipe for portable code:

The Flang options that make a legacy extension available are opt-in and named after the extension: -fbackslash, -flogical-abbreviations (.t., .f.), -fxor-operator (.xor.), -falternative-parameter-statement, -funsigned and -fimplicit-none-ext; gfortran groups the DEC-compatible ones under -fdec (-fdec-structure, -fdec-math, -fdec-include, -fdec-static, -fdec-blank-format-item and others). -funsigned in both compilers enables the experimental unsigned integer type (a Fortran 202y item, see What’s New and Fortran 2028 Preview). Also worth a look is -fc-prototypes, which makes gfortran print a C prototype for each bind(c) interface.

The same choices expressed through CMake, Meson and fpm are in Building with Make, CMake and Meson and Fortran Package Manager (fpm) (fpm has --profile debug and --profile release and --flag for extra options); gfortran --help=fortran and flang --help are the reference when one of these flags is in doubt.

Not checked here, because no compiler for them is installed: Intel ifx, NAG, HPE Cray and NVIDIA HPC compilers; see History, Standards and Compilers for the support table.

See also Best Practices and Style and Common Gotchas and Pitfalls.