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.
SAVEstatement 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.)
Since there is a run-time penalty for initialization of variables
that are not given the
SAVE attribute, it might be a
good idea to also use -fno-automatic with -finit-local-zero.
The f2c calling conventions require functions that return
REAL(KIND=1) to actually return the C type
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 GNU calling conventions, such functions simply return
their results as they would in GNU C—
return the C type
return the GNU C type
complex (or its
This does not affect the generation of code that interfaces with the
However, because the
libg2c library uses f2c
calling conventions, g77 rejects attempts to pass
intrinsics implemented by routines in this library as actual
arguments when -fno-f2c is used, to avoid bugs when
they are actually called by code expecting the GNU calling
conventions to work.
For example, `INTRINSIC ABS;CALL FOO(ABS)' is rejected when -fno-f2c is in force. (Future versions of the g77 run-time library might offer routines that provide GNU-callable versions of the routines that implement the f2c intrinsics that may be passed as actual arguments, so that valid programs need not be rejected when -fno-f2c is used.)
Caution: If -fno-f2c is used when compiling any source file used in a program, it must be used when compiling all Fortran source files used in that program.
libg2c(or the original
libf2c) is required. This is the default for the current version of g77
Currently it is not
valid to specify -fno-f2c-library.
This option is provided so users can specify it in shell
scripts that build programs and libraries that require the
libf2c library, even when being compiled by future
versions of g77 that might otherwise default to
generating code for an incompatible library.
With -funderscoring in effect, g77 appends two underscores to names with underscores and one underscore to external names with no underscores. (g77 also appends two underscores to internal names with underscores to avoid naming collisions with external names. The -fno-second-underscore option disables appending of the second underscore in all cases.)
This is done to ensure compatibility with code produced by many UNIX Fortran compilers, including f2c which perform the same transformations.
Use of -fno-underscoring is not recommended unless you are experimenting with issues such as integration of (GNU) Fortran into existing system environments (vis-a-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 g77 code with other languages.
Note that just because the names match does not mean that the interface implemented by g77 for an external name matches the interface implemented by some other language for that same name. That is, getting code produced by g77 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 g77 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.
This option has no effect if -fno-underscoring is in effect.
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__'.
As of version 0.5.18, g77 normally treats
other statements that are used to specify initial values of zero
for variables and arrays as if no values were actually specified,
in the sense that no diagnostics regarding multiple initializations
This is done to speed up compiling of programs that initialize large arrays to zeros.
Use -fzeros to revert to the simpler, slower behavior that can catch multiple initializations by keeping track of all initializations, zero or otherwise.
Caution: Future versions of g77 might disregard this option (and its negative form, the default) or interpret it somewhat differently. The interpretation changes will affect only non-standard programs; standard-conforming programs should not be affected.
COMPLEXarithmetic via emulation, instead of using the facilities of the gcc back end that provide direct support of
(gcc had some bugs in its back-end support
complex arithmetic, due primarily to the support not being
completed as of version 2.8.1 and
Use -femulate-complex if you suspect code-generation bugs,
or experience compiler crashes,
that might result from g77 using the
in the gcc back end.
If using that option fixes the bugs or crashes you are seeing,
that indicates a likely g77 bugs
(though, all compiler crashes are considered bugs),
so, please report it.
(Note that the known bugs, now believed fixed, produced compiler crashes
rather than causing the generation of incorrect code.)
Use of this option should not affect how Fortran code compiled by g77 works in terms of its interfaces to other code, e.g. that compiled by f2c
As of GCC version 3.0, this option is not necessary anymore.
Caution: Future versions of g77 might ignore both forms of this option.
These options specify to what degree aliasing
is permitted between
arguments (passed as pointers) and
COMMON (external, or
The default for Fortran code, as mandated by the FORTRAN 77 and Fortran 90 standards, is -fargument-noalias-global. The default for code written in the C language family is -fargument-alias.
Note that, on some systems, compiling with -fforce-addr in effect can produce more optimal code when the default aliasing options are in effect (and when optimization is enabled).
See Aliasing Assumed To Work, for detailed information on the implications of compiling Fortran code that depends on the ability to alias dummy arguments.
Further, this option disables such inlining, to avoid compiler crashes resulting from incorrect code that would otherwise be diagnosed.
As such, this option might be quite useful when compiling existing, “working” code that happens to have a few bugs that do not generally show themselves, but which g77 diagnoses.
Use of this option therefore has the effect of instructing g77 to behave more like it did up through version 0.5.19.1, when it paid little or no attention to disagreements between program units about a procedure's type and argument information, and when it performed no inlining of procedures (except statement functions).
Without this option, g77 defaults to performing the potentially inlining procedures as it started doing in version 0.5.20, but as of version 0.5.21, it also diagnoses disagreements that might cause such inlining to crash the compiler as (fatal) errors, and warns about similar disagreements that are currently believed to not likely to result in the compiler later crashing or producing incorrect code.
ARRAY_REFconstruct to handle all array references.
Note: This option is not supported. It is intended for use only by g77 developers, to evaluate code-generation issues. It might be removed at any time.
The current implementation uses the
s_rnge to print the diagnostic.
However, whereas f2c generates a single check per reference for a multi-dimensional array, of the computed offset against the valid offset range (0 through the size of the array), g77 generates a single check per subscript expression. This catches some cases of potential bugs that f2c does not, such as references to below the beginning of an assumed-size array.
g77 also generates checks for
CHARACTER substring references,
something f2c currently does not do.
Use the new -ffortran-bounds-check option to specify bounds-checking for only the Fortran code you are compiling, not necessarily for code written in other languages.
Note: To provide more detailed information on the offending subscript,
g77 provides the
libg2c run-time library routine
with somewhat differently-formatted information.
Here's a sample diagnostic:
Subscript out of range on file line 4, procedure rnge.f/bf. Attempt to access the -6-th element of variable b[subscript-2-of-2]. Aborted
The above message indicates that the offending source line is line 4 of the file rnge.f, within the program unit (or statement function) named `bf'. The offended array is named `b'. The offended array dimension is the second for a two-dimensional array, and the offending, computed subscript expression was `-6'.
CHARACTER substring reference, the second line has
Attempt to access the 11-th element of variable a[start-substring].
This indicates that the offended
CHARACTER variable or array
is named `a',
the offended substring position is the starting (leftmost) position,
and the offending substring expression is `11'.
(Though the verbage of
s_rnge is not ideal
for the purpose of the g77 compiler,
the above information should provide adequate diagnostic abilities
to it users.)
See Options for Code Generation Conventions, for information on more options offered by the GBE shared by g77 gcc and other GNU compilers.
Some of these do not work when compiling programs written in Fortran:
libg2cwith which you will be linking all code compiled by g77 with the same option.
libg2clibrary, at the very least, even if it is built with the same option.