Home Man
Today's Posts

Linux & Unix Commands - Search Man Pages

RedHat 9 (Linux i386) - man page for g77 (redhat section 1)

G77(1)					       GNU					   G77(1)

       g77 - GNU project Fortran 77 compiler

       g77 [-c|-S|-E]
	   [-g] [-pg] [-Olevel]
	   [-Wwarn...] [-pedantic]
	   [-Idir...] [-Ldir...]
	   [-Dmacro[=defn]...] [-Umacro]
	   [-foption...] [-mmachine-option...]
	   [-o outfile] infile...

       Only the most useful options are listed here; see below for the remainder.

       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

       Here is a summary of all the options specific to GNU Fortran, grouped by type.  Explana-
       tions are in the following sections.

       Overall Options
	   -fversion  -fset-g77-defaults  -fno-silent

       Shorthand Options
	   -ff66  -fno-f66  -ff77  -fno-f77  -fno-ugly

       Fortran Language Options
	   -ffree-form	-fno-fixed-form  -ff90 -fvxt  -fdollar-ok  -fno-backslash -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
	   -fintrin-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-intrin-
	   sics-hide -ff2c-intrinsics-disable  -ff2c-intrinsics-enable -fbadu77-intrinsics-delete
	   -fbadu77-intrinsics-hide -fbadu77-intrinsics-disable  -fbadu77-intrinsics-enable
	   -ff90-intrinsics-delete  -ff90-intrinsics-hide -ff90-intrinsics-disable  -ff90-intrin-
	   sics-enable -fgnu-intrinsics-delete	-fgnu-intrinsics-hide -fgnu-intrinsics-disable
	   -fgnu-intrinsics-enable -fmil-intrinsics-delete  -fmil-intrinsics-hide -fmil-intrin-
	   sics-disable  -fmil-intrinsics-enable -funix-intrinsics-delete  -funix-intrinsics-hide
	   -funix-intrinsics-disable  -funix-intrinsics-enable -fvxt-intrinsics-delete
	   -fvxt-intrinsics-hide -fvxt-intrinsics-disable  -fvxt-intrinsics-enable
	   -ffixed-line-length-n  -ffixed-line-length-none

       Warning Options
	   -fsyntax-only  -pedantic  -pedantic-errors  -fpedantic -w  -Wno-globals  -Wimplicit
	   -Wunused  -Wuninitialized -Wall  -Wsurprising -Werror  -W

       Debugging Options

       Optimization Options
	   -malign-double -ffloat-store  -fforce-mem  -fforce-addr  -fno-inline -ffast-math
	   -fstrength-reduce  -frerun-cse-after-loop -funsafe-math-optimizations -fno-trap-
	   ping-math -fexpensive-optimizations	-fdelayed-branch -fschedule-insns  -fsched-
	   ule-insn2  -fcaller-saves -funroll-loops  -funroll-all-loops -fno-move-all-movables
	   -fno-reduce-all-givs -fno-rerun-loop-opt

       Directory Options
	   -Idir  -I-

       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  -fargu-
	   ment-alias -fargument-noalias  -fno-argument-noalias-global -fno-globals  -fflat-
	   ten-arrays -fbounds-check  -ffortran-bounds-check

       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 con-
       tained in the file---that is, the language in which the program is written is generally
       indicated by the suffix.  Suffixes specific 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 f77-cpp-input.

	   Fortran source code that must be preprocessed (by the C preprocessor cpp, which is
	   part of GNU CC).

	   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 command, which is avail-
	   able separately (as it is not yet part of the GNU Fortran distribution).  One version
	   in Fortran, adapted for use with g77 is at <ftp://members.aol.com/n8tm/rat7.uue> (of
	   uncertain copyright status).  Another, public domain version in C is at <http://sep-

       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 let-
       ters in their file names, typically 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 tra-
       ditional fixed source form.  With free source form, fewer unexpected transformations are
       likely to happen, but use of constructs such as Hollerith and character constants can nev-
       ertheless 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 according 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---unfortunate 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 (generally, names with a leading under-
       score) are liable to substitution by C predefines.  Thus, if you want to do system-spe-
       cific 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 anything 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 specified as a command-
	   line option for g77 or gcc and when the resulting commands compile Fortran source

	   In GCC 3.1, this is changed back to the behaviour gcc displays for .c files.

	   Version info: This option was obsolete as of "egcs" version 1.1.  The effect is
	   instead achieved by the "lang_init_options" routine in gcc/gcc/f/com.c.

	   Set up whatever gcc options are to apply to Fortran compilations, and avoid running
	   internal consistency checks that might take some time.

	   This option is supplied automatically when compiling Fortran code via the g77 or gcc
	   command.  The description of this option is provided so that users seeing it in the
	   output of, say, g77 -v understand 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 introduced any
	   internal inconsistencies (such as in the table of intrinsics) 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 compiled, in a form
	   similar to that used by popular UNIX f77 implementations and f2c

       Shorthand Options

       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 porta-
	   ble Fortran code, but widely used in old code.

	   Specify that all ``ugly'' constructs are to be noisily rejected.  Same as:

		   -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

	   The -fno-f66 option is the inverse of -ff66.  As such, it is the same as -fno-onetrip

	   The meaning of this option is likely to be refined as future versions 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 -fbackslash -fno-typeless-boz.

	   The meaning of this option is likely to be refined as future versions 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 -fno-backslash.

	   The meaning of this option is likely to be refined as future versions 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 accepts:

	   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 recognized.  (Other
	   Fortran 90 constructs might or might not be recognized depending on other options such
	   as -fvxt, -ff90-intrinsics-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 characters, 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 processing that is incom-
	   patible 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 back-
	   slash 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 arguments (for example,

	   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 X(*).

	   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 speci-
	   fication of a single null argument.

	   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 = FUNC(%VAL(0)).

	   The default behavior, -fno-ugly-comma, is to ignore a single trailing comma in an
	   argument list.  So, by default, CALL FOO(X,) is treated exactly the same as CALL

	   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 constants to initialize numeric types and
	   vice versa.

	   For example, DATA I/'F'/, CHRVAR/65/, J/4HABCD/ is disallowed by -fno-ugly-init.

	   Treat "INTEGER" and "LOGICAL" variables and expressions as potential 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

	   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 behavior.

	   The -fonetrip option specifies that the source file(s) being compiled require one-trip

	   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 following program:

		   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 "INTEGER(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 the default.

	   Specify expected case for keywords.	-fmatch-case-lower is the default.

	   Specify whether source text other than character and Hollerith constants is to be
	   translated to uppercase, to lowercase, or preserved as is.  -fsource-case-lower is the

	   Specify valid cases for user-defined symbol names.  -fsymbol-case-any is the default.

	   Same as -fintrin-case-upper -fmatch-case-upper -fsource-case-preserve -fsym-
	   bol-case-upper.  (Requires all pertinent source to be in uppercase.)

	   Same as -fintrin-case-lower -fmatch-case-lower -fsource-case-preserve -fsym-
	   bol-case-lower.  (Requires all pertinent source to be in lowercase.)

	   Same as -fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve -fsym-
	   bol-case-initcap.  (Requires all pertinent source to be in initial capitals, as in
	   Print *,SqRt(Value).)

	   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 vari-
	   ables named i and I to a procedure named Foo.)

	   Specify status of UNIX intrinsics having inappropriate forms.  -fbadu77-intrin-
	   sics-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-intrinsics-enable is the

	   Specify status of UNIX intrinsics.  -funix-intrinsics-enable is the default.

	   Specify status of VXT intrinsics.  -fvxt-intrinsics-enable is the default.

	   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 con-
	   stants never have implicit spaces appended to them to fill out the line.
	   -ffixed-line-length-0 means the same thing as -ffixed-line-length-none.

       Options to Request or Suppress Warnings

       Warnings are diagnostic messages that report constructions which are not inherently erro-
       neous 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 Fortran:

	   Check the code for syntax errors, but don't do anything beyond that.

	   Issue warnings for uses of extensions to ANSI FORTRAN 77.  -pedantic 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 warnings.

	   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 subroutine, 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 definitions of global pro-
	   cedures (function and subroutines).	Such inconsistencies 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 initialized.

	   These warnings are possible only in optimizing compilation, because they require data-
	   flow information that is computed only when optimizing.  If you don't specify -O, you
	   simply won't get these warnings.

	   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 registers.

	   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 warnings 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 happen:

		   IF (J.EQ.1) I=1
		   IF (J.EQ.2) I=4
		   IF (J.EQ.3) I=5
		   CALL FOO(I)

	   If the value of "J" is always 1, 2 or 3, then "I" is always initialized, but GNU For-
	   tran doesn't know this.  Here is another common case:

		   IF (FLAG) VALUE = 9.4

	   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 clean programs.

	   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-dependent (even machine-dependent) behavioral differences.
	   The constructs warned about include:

	   o   Expressions having two arithmetic operators in a row, such as X*-Y.  Such a con-
	       struct is nonstandard, and can produce unexpected results in more complicated sit-
	       uations such as X**-Y*Z.  g77 along with many other compilers, interprets this
	       example differently than many programmers, and a few other compilers.  Specifi-
	       cally, g77 interprets X**-Y*Z as (X**(-Y))*Z, while others 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 promotion.

	       (The -fpedantic option also warns about expressions having two arithmetic opera-
	       tors in a row.)

	   o   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 expres-
	       sion evaluates to a positive number, while the ``expected'' interpretation,
	       (-I)*S, would evaluate to a negative number.

	       Even cases such as -I*J produce warnings, even though, in most configurations and
	       situations, there is no computational difference between the results of the two
	       interpretations---the purpose of this warning is to warn about differing interpre-
	       tations and encourage a better style of coding, not to identify only those places
	       where bugs might exist in the user's code.

	   o   "DO" loops with "DO" variables that are not of integral type---that is, using
	       "REAL" variables as loop control variables.  Although such loops can be written to
	       work in the ``obvious'' way, the way g77 is required by the Fortran standard 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 -Wuninitial-
	   ized option.  (This might change in future versions of g77

	   ``Extra warnings'' are issued for:

	   o   Unused parameters to a procedure (when -Wunused also is specified).

	   o   Overflows involving floating-point constants (not available for certain configura-

       Some of these have no effect when compiling programs written in Fortran:

	   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

       -g  Produce debugging information in the operating system's native format (stabs, COFF,
	   XCOFF, or DWARF).  GDB can work with this debugging information.

	   A sample debugging session looks like this (note the use of the breakpoint):

		   $ 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.
		   (gdb) run
		   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) step
		   5		 PRINT*,A
		   (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 diagnostics---such as for uninitialized variables---depend on
       the flow analysis done by -O, i.e. you must use -O or -O2 to get such diagnostics.

       The following flags have particular applicability when compiling Fortran programs:

	   (Intel x86 architecture only.)

	   Noticeably improves performance of g77 programs making heavy use of "REAL(KIND=2)"
	   ("DOUBLE PRECISION") data on some systems.  In particular, systems using Pentium, Pen-
	   tium Pro, 586, and 686 implementations 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 sys-
	   tem configurations, versions of the program, and data sets.

	   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

	   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 intermediate 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 @ref{Float-
	   ing-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 float-
	   ing-point to run faster, or die trying.  Sets -funsafe-math-optimizations, and

	   Allow optimizations that may be give incorrect results for certain IEEE inputs.

	   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 arithmetic.

	   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 Fortran, 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 count.

	   Also, no `loop discovery'[1] 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 currently recognized as such.  This option unrolls only itera-
	   tive "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 equiv-
	   alent to -funroll-loops but possibly slower.

	   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

	   -fmove-all-movables and -freduce-all-givs will enable loop optimization to move all
	   loop-invariant index computations in nested loops over multi-rank array dummy argu-
	   ments 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 the loops.

	   These three options are intended to be removed someday, once loop optimization is suf-
	   ficiently advanced to perform all those transformations without help from these

       Options Controlling the Preprocessor

       These options control the C preprocessor, which is run on each C source file before actual

       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 containing 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 specified 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 behav-
	   ior 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 genera-

       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 vari-
	   able and array referenced in it.  Does not affect common blocks.  (Some Fortran com-
	   pilers 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

	   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 actu-
	   ally 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 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"

	   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 argu-
	   ments 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

	   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 exter-
	   nal names.  The -fno-second-underscore option disables appending of the second under-
	   score in all cases.)

	   This is done to ensure compatibility with code produced by many UNIX Fortran compil-
	   ers, 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 vari-
	   ables, 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 diffi-
	   cult 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 debug-
	   ging 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.

	   Do not append a second underscore to names of entities specified in the Fortran source

	   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 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 are

	   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 initial-
	   izations 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

	   Implement "COMPLEX" arithmetic via emulation, instead of using the facilities of the
	   gcc back end that provide direct support of "complex" arithmetic.

	   (gcc had some bugs in its back-end support for "complex" arithmetic, due primarily to
	   the support not being completed as of version 2.8.1 and "egcs" 1.1.2.)

	   Use -femulate-complex if you suspect code-generation bugs, or experience compiler
	   crashes, that might result from g77 using the "COMPLEX" 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 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.

	   Version info: These options are not supported by versions of g77 based on gcc version

	   These options specify to what degree aliasing (overlap) is permitted 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

	   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 are produced.)

	   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

	   Use of this option therefore has the effect of instructing g77 to behave more like it
	   did up through version, 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 dis-
	   agreements 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.

	   Use back end's C-like constructs (pointer plus offset) instead of its "ARRAY_REF" con-
	   struct 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 substring 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

	   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 cur-
	   rently does not do.

	   Use the new -ffortran-bounds-check option to specify bounds-checking for only the For-
	   tran 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 "s_rnge" 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].

	   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.

	   For a "CHARACTER" substring reference, the second line has this appearance:

		   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.)

       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 linking 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 Trouble.

	   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 opera-
       tion above and beyond those that affect the operation of gcc.

       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 ``dis-
	   cover'' loops that are constructed out of looping constructs in the language (such as
	   Fortran's "DO").  For some programs, ``discovering'' loops constructed out of lower-
	   level constructs (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 Free Software Foundation, Inc.

       Permission is granted to copy, distribute and/or modify this document under the terms of
       the GNU Free Documentation License, Version 1.1 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

       (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.2.2				    2003-02-25					   G77(1)

All times are GMT -4. The time now is 11:51 AM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password