Next: Environment Variables, Previous: Runtime Options, Up: Invoking GNU Fortran
These machine-independent options control the interface conventions used in code generation.
Most of them have both positive and negative forms; the negative form of -ffoo would be -fno-foo. In the table below, only one of the forms is listed—the one which is not the default. You can figure out the other form by either removing no- or adding it.
-fno-automaticSAVE statement were 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 or -save.)
The default, which is -fautomatic, uses the stack for local
variables smaller than the value given by -fmax-stack-var-size.
Use the option -frecursive to use no static memory.
-ff2cThe calling conventions used by g77 (originally implemented
in f2c) require functions that return type
default REAL to actually return the C type double, and
functions that return type COMPLEX to return the values via an
extra argument in the calling sequence that points to where to
store the return value. Under the default GNU calling conventions, such
functions simply return their results as they would in GNU
C—default REAL functions return the C type float, and
COMPLEX functions return the GNU C type complex.
Additionally, this option implies the -fsecond-underscore
option, unless -fno-second-underscore is explicitly requested.
This does not affect the generation of code that interfaces with the libgfortran library.
Caution: It is not a good idea to mix Fortran code compiled with
-ff2c with code compiled with the default -fno-f2c
calling conventions as, calling COMPLEX or default REAL
functions between program parts which were compiled with different
calling conventions will break at execution time.
Caution: This will break code which passes intrinsic functions
of type default REAL or COMPLEX as actual arguments, as
the library implementations use the -fno-f2c calling conventions.
-fno-underscoringWith -funderscoring in effect, GNU Fortran appends one underscore to external names with no underscores. This is done to ensure compatibility with code produced by many UNIX Fortran compilers.
Caution: The default behavior of GNU Fortran is incompatible with f2c and g77, please use the -ff2c option if you want object files compiled with GNU Fortran to be compatible with object code created with these tools.
Use of -fno-underscoring is not recommended unless you are experimenting with issues such as integration of GNU Fortran into existing system environments (vis-à-vis existing libraries, tools, and so on).
For example, with -funderscoring, and assuming other defaults like
-fcase-lower and that j() and max_count() are
external functions while my_var and lvar are local variables,
a statement like
I = J() + MAX_COUNT (MY_VAR, LVAR)
is implemented as something akin to:
i = j_() + max_count__(&my_var__, &lvar);
With -fno-underscoring, the same statement is implemented as:
i = j() + max_count(&my_var, &lvar);
Use of -fno-underscoring allows direct specification of user-defined names while debugging and when interfacing GNU Fortran code with other languages.
Note that just because the names match does not mean that the interface implemented by GNU Fortran for an external name matches the interface implemented by some other language for that same name. That is, getting code produced by GNU Fortran to link to code produced by some other compiler using this or any other method can be only a small part of the overall solution—getting the code generated by both compilers to agree on issues other than naming can require significant effort, and, unlike naming disagreements, linkers normally cannot detect disagreements in these other areas.
Also, note that with -fno-underscoring, the lack of appended underscores introduces the very real possibility that a user-defined external name will conflict with a name in a system library, which could make finding unresolved-reference bugs quite difficult in some cases—they might occur at program run time, and show up only as buggy behavior at run time.
In future versions of GNU Fortran we hope to improve naming and linking
issues so that debugging always involves using the names as they appear
in the source, even if the names as seen by the linker are mangled to
prevent accidental linking between procedures with incompatible
interfaces.
-fno-whole-fileBy default, the whole file is parsed and placed in a single front-end tree. During resolution, in addition to all the usual checks and fixups, references to external procedures that are in the same file effect resolution of that procedure, if not already done, and a check of the interfaces. The dependences are resolved by changing the order in which the file is translated into the backend tree. Thus, a procedure that is referenced is translated before the reference and the duplication of backend tree declarations eliminated.
The -fno-whole-file option is deprecated and may lead to wrong code.
-fsecond-underscoreThis option has no effect if -fno-underscoring is in effect. It is implied by the -ff2c option.
Otherwise, with this option, an external name such as MAX_COUNT
is implemented as a reference to the link-time external symbol
max_count__, instead of max_count_. This is required
for compatibility with g77 and f2c, and is implied
by use of the -ff2c option.
-fcoarray=<keyword>num_images() is always one.
-fcheck=<keyword>Note: The warning is only printed once per location.
Some checks require that -fcheck=bounds is set for the compilation of the main program.
Note: In the future this may also include other forms of checking, e.g.,
checking substring references.
ALLOCATE statement, which will be always checked.
-fbounds-check-fcheck-array-temporaries-fmax-array-constructor=n program test
implicit none
integer j
integer, parameter :: n = 100000
integer, parameter :: i(n) = (/ (2*j, j = 1, n) /)
print '(10(I0,1X))', i
end program test
Caution: This option can lead to long compile times and excessively large object files.
The default value for n is 65535.
-fmax-stack-var-size=nThis option currently only affects local arrays declared with constant bounds, and may not apply to all character variables. Future versions of GNU Fortran may improve this behavior.
The default value for n is 32768.
-fpack-derived-frepack-arraysThis should result in faster accesses to the array. However it can introduce
significant overhead to the function call, especially when the passed data
is noncontiguous.
-fshort-enumsINTEGER kind a given
enumerator set will fit in, and give all its enumerators this kind.
-fexternal-blasMATMUL, instead of using our own
algorithms, if the size of the matrices involved is larger than a given
limit (see -fblas-matmul-limit). This may be profitable if an
optimized vendor BLAS library is available. The BLAS library will have
to be specified at link time.
-fblas-matmul-limit=nThe default value for n is 30.
-frecursive-finit-local-zero-finit-integer=n-finit-real=<zero|inf|-inf|nan|snan>-finit-logical=<true|false>-finit-character=nINTEGER, REAL, and COMPLEX
variables to zero, LOGICAL variables to false, and
CHARACTER variables to a string of null bytes. Finer-grained
initialization options are provided by the
-finit-integer=n,
-finit-real=<zero|inf|-inf|nan|snan> (which also initializes
the real and imaginary parts of local COMPLEX variables),
-finit-logical=<true|false>, and
-finit-character=n (where n is an ASCII character
value) options. These options do not initialize
EQUIVALENCE statement.
Note that the -finit-real=nan option initializes REAL
and COMPLEX variables with a quiet NaN. For a signalling NaN
use -finit-real=snan; note, however, that compile-time
optimizations may convert them into quiet NaN and that trapping
needs to be enabled (e.g. via -ffpe-trap).
-falign-commonsCOMMON block by padding them as needed. On certain platforms this is mandatory,
on others it increases performance. If a COMMON block is not declared with
consistent data types everywhere, this padding can cause trouble, and
-fno-align-commons can be used to disable automatic alignment. The
same form of this option should be used for all files that share a COMMON block.
To avoid potential alignment issues in COMMON blocks, it is recommended to order
objects from largest to smallest.
-fno-protect-parensREAL and
COMPLEX expressions to produce faster code. Note that for the re-association
optimization -fno-signed-zeros and -fno-trapping-math
need to be in effect.
-frealloc-lhsSee Options for Code Generation Conventions, for information on more options offered by the GBE shared by gfortran, gcc, and other GNU compilers.