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. Note:gcc,
for information on suffixes recognized
by GNU CC.
`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'. Note:LEX.
`FILE.F'
`FILE.fpp'
`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). 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://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. Note: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.
Note: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'-specific 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.
`-fset-g77-defaults'
*Version info:* This option is obsolete in `egcs' as of version
1.1. The effect is instead achieved by the `lang_init_options'
routine in `egcs/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'.
Note: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).