Next: Overview of Translation Process, Up: Front End
The current directory layout includes the following:
libg2c configuration and g2c.h file generation
libg2c
libg2c
libc for libg2c
Components of note in g77 are described below.
f/ as a whole contains the source for g77,
while libf2c/ contains a portion of the separate program
f2c.
Note that the libf2c code is not part of the program g77,
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.
The g77 compiler code is placed in f/ because it,
along with its contents,
is designed to be a subdirectory of a gcc source directory,
gcc/,
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
the cp/ subdirectory.
Note that the C front end (also referred to as gcc)
is an exception to this, as its source files reside
in the gcc/ directory itself.
libf2c/ contains the run-time libraries for the f2c program,
also used by g77.
These libraries normally referred to collectively as libf2c.
When built as part of g77,
libf2c is installed under the name libg2c to avoid
conflict with any existing version of libf2c,
and thus is often referred to as libg2c when the
g77 version is specifically being referred to.
The netlib version of libf2c/
contains two distinct libraries,
libF77 and libI77,
each in their own subdirectories.
In g77, this distinction is not made,
beyond maintaining the subdirectory structure in the source-code tree.
libf2c/ is not part of the program g77,
just distributed with it.
It contains files not present
in the official (netlib) version of libf2c,
and also contains some minor changes made from libf2c,
to fix some bugs,
and to facilitate automatic configuration, building, and installation of
libf2c (as libg2c) for use by g77 users.
See libf2c/README for more information,
including licensing conditions
governing distribution of programs containing code from libg2c.
libg2c, g77's version of libf2c,
adds Dave Love's implementation of libU77,
in the libf2c/libU77/ directory.
This library is distributed under the
GNU Library General Public License (LGPL)—see the
file libf2c/libU77/COPYING.LIB
for more information,
as this license
governs distribution conditions for programs containing code
from this portion of the library.
Files of note in f/ and libf2c/ are described below:
g77 documentation:
info -f f/g77.info -n "Actual Bugs"
g77 internals.
libg2c internals.
g77 documentation, plus internal
changes of import.
Or use:
info -f f/g77.info -n News
g77 documentation, in Info format,
produced by building g77.
All users of g77 (not just installers) should read this,
using the more command if neither the info command,
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
such as info and GNU Emacs Info mode.
If you want to explore the FFE code, which lives entirely in f/,
here are a few clues.
The file g77spec.c contains the g77-specific source code
for the 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,
the g77 command does not contain the Fortran front end (FFE).
The FFE code ends up in an executable named f771,
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.
The file parse.c is the source file for yyparse(),
which is invoked by the GBE to start the compilation process,
for f771.
The file top.c contains the top-level FFE function ffe_file
and it (along with top.h) define all `ffe_[a-z].*', `ffe[A-Z].*',
and `FFE_[A-Za-z].*' symbols.
The file fini.c is a main() program that is used when building
the FFE to generate C header and source files for recognizing keywords.
The files malloc.c and malloc.h comprise a memory manager
that defines all `malloc_[a-z].*', `malloc[A-Z].*', and
`MALLOC_[A-Za-z].*' symbols.
All other modules named xyz are comprised of all files named `xyz*.ext' and define all `ffexyz_[a-z].*', `ffexyz[A-Z].*', and `FFEXYZ_[A-Za-z].*' symbols. 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 in xyz.h and implemented there (if it's a macro) or in xyz.c.
The “porting” files of note currently are:
ARRAY_SIZE and such.
INTEGER*8 map, for example),
how to convert between them,
and so on.
Over time, versions of g77 rely less on this file
and more on run-time configuration based on GBE info
in com.c.
If you want to debug the f771 executable,
for example if it crashes,
note that the global variables lineno and input_filename
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.)