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 GNU CC.
Such source code cannot contain any preprocessor directives, such
#if, and so on.
You can force
.f files to be preprocessed by
cpp by using
cpp, which is part of GNU CC).
Note that preprocessing is not extended to the contents of
files included by the
preprocessor directive must be used instead.
ratforcommand, which is available separately (as it is not yet part of the GNU Fortran distribution). One version in Fortran, adapted for use with
g77is 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
Users of other operating systems, especially those that cannot
letters from lower-case letters in their file names, typically use
Use of the preprocessor
cpp allows use of C-like
constructs such as
#include, but can
lead to unexpected, even mistaken, results due to Fortran's source file
It is recommended that use of the C preprocessor
be limited to
#include and, in
#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
These problems result, primarily, from differences between the way
such constants are interpreted by the C preprocessor and by a Fortran
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!
-undef flags are supplied
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
-v option to see exactly how the preprocessor is invoked.
-traditional flag will not avoid an error from
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
gcc commands in a GNU Fortran installation:
g77version of the compiler phase is reported, if run, and, starting in
egcsversion 1.1, that internal consistency checks in the
f771program are run.
This option is supplied automatically when
is specified as a command-line option for
and when the resulting commands compile Fortran source files.
In GCC 3.1, this is changed back to the behavior
egcsversion 1.1. The effect is instead achieved by the
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
The description of this option is provided so that users seeing
it in the output of, say,
g77 -v understand why it is
Also, developers who run
f771 directly might want to specify it
by hand to get the same defaults as they would running
However, such developers should, after linking a new
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.
stderr) the names of the program units as they are compiled, in a form similar to that used by popular UNIX
See Options Controlling the Kind of Output, for information
on more options that control the overall operation of the
(and, by extension, the