5.2 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 Options Controlling the Kind of Output, for information on suffixes recognized by GCC.

file.f

file.for

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.

You can force `.f' files to be preprocessed by cpp by using -x f77-cpp-input. See LEX.

file.F

file.fpp

file.FPP

Fortran source code that must be preprocessed (by the C preprocessor 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.

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). A public domain version in C is at http://sepwww.stanford.edu/sep/prof/ratfor.shar.2.

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 help avoid unpleasant surprises. See Options Controlling the Preprocessor. 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.

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.

See Trailing Comment.

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

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

-fset-g77-defaults

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.

-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 Options Controlling the Kind of Output, for information on more options that control the overall operation of the gcc command (and, by extension, the g77 command).