Overview of Sources

The current directory layout includes the following:

{No value for `srcdir'}/gcc/

Non-g77 files in gcc

{No value for `srcdir'}/gcc/f/

GNU Fortran front end sources

{No value for `srcdir'}/libf2c/

libg2c configuration and g2c.h file generation

{No value for `srcdir'}/libf2c/libF77/

General support and math portion of libg2c

{No value for `srcdir'}/libf2c/libI77/

I/O portion of libg2c

{No value for `srcdir'}/libf2c/libU77/

Additional interfaces to Unix 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:

f/BUGS

Lists some important bugs known to be in g77. Or use Info (or GNU Emacs Info mode) to read the "Actual Bugs" node of the g77 documentation:

          info -f f/g77.info -n "Actual Bugs"
          

f/ChangeLog

Lists recent changes to g77 internals.

libf2c/ChangeLog

Lists recent changes to libg2c internals.

f/NEWS

Contains the per-release changes. These include the user-visible changes described in the node "Changes" in the g77 documentation, plus internal changes of import. Or use:

          info -f f/g77.info -n News
          

f/g77.info*

The 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:

proj.c

proj.h

This defines the "language" used by all the other source files, the language being Standard C plus some useful things like ARRAY_SIZE and such.

target.c

target.h

These describe the target machine in terms of what data types are supported, how they are denoted (to what C type does an 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.

com.c

com.h

These are the primary interface to the GBE.

ste.c

ste.h

This contains code for implementing recognized executable statements in the GBE.

src.c

src.h

These contain information on the format(s) of source files (such as whether they are never to be processed as case-insensitive with regard to Fortran keywords).

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