The current directory layout includes the following:
Components of note in
g77 are described below.
f/ as a whole contains the source for
libf2c/ contains a portion of the separate program
Note that the
libf2c code is not part of the program
just distributed with it.
f/ contains text files that document the Fortran compiler, source
files for the GNU Fortran Front End (FFE), and some other stuff.
g77 compiler code is placed in
f/ because it,
along with its contents,
is designed to be a subdirectory of a
gcc source directory,
which is structured so that language-specific front ends can be "dropped
in" as subdirectories.
The C++ front end (
g++), is an example of this--it resides in
Note that the C front end (also referred to as
is an exception to this, as its source files reside
gcc/ directory itself.
libf2c/ contains the run-time libraries for the
also used by
These libraries normally referred to collectively as
When built as part of
libf2c is installed under the name
libg2c to avoid
conflict with any existing version of
and thus is often referred to as
libg2c when the
g77 version is specifically being referred to.
netlib version of
contains two distinct libraries,
each in their own subdirectories.
g77, this distinction is not made,
beyond maintaining the subdirectory structure in the source-code tree.
libf2c/ is not part of the program
just distributed with it.
It contains files not present
in the official (
netlib) version of
and also contains some minor changes made from
to fix some bugs,
and to facilitate automatic configuration, building, and installation of
libg2c) for use by
libf2c/README for more information,
including licensing conditions
governing distribution of programs containing code from
g77's version of
adds Dave Love's implementation of
This library is distributed under the
GNU Library General Public License (LGPL)--see the
for more information,
as this license
governs distribution conditions for programs containing code
from this portion of the library.
Files of note in
libf2c/ are described below:
info -f f/g77.info -n "Actual Bugs"
g77documentation, plus internal changes of import. Or use:
info -f f/g77.info -n News
g77documentation, in Info format, produced by building
All users of
g77 (not just installers) should read this,
more command if neither the
nor GNU Emacs (with its Info mode), are available, or if users
aren't yet accustomed to using these tools.
All of these files are readable as "plain text" files,
though they're easier to navigate using Info readers
info and GNU Emacs Info mode.
If you want to explore the FFE code, which lives entirely in
here are a few clues.
g77spec.c contains the
g77-specific source code
g77 command only--this just forms a variant of the
gcc command, so,
just as the
gcc command itself does not contain the C front end,
g77 command does not contain the Fortran front end (FFE).
The FFE code ends up in an executable named
which does the actual compiling,
so it contains the FFE plus the
gcc back end (GBE),
the latter to do most of the optimization, and the code generation.
parse.c is the source file for
which is invoked by the GBE to start the compilation process,
top.c contains the top-level FFE function
and it (along with top.h) define all
fini.c is a
main() program that is used when building
the FFE to generate C header and source files for recognizing keywords.
malloc.h comprise a memory manager
that defines all
All other modules named xyz
are comprised of all files named
and define all
If you understand all this, congratulations--it's easier for me to remember
how it works than to type in these regular expressions.
But it does make it easy to find where a symbol is defined.
For example, the symbol
ffexyz_set_something would be defined
xyz.h and implemented there (if it's a macro) or in
The "porting" files of note currently are:
INTEGER*8map, for example), how to convert between them, and so on. Over time, versions of
g77rely less on this file and more on run-time configuration based on GBE info in
If you want to debug the
for example if it crashes,
note that the global variables
are usually set to reflect the current line being read by the lexer
during the first-pass analysis of a program unit and to reflect
the current line being processed during the second-pass compilation
of a program unit.
If an invocation of the function
ffestd_exec_end is on the stack,
the compiler is in the second pass, otherwise it is in the first.
(This information might help you reduce a test case and/or work around
a bug in
g77 until a fix is available.)