G77(1) GNU G77(1)
g77 - GNU project Fortran 77 compiler
[-g] [-pg] [-Olevel]
[-o outfile] infile...
Only the most useful options are listed here; see below for the remain-
The g77 command supports all the options supported by the gcc command.
All gcc and g77 options are accepted both by g77 and by gcc (as well as
any other drivers built at the same time, such as g++), since adding
g77 to the gcc distribution enables acceptance of g77 options by all of
the relevant drivers.
In some cases, options have positive and negative forms; the negative
form of -ffoo would be -fno-foo. This manual documents only one of
these two forms, whichever one is not the default.
Here is a summary of all the options specific to GNU Fortran, grouped
by type. Explanations are in the following sections.
-fversion -fset-g77-defaults -fno-silent
-ff66 -fno-f66 -ff77 -fno-f77 -fno-ugly
Fortran Language Options
-ffree-form -fno-fixed-form -ff90 -fvxt -fdollar-ok -fno-back-
slash -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
-fugly-comma -fugly-complex -fugly-init -fugly-logint -fonetrip
-ftypeless-boz -fintrin-case-initcap -fintrin-case-upper -fin-
trin-case-lower -fintrin-case-any -fmatch-case-initcap
-fmatch-case-upper -fmatch-case-lower -fmatch-case-any
-fsource-case-upper -fsource-case-lower -fsource-case-preserve
-fsymbol-case-initcap -fsymbol-case-upper -fsymbol-case-lower
-fsymbol-case-any -fcase-strict-upper -fcase-strict-lower
-fcase-initcap -fcase-upper -fcase-lower -fcase-preserve
-ff2c-intrinsics-delete -ff2c-intrinsics-hide -ff2c-intrin-
sics-disable -ff2c-intrinsics-enable -fbadu77-intrinsics-delete
-fbadu77-intrinsics-enable -ff90-intrinsics-delete -ff90-intrin-
sics-hide -ff90-intrinsics-disable -ff90-intrinsics-enable
-fgnu-intrinsics-delete -fgnu-intrinsics-hide -fgnu-intrin-
sics-disable -fgnu-intrinsics-enable -fmil-intrinsics-delete
-fmil-intrinsics-hide -fmil-intrinsics-disable -fmil-intrin-
sics-enable -funix-intrinsics-delete -funix-intrinsics-hide
-funix-intrinsics-disable -funix-intrinsics-enable -fvxt-intrin-
sics-delete -fvxt-intrinsics-hide -fvxt-intrinsics-disable
-fsyntax-only -pedantic -pedantic-errors -fpedantic -w
-Wno-globals -Wimplicit -Wunused -Wuninitialized -Wall -Wsur-
prising -Werror -W
-malign-double -ffloat-store -fforce-mem -fforce-addr
-fno-inline -ffast-math -fstrength-reduce -frerun-cse-after-loop
-funsafe-math-optimizations -ffinite-math-only -fno-trapping-math
-fexpensive-optimizations -fdelayed-branch -fschedule-insns
-fschedule-insn2 -fcaller-saves -funroll-loops -funroll-all-loops
-fno-move-all-movables -fno-reduce-all-givs -fno-rerun-loop-opt
Code Generation Options
-fno-automatic -finit-local-zero -fno-f2c -ff2c-library
-fno-underscoring -fno-ident -fpcc-struct-return
-freg-struct-return -fshort-double -fno-common -fpack-struct
-fzeros -fno-second-underscore -femulate-complex -falias-check
-fargument-alias -fargument-noalias -fno-argument-noalias-global
-fno-globals -fflatten-arrays -fbounds-check -ffor-
Compilation can involve as many as four stages: preprocessing, code
generation (often what is really meant by the term ''compilation''),
assembly, and linking, always in that order. The first three stages
apply to an individual source file, and end by producing an object
file; linking combines all the object files (those newly compiled, and
those specified as input) into an executable file.
For any given input file, the file name suffix determines what kind of
program is contained in the file---that is, the language in which the
program is written is generally indicated by the suffix. Suffixes spe-
cific to GNU Fortran are listed below.
Fortran source code that should not be preprocessed.
Such source code cannot contain any preprocessor directives, such
as "#include", "#define", "#if", and so on.
You can force .f files to be preprocessed by cpp by using -x
Fortran source code that must be preprocessed (by the C preproces-
sor cpp, which is part of GCC).
Note that preprocessing is not extended to the contents of files
included by the "INCLUDE" directive---the "#include" preprocessor
directive must be used instead.
Ratfor source code, which must be preprocessed by the ratfor com-
mand, which is available separately (as it is not yet part of the
GNU Fortran distribution). A public domain version in C is at
UNIX users typically use the file.f and file.F nomenclature. Users of
other operating systems, especially those that cannot distinguish
upper-case letters from lower-case letters in their file names, typi-
cally use the file.for and file.fpp nomenclature.
Use of the preprocessor cpp allows use of C-like constructs such as
"#define" and "#include", but can lead to unexpected, even mistaken,
results due to Fortran's source file format. It is recommended that
use of the C preprocessor be limited to "#include" and, in conjunction
with "#define", only "#if" and related directives, thus avoiding in-
line macro expansion entirely. This recommendation applies especially
when using the traditional fixed source form. With free source form,
fewer unexpected transformations are likely to happen, but use of con-
structs such as Hollerith and character constants can nevertheless
present problems, especially when these are continued across multiple
source lines. These problems result, primarily, from differences
between the way such constants are interpreted by the C preprocessor
and by a Fortran compiler.
Another example of a problem that results from using the C preprocessor
is that a Fortran comment line that happens to contain any characters
''interesting'' to the C preprocessor, such as a backslash at the end
of the line, is not recognized by the preprocessor as a comment line,
so instead of being passed through ''raw'', the line is edited accord-
ing to the rules for the preprocessor. For example, the backslash at
the end of the line is removed, along with the subsequent newline,
resulting in the next line being effectively commented out---unfortu-
nate if that line is a non-comment line of important code!
Note: The -traditional and -undef flags are supplied to cpp by default,
to help avoid unpleasant surprises.
This means that ANSI C preprocessor features (such as the # operator)
aren't available, and only variables in the C reserved namespace (gen-
erally, names with a leading underscore) are liable to substitution by
C predefines. Thus, if you want to do system-specific tests, use, for
example, #ifdef __linux__ rather than #ifdef linux. Use the -v option
to see exactly how the preprocessor is invoked.
Unfortunately, the -traditional flag will not avoid an error from any-
thing that cpp sees as an unterminated C comment, such as:
C Some Fortran compilers accept /* as starting
C an inline comment.
The following options that affect overall processing are recognized by
the g77 and gcc commands in a GNU Fortran installation:
Ensure that the g77 version of the compiler phase is reported, if
run, and, starting in "egcs" version 1.1, that internal consistency
checks in the f771 program are run.
This option is supplied automatically when -v or --verbose is spec-
ified as a command-line option for g77 or gcc and when the result-
ing commands compile Fortran source files.
In GCC 3.1, this is changed back to the behavior gcc displays for
Version info: This option was obsolete as of "egcs" version 1.1.
The effect is instead achieved by the "lang_init_options" routine
Set up whatever gcc options are to apply to Fortran compilations,
and avoid running internal consistency checks that might take some
This option is supplied automatically when compiling Fortran code
via the g77 or gcc command. The description of this option is pro-
vided so that users seeing it in the output of, say, g77 -v under-
stand why it is there.
Also, developers who run "f771" directly might want to specify it
by hand to get the same defaults as they would running "f771" via
g77 or gcc However, such developers should, after linking a new
"f771" executable, invoke it without this option once, e.g. via
"./f771 -quiet < /dev/null", to ensure that they have not intro-
duced any internal inconsistencies (such as in the table of intrin-
sics) before proceeding---g77 will crash with a diagnostic if it
detects an inconsistency.
Print (to "stderr") the names of the program units as they are com-
piled, in a form similar to that used by popular UNIX f77 implemen-
tations and f2c
The following options serve as ''shorthand'' for other options accepted
by the compiler:
Note: This option is no longer supported. The information, below,
is provided to aid in the conversion of old scripts.
Specify that certain ''ugly'' constructs are to be quietly
accepted. Same as:
-fugly-args -fugly-assign -fugly-assumed
-fugly-comma -fugly-complex -fugly-init
These constructs are considered inappropriate to use in new or
well-maintained portable Fortran code, but widely used in old code.
Specify that all ''ugly'' constructs are to be noisily rejected.
-fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
-fno-ugly-comma -fno-ugly-complex -fno-ugly-init
Specify that the program is written in idiomatic FORTRAN 66. Same
as -fonetrip -fugly-assumed.
The -fno-f66 option is the inverse of -ff66. As such, it is the
same as -fno-onetrip -fno-ugly-assumed.
The meaning of this option is likely to be refined as future ver-
sions of g77 provide more compatibility with other existing and
obsolete Fortran implementations.
Specify that the program is written in idiomatic UNIX FORTRAN 77
and/or the dialect accepted by the f2c product. Same as -fback-
The meaning of this option is likely to be refined as future ver-
sions of g77 provide more compatibility with other existing and
obsolete Fortran implementations.
The -fno-f77 option is not the inverse of -ff77. It specifies that
the program is not written in idiomatic UNIX FORTRAN 77 or f2c but
in a more widely portable dialect. -fno-f77 is the same as
The meaning of this option is likely to be refined as future ver-
sions of g77 provide more compatibility with other existing and
obsolete Fortran implementations.
Options Controlling Fortran Dialect
The following options control the dialect of Fortran that the compiler
Specify that the source file is written in free form (introduced in
Fortran 90) instead of the more-traditional fixed form.
Allow certain Fortran-90 constructs.
This option controls whether certain Fortran 90 constructs are rec-
ognized. (Other Fortran 90 constructs might or might not be recog-
nized depending on other options such as -fvxt, -ff90-intrin-
sics-enable, and the current level of support for Fortran 90.)
Specify the treatment of certain constructs that have different
meanings depending on whether the code is written in GNU Fortran
(based on FORTRAN 77 and akin to Fortran 90) or VXT Fortran (more
like VAX FORTRAN).
The default is -fno-vxt. -fvxt specifies that the VXT Fortran
interpretations for those constructs are to be chosen.
Allow $ as a valid character in a symbol name.
Specify that \ is not to be specially interpreted in character and
Hollerith constants a la C and many UNIX Fortran compilers.
For example, with -fbackslash in effect, A\nB specifies three char-
acters, with the second one being newline. With -fno-backslash, it
specifies four characters, A, \, n, and B.
Note that g77 implements a fairly general form of backslash pro-
cessing that is incompatible with the narrower forms supported by
some other compilers. For example, 'A\003B' is a three-character
string in g77 whereas other compilers that support backslash might
not support the three-octal-digit form, and thus treat that string
as longer than three characters.
Disallow passing Hollerith and typeless constants as actual argu-
ments (for example, CALL FOO(4HABCD)).
Use the same storage for a given variable regardless of whether it
is used to hold an assigned-statement label (as in ASSIGN 10 TO I)
or used to hold numeric data (as in I = 3).
Assume any dummy array with a final dimension specified as 1 is
really an assumed-size array, as if * had been specified for the
final dimension instead of 1.
For example, DIMENSION X(1) is treated as if it had read DIMENSION
In an external-procedure invocation, treat a trailing comma in the
argument list as specification of a trailing null argument, and
treat an empty argument list as specification of a single null
For example, CALL FOO(,) is treated as CALL FOO(%VAL(0), %VAL(0)).
That is, two null arguments are specified by the procedure call
when -fugly-comma is in force. And F = FUNC() is treated as F =
The default behavior, -fno-ugly-comma, is to ignore a single trail-
ing comma in an argument list. So, by default, CALL FOO(X,) is
treated exactly the same as CALL FOO(X).
Do not complain about REAL(expr) or AIMAG(expr) when expr is a
"COMPLEX" type other than "COMPLEX(KIND=1)"---usually this is used
to permit "COMPLEX(KIND=2)" ("DOUBLE COMPLEX") operands.
The -ff90 option controls the interpretation of this construct.
Disallow use of Hollerith and typeless constants as initial values
(in "PARAMETER" and "DATA" statements), and use of character con-
stants to initialize numeric types and vice versa.
For example, DATA I/'F'/, CHRVAR/65/, J/4HABCD/ is disallowed by
Treat "INTEGER" and "LOGICAL" variables and expressions as poten-
tial stand-ins for each other.
For example, automatic conversion between "INTEGER" and "LOGICAL"
is enabled, for many contexts, via this option.
Executable iterative "DO" loops are to be executed at least once
each time they are reached.
ANSI FORTRAN 77 and more recent versions of the Fortran standard
specify that the body of an iterative "DO" loop is not executed if
the number of iterations calculated from the parameters of the loop
is less than 1. (For example, DO 10 I = 1, 0.) Such a loop is
called a zero-trip loop.
Prior to ANSI FORTRAN 77, many compilers implemented "DO" loops
such that the body of a loop would be executed at least once, even
if the iteration count was zero. Fortran code written assuming
this behavior is said to require one-trip loops. For example, some
code written to the FORTRAN 66 standard expects this behavior from
its "DO" loops, although that standard did not specify this behav-
The -fonetrip option specifies that the source file(s) being
compiled require one-trip loops.
This option affects only those loops specified by the (iterative)
"DO" statement and by implied-"DO" lists in I/O statements. Loops
specified by implied-"DO" lists in "DATA" and specification
(non-executable) statements are not affected.
Specifies that prefix-radix non-decimal constants, such as Z'ABCD',
are typeless instead of "INTEGER(KIND=1)".
You can test for yourself whether a particular compiler treats the
prefix form as "INTEGER(KIND=1)" or typeless by running the follow-
EQUIVALENCE (I, R)
R = Z'ABCD1234'
J = Z'ABCD1234'
IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
Reports indicate that many compilers process this form as "INTE-
GER(KIND=1)", though a few as typeless, and at least one based on a
command-line option specifying some kind of compatibility.
Specify expected case for intrinsic names. -fintrin-case-lower is
Specify expected case for keywords. -fmatch-case-lower is the
Specify whether source text other than character and Hollerith con-
stants is to be translated to uppercase, to lowercase, or preserved
as is. -fsource-case-lower is the default.
Specify valid cases for user-defined symbol names. -fsym-
bol-case-any is the default.
Same as -fintrin-case-upper -fmatch-case-upper -fsource-case-pre-
serve -fsymbol-case-upper. (Requires all pertinent source to be in
Same as -fintrin-case-lower -fmatch-case-lower -fsource-case-pre-
serve -fsymbol-case-lower. (Requires all pertinent source to be in
Same as -fintrin-case-initcap -fmatch-case-initcap
-fsource-case-preserve -fsymbol-case-initcap. (Requires all
pertinent source to be in initial capitals, as in Print
Same as -fintrin-case-any -fmatch-case-any -fsource-case-upper
-fsymbol-case-any. (Maps all pertinent source to uppercase.)
Same as -fintrin-case-any -fmatch-case-any -fsource-case-lower
-fsymbol-case-any. (Maps all pertinent source to lowercase.)
Same as -fintrin-case-any -fmatch-case-any -fsource-case-preserve
-fsymbol-case-any. (Preserves all case in user-defined symbols,
while allowing any-case matching of intrinsics and keywords. For
example, call Foo(i,I) would pass two different variables named i
and I to a procedure named Foo.)
Specify status of UNIX intrinsics having inappropriate forms.
-fbadu77-intrinsics-enable is the default.
Specify status of f2c-specific intrinsics. -ff2c-intrinsics-enable
is the default.
Specify status of F90-specific intrinsics. -ff90-intrinsics-enable
is the default.
Specify status of Digital's COMPLEX-related intrinsics.
-fgnu-intrinsics-enable is the default.
Specify status of MIL-STD-1753-specific intrinsics. -fmil-intrin-
sics-enable is the default.
Specify status of UNIX intrinsics. -funix-intrinsics-enable is the
Specify status of VXT intrinsics. -fvxt-intrinsics-enable is the
Set column after which characters are ignored in typical fixed-form
lines in the source file, and through which spaces are assumed (as
if padded to that length) after the ends of short fixed-form lines.
Popular values for n include 72 (the standard and the default), 80
(card image), and 132 (corresponds to ''extended-source'' options
in some popular compilers). n may be none, meaning that the entire
line is meaningful and that continued character constants never
have implicit spaces appended to them to fill out the line.
-ffixed-line-length-0 means the same thing as
Options to Request or Suppress Warnings
Warnings are diagnostic messages that report constructions which are
not inherently erroneous but which are risky or suggest there might
have been an error.
You can request many specific warnings with options beginning -W, for
example -Wimplicit to request warnings on implicit declarations. Each
of these specific warning options also has a negative form beginning
-Wno- to turn off warnings; for example, -Wno-implicit. This manual
lists only one of the two forms, whichever is not the default.
These options control the amount and kinds of warnings produced by GNU
Check the code for syntax errors, but don't do anything beyond
Issue warnings for uses of extensions to ANSI FORTRAN 77. -pedan-
tic also applies to C-language constructs where they occur in GNU
Fortran source files, such as use of \e in a character constant
within a directive like #include.
Valid ANSI FORTRAN 77 programs should compile properly with or
without this option. However, without this option, certain GNU
extensions and traditional Fortran features are supported as well.
With this option, many of them are rejected.
Some users try to use -pedantic to check programs for strict ANSI
conformance. They soon find that it does not do quite what they
want---it finds some non-ANSI practices, but not all. However,
improvements to g77 in this area are welcome.
Like -pedantic, except that errors are produced rather than warn-
Like -pedantic, but applies only to Fortran constructs.
-w Inhibit all warning messages.
Inhibit warnings about use of a name as both a global name (a sub-
routine, function, or block data program unit, or a common block)
and implicitly as the name of an intrinsic in a source file.
Also inhibit warnings about inconsistent invocations and/or defini-
tions of global procedures (function and subroutines). Such incon-
sistencies include different numbers of arguments and different
types of arguments.
Warn whenever a variable, array, or function is implicitly
declared. Has an effect similar to using the "IMPLICIT NONE"
statement in every program unit. (Some Fortran compilers provide
this feature by an option named -u or /WARNINGS=DECLARATIONS.)
Warn whenever a variable is unused aside from its declaration.
Warn whenever an automatic variable is used without first being
These warnings are possible only in optimizing compilation, because
they require data-flow information that is computed only when opti-
mizing. If you don't specify -O, you simply won't get these warn-
These warnings occur only for variables that are candidates for
register allocation. Therefore, they do not occur for a variable
whose address is taken, or whose size is other than 1, 2, 4 or 8
bytes. Also, they do not occur for arrays, even when they are in
Note that there might be no warning about a variable that is used
only to compute a value that itself is never used, because such
computations may be deleted by data-flow analysis before the warn-
ings are printed.
These warnings are made optional because GNU Fortran is not smart
enough to see all the reasons why the code might be correct despite
appearing to have an error. Here is one example of how this can
IF (J.EQ.1) I=1
IF (J.EQ.2) I=4
IF (J.EQ.3) I=5
If the value of "J" is always 1, 2 or 3, then "I" is always ini-
tialized, but GNU Fortran doesn't know this. Here is another com-
IF (FLAG) VALUE = 9.4
IF (FLAG) PRINT *, VALUE
This has no bug because "VALUE" is used only if it is set.
The -Wunused and -Wuninitialized options combined. These are all
the options which pertain to usage that we recommend avoiding and
that we believe is easy to avoid. (As more warnings are added to
g77 some might be added to the list enabled by -Wall.)
The remaining -W... options are not implied by -Wall because they warn
about constructions that we consider reasonable to use, on occasion, in
Warn about ''suspicious'' constructs that are interpreted by the
compiler in a way that might well be surprising to someone reading
the code. These differences can result in subtle, compiler-depen-
dent (even machine-dependent) behavioral differences. The con-
structs warned about include:
* Expressions having two arithmetic operators in a row, such as
X*-Y. Such a construct is nonstandard, and can produce unex-
pected results in more complicated situations such as X**-Y*Z.
g77 along with many other compilers, interprets this example
differently than many programmers, and a few other compilers.
Specifically, g77 interprets X**-Y*Z as (X**(-Y))*Z, while oth-
ers might think it should be interpreted as X**(-(Y*Z)).
A revealing example is the constant expression 2**-2*1., which
g77 evaluates to .25, while others might evaluate it to 0., the
difference resulting from the way precedence affects type pro-
(The -fpedantic option also warns about expressions having two
arithmetic operators in a row.)
* Expressions with a unary minus followed by an operand and then
a binary operator other than plus or minus. For example, -2**2
produces a warning, because the precedence is -(2**2), yielding
-4, not (-2)**2, which yields 4, and which might represent what
a programmer expects.
An example of an expression producing different results in a
surprising way is -I*S, where I holds the value -2147483648 and
S holds 0.5. On many systems, negating I results in the same
value, not a positive number, because it is already the lower
bound of what an "INTEGER(KIND=1)" variable can hold. So, the
expression evaluates to a positive number, while the
''expected'' interpretation, (-I)*S, would evaluate to a nega-
Even cases such as -I*J produce warnings, even though, in most
configurations and situations, there is no computational dif-
ference between the results of the two interpretations---the
purpose of this warning is to warn about differing interpreta-
tions and encourage a better style of coding, not to identify
only those places where bugs might exist in the user's code.
* "DO" loops with "DO" variables that are not of integral
type---that is, using "REAL" variables as loop control vari-
ables. Although such loops can be written to work in the
''obvious'' way, the way g77 is required by the Fortran stan-
dard to interpret such code is likely to be quite different
from the way many programmers expect. (This is true of all
"DO" loops, but the differences are pronounced for non-integral
loop control variables.)
Make all warnings into errors.
-W Turns on ''extra warnings'' and, if optimization is specified via
-O, the -Wuninitialized option. (This might change in future ver-
sions of g77
''Extra warnings'' are issued for:
* Unused parameters to a procedure (when -Wunused also is speci-
* Overflows involving floating-point constants (not available for
Some of these have no effect when compiling programs written in
These options all could have some relevant meaning for GNU Fortran
programs, but are not yet supported.
Options for Debugging Your Program or GNU Fortran
GNU Fortran has various special options that are used for debugging
either your program or g77
-g Produce debugging information in the operating system's native for-
mat (stabs, COFF, XCOFF, or DWARF). GDB can work with this debug-
A sample debugging session looks like this (note the use of the
$ cat gdb.f
DATA A /1.,2.,3.,4.,5.,6.,7.,8.,9.,10./
A(5) = 4.
$ g77 -g -O gdb.f
$ gdb a.out
(gdb) break MAIN__
Breakpoint 1 at 0x8048e96: file gdb.f, line 4.
Starting program: /home/toon/g77-bugs/./a.out
Breakpoint 1, MAIN__ () at gdb.f:4
4 A(5) = 4.
Current language: auto; currently fortran
(gdb) print a(5)
$1 = 5
(gdb) print a(5)
$2 = 4
One could also add the setting of the breakpoint and the first run
command to the file .gdbinit in the current directory, to simplify
the debugging session.
Options That Control Optimization
Most Fortran users will want to use no optimization when developing and
testing programs, and use -O or -O2 when compiling programs for late-
cycle testing and for production use. However, note that certain diag-
nostics---such as for uninitialized variables---depend on the flow
analysis done by -O, i.e. you must use -O or -O2 to get such diagnos-
The following flags have particular applicability when compiling For-
(Intel x86 architecture only.)
Noticeably improves performance of g77 programs making heavy use of
"REAL(KIND=2)" ("DOUBLE PRECISION") data on some systems. In par-
ticular, systems using Pentium, Pentium Pro, 586, and 686 implemen-
tations of the i386 architecture execute programs faster when
"REAL(KIND=2)" ("DOUBLE PRECISION") data are aligned on 64-bit
boundaries in memory.
This option can, at least, make benchmark results more consistent
across various system configurations, versions of the program, and
Note: The warning in the gcc documentation about this option does
not apply, generally speaking, to Fortran code compiled by g77
Also also note: The negative form of -malign-double is
-mno-align-double, not -benign-double.
Might help a Fortran program that depends on exact IEEE conformance
on some machines, but might slow down a program that doesn't.
This option is effective when the floating-point unit is set to
work in IEEE 854 'extended precision'---as it typically is on x86
and m68k GNU systems---rather than IEEE 754 double precision.
-ffloat-store tries to remove the extra precision by spilling data
from floating-point registers into memory and this typically
involves a big performance hit. However, it doesn't affect inter-
mediate results, so that it is only partially effective. 'Excess
precision' is avoided in code like:
a = b + c
d = a * e
but not in code like:
d = (b + c) * e
For another, potentially better, way of controlling the precision,
see Floating-point precision.
Might improve optimization of loops.
Don't compile statement functions inline. Might reduce the size of
a program unit---which might be at expense of some speed (though it
should compile faster). Note that if you are not optimizing, no
functions can be expanded inline.
Might allow some programs designed to not be too dependent on IEEE
behavior for floating-point to run faster, or die trying. Sets
-funsafe-math-optimizations, -ffinite-math-only, and -fno-trap-
Allow optimizations that may be give incorrect results for certain
Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.
This option should never be turned on by any -O option since it can
result in incorrect output for programs which depend on an exact
implementation of IEEE or ISO rules/specifications.
The default is -fno-finite-math-only.
Allow the compiler to assume that floating-point arithmetic will
not generate traps on any inputs. This is useful, for example,
when running a program using IEEE "non-stop" floating-point arith-
Might make some loops run faster.
Might improve performance on some code.
Typically improves performance on code using iterative "DO" loops
by unrolling them and is probably generally appropriate for For-
tran, though it is not turned on at any optimization level. Note
that outer loop unrolling isn't done specifically; decisions about
whether to unroll a loop are made on the basis of its instruction
Also, no 'loop discovery' is done, so only loops written with
"DO" benefit from loop optimizations, including---but not limited
to---unrolling. Loops written with "IF" and "GOTO" are not cur-
rently recognized as such. This option unrolls only iterative "DO"
loops, not "DO WHILE" loops.
Probably improves performance on code using "DO WHILE" loops by
unrolling them in addition to iterative "DO" loops. In the absence
of "DO WHILE", this option is equivalent to -funroll-loops but pos-
In general, the optimizations enabled with these options will lead
to faster code being generated by GNU Fortran; hence they are
enabled by default when issuing the g77 command.
-fmove-all-movables and -freduce-all-givs will enable loop opti-
mization to move all loop-invariant index computations in nested
loops over multi-rank array dummy arguments out of these loops.
-frerun-loop-opt will move offset calculations resulting from the
fact that Fortran arrays by default have a lower bound of 1 out of
These three options are intended to be removed someday, once loop
optimization is sufficiently advanced to perform all those trans-
formations without help from these options.
Options Controlling the Preprocessor
These options control the C preprocessor, which is run on each C source
file before actual compilation.
Some of these options also affect how g77 processes the "INCLUDE"
directive. Since this directive is processed even when preprocessing
is not requested, it is not described in this section.
However, the "INCLUDE" directive does not apply preprocessing to the
contents of the included file itself.
Therefore, any file that contains preprocessor directives (such as
"#include", "#define", and "#if") must be included via the "#include"
directive, not via the "INCLUDE" directive. Therefore, any file con-
taining preprocessor directives, if included, is necessarily included
by a file that itself contains preprocessor directives.
Options for Directory Search
These options affect how the cpp preprocessor searches for files speci-
fied via the "#include" directive. Therefore, when compiling Fortran
programs, they are meaningful when the preprocessor is used.
Some of these options also affect how g77 searches for files specified
via the "INCLUDE" directive, although files included by that directive
are not, themselves, preprocessed. These options are:
These affect interpretation of the "INCLUDE" directive (as well as
of the "#include" directive of the cpp preprocessor).
Note that -Idir must be specified without any spaces between -I and
the directory name---that is, -Ifoo/bar is valid, but -I foo/bar is
rejected by the g77 compiler (though the preprocessor supports the
latter form). Also note that the general behavior of -I and
"INCLUDE" is pretty much the same as of -I with "#include" in the
cpp preprocessor, with regard to looking for header.gcc files and
other such things.
Options for Code Generation Conventions
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.
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.)
Specify that variables and arrays that are local to a program unit
(not in a common block and not passed as an argument) are to be
initialized to binary zeros.
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.
Do not generate code designed to be compatible with code generated
by f2c use the GNU calling conventions instead.
The f2c calling conventions require functions that return type
"REAL(KIND=1)" to actually return the C type "double", and func-
tions 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---"REAL(KIND=1)"
functions return the C type "float", and "COMPLEX" functions return
the GNU C type "complex" (or its "struct" equivalent).
This does not affect the generation of code that interfaces with
the "libg2c" library.
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 call-
ing 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.
Specify that use of "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.
Do not transform names of entities specified in the Fortran source
file by appending underscores to them.
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 trans-
Use of -fno-underscoring is not recommended unless you are experi-
menting 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
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 nor-
mally cannot detect disagreements in these other areas.
Also, note that with -fno-underscoring, the lack of appended under-
scores 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
Do not append a second underscore to names of entities specified in
the Fortran source file.
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__.
Ignore the #ident directive.
Treat initial values of zero as if they were any other value.
As of version 0.5.18, g77 normally treats "DATA" and other state-
ments 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 are pro-
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 initializa-
tions, zero or otherwise.
Caution: Future versions of g77 might disregard this option (and
its negative form, the default) or interpret it somewhat differ-
ently. The interpretation changes will affect only non-standard
programs; standard-conforming programs should not be affected.
Implement "COMPLEX" arithmetic 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 for "complex" arith-
metic, due primarily to the support not being completed as of ver-
sion 2.8.1 and "egcs" 1.1.2.)
Use -femulate-complex if you suspect code-generation bugs, or expe-
rience compiler crashes, that might result from g77 using the "COM-
PLEX" support 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
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 com-
piled 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
Version info: These options are not supported by versions of g77
based on gcc version 2.8.
These options specify to what degree aliasing (overlap) is permit-
ted between arguments (passed as pointers) and "COMMON" (external,
or public) storage.
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).
Disable diagnostics about inter-procedural analysis problems, such
as disagreements about the type of a function or a procedure's
argument, that might cause a compiler crash when attempting to
inline a reference to a procedure within a program unit. (The
diagnostics themselves are still produced, but as warnings, unless
-Wno-globals is specified, in which case no relevant diagnostics
Further, this option disables such inlining, to avoid compiler
crashes resulting from incorrect code that would otherwise be diag-
As such, this option might be quite useful when compiling existing,
''working'' code that happens to have a few bugs that do not gener-
ally 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 incor-
Use back end's C-like constructs (pointer plus offset) instead of
its "ARRAY_REF" construct 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.
Enable generation of run-time checks for array subscripts and sub-
string start and end points against the (locally) declared minimum
and maximum values.
The current implementation uses the "libf2c" library routine
"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-check-
ing 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 sub-
script, g77 provides the "libg2c" run-time library routine "s_rnge"
with somewhat differently-formatted information. Here's a sample
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].
The above message indicates that the offending source line is line
4 of the file rnge.f, within the program unit (or statement func-
tion) 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.
For a "CHARACTER" substring reference, the second line has this
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 diag-
nostic abilities to it users.)
Some of these do not work when compiling programs written in Fortran:
You should not use these except strictly the same way as you used
them to build the version of "libg2c" with which you will be link-
ing all code compiled by g77 with the same option.
This probably either has no effect on Fortran programs, or makes
them act loopy.
Do not use this when compiling Fortran programs, or there will be
This probably will break any calls to the "libg2c" library, at the
very least, even if it is built with the same option.
GNU Fortran currently does not make use of any environment variables to
control its operation above and beyond those that affect the operation
For instructions on reporting bugs, see <http://gcc.gnu.org/bugs.html>.
Use of the gccbug script to report bugs is recommended.
1. loop discovery refers to the process by which a compiler, or indeed
any reader of a program, determines which portions of the program
are more likely to be executed repeatedly as it is being run. Such
discovery typically is done early when compiling using optimization
techniques, so the ''discovered'' loops get more attention---and
more run-time resources, such as registers---from the compiler. It
is easy to ''discover'' loops that are constructed out of looping
constructs in the language (such as Fortran's "DO"). For some pro-
grams, ''discovering'' loops constructed out of lower-level con-
structs (such as "IF" and "GOTO") can lead to generation of more
optimal code than otherwise.
gpl(7), gfdl(7), fsf-funding(7), cpp(1), gcov(1), gcc(1), as(1), ld(1),
gdb(1), adb(1), dbx(1), sdb(1) and the Info entries for gcc, cpp, g77,
as, ld, binutils and gdb.
See the Info entry for g77 for contributors to GCC and G77.
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2004 Free Soft-
ware Foundation, Inc.
Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being ''GNU General Public License'' and ''Funding
Free Software'', the Front-Cover texts being (a) (see below), and with
the Back-Cover Texts being (b) (see below). A copy of the license is
included in the gfdl(7) man page.
(a) The FSF's Front-Cover Text is:
A GNU Manual
(b) The FSF's Back-Cover Text is:
You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.
gcc-3.4.6 2011-01-30 G77(1)