Options Controlling the Kind of Output

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 specific to GNU Fortran are listed below. See section Options Controlling the Kind of Output, for information on suffixes recognized by GNU CC.

file.f

file.for

Fortran source code that should not be preprocessed. Such source code cannot contain any preprocessor directives, such as #include, #define, #if, and so on.

file.F

file.fpp

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.

file.r

Ratfor source code, which must be preprocessed by the ratfor command, which is available separately (as it is not yet part of the GNU Fortran distribution).

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, 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 traditional 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 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 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 avoid unpleasant surprises. See section `Options Controlling the Preprocessor' in Using and Porting GNU CC. 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 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.

The following options that affect overall processing are recognized by the g77 and gcc commands in a GNU Fortran installation:

-fversion

Ensure that the g77-specific version of the compiler phase is reported, if run. (This 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 files.)

-fset-g77-defaults

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.

-fno-silent

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.

See section `Options Controlling the Kind of Output' in Using and Porting GNU CC, for information on more options that control the overall operation of the gcc command (and, by extension, the g77 command).

Go to the first, previous, next, last section, table of contents.