   This file documents the use and the internals of the GNU Fortran
(`g77') compiler.  It corresponds to the GCC-2.95 version of `g77'.

   Published by the Free Software Foundation 59 Temple Place - Suite 330
Boston, MA 02111-1307 USA

   Copyright (C) 1995-1999 Free Software Foundation, Inc.

   Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.

   Permission is granted to copy and distribute modified versions of
this manual under the conditions for verbatim copying, provided also
that the sections entitled "GNU General Public License," "Funding for
Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

   Permission is granted to copy and distribute translations of this
manual into another language, under the above conditions for modified
versions, except that the sections entitled "GNU General Public
License," "Funding for Free Software," and "Protect Your Freedom--Fight
`Look And Feel'", and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.

   Contributed by James Craig Burley (<craig@jcb-sc.com>).  Inspired by
a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).

`EXPIMP'
========

     Intrinsic INTRINSIC referenced ...

   The INTRINSIC is explicitly declared in one program unit in the
source file and implicitly used as an intrinsic in another program unit
in the same source file.

   This diagnostic is designed to catch cases where a program might
depend on using the name INTRINSIC as an intrinsic in one program unit
and as a global name (such as the name of a subroutine or function) in
another, but `g77' recognizes the name as an intrinsic in both cases.

   After verifying that the program unit making implicit use of the
intrinsic is indeed written expecting the intrinsic, add an `INTRINSIC
INTRINSIC' statement to that program unit to prevent this warning.

   This and related warnings are disabled by using the `-Wno-globals'
option when compiling.

   Note that this warning is not issued for standard intrinsics.
Standard intrinsics include those described in the FORTRAN 77 standard
and, if `-ff90' is specified, those described in the Fortran 90
standard.  Such intrinsics are not as likely to be confused with user
procedures as intrinsics provided as extensions to the standard by
`g77'.

`INTGLOB'
=========

     Same name `INTRINSIC' given ...

   The name INTRINSIC is used for a global entity (a common block or a
program unit) in one program unit and implicitly used as an intrinsic
in another program unit.

   This diagnostic is designed to catch cases where a program intends
to use a name entirely as a global name, but `g77' recognizes the name
as an intrinsic in the program unit that references the name, a
situation that would likely produce incorrect code.

   For example:

     INTEGER FUNCTION TIME()
     ...
     END
     ...
     PROGRAM SAMP
     INTEGER TIME
     PRINT *, 'Time is ', TIME()
     END

   The above example defines a program unit named `TIME', but the
reference to `TIME' in the main program unit `SAMP' is normally treated
by `g77' as a reference to the intrinsic `TIME()' (unless a
command-line option that prevents such treatment has been specified).

   As a result, the program `SAMP' will *not* invoke the `TIME'
function in the same source file.

   Since `g77' recognizes `libU77' procedures as intrinsics, and since
some existing code uses the same names for its own procedures as used
by some `libU77' procedures, this situation is expected to arise often
enough to make this sort of warning worth issuing.

   After verifying that the program unit making implicit use of the
intrinsic is indeed written expecting the intrinsic, add an `INTRINSIC
INTRINSIC' statement to that program unit to prevent this warning.

   Or, if you believe the program unit is designed to invoke the
program-defined procedure instead of the intrinsic (as recognized by
`g77'), add an `EXTERNAL INTRINSIC' statement to the program unit that
references the name to prevent this warning.

   This and related warnings are disabled by using the `-Wno-globals'
option when compiling.

   Note that this warning is not issued for standard intrinsics.
Standard intrinsics include those described in the FORTRAN 77 standard
and, if `-ff90' is specified, those described in the Fortran 90
standard.  Such intrinsics are not as likely to be confused with user
procedures as intrinsics provided as extensions to the standard by
`g77'.

`LEX'
=====

     Unrecognized character ...
     Invalid first character ...
     Line too long ...
     Non-numeric character ...
     Continuation indicator ...
     Label at ... invalid with continuation line indicator ...
     Character constant ...
     Continuation line ...
     Statement at ... begins with invalid token

   Although the diagnostics identify specific problems, they can be
produced when general problems such as the following occur:

   * The source file contains something other than Fortran code.

     If the code in the file does not look like many of the examples
     elsewhere in this document, it might not be Fortran code.  (Note
     that Fortran code often is written in lower case letters, while
     the examples in this document use upper case letters, for
     stylistic reasons.)

     For example, if the file contains lots of strange-looking
     characters, it might be APL source code; if it contains lots of
     parentheses, it might be Lisp source code; if it contains lots of
     bugs, it might be C++ source code.

   * The source file contains free-form Fortran code, but `-ffree-form'
     was not specified on the command line to compile it.

     Free form is a newer form for Fortran code.  The older, classic
     form is called fixed form.

     Fixed-form code is visually fairly distinctive, because numerical
     labels and comments are all that appear in the first five columns
     of a line, the sixth column is reserved to denote continuation
     lines, and actual statements start at or beyond column 7.  Spaces
     generally are not significant, so if you see statements such as
     `REALX,Y' and `DO10I=1,100', you are looking at fixed-form code.
     Comment lines are indicated by the letter `C' or the symbol `*' in
     column 1.  (Some code uses `!' or `/*' to begin in-line comments,
     which many compilers support.)

     Free-form code is distinguished from fixed-form source primarily
     by the fact that statements may start anywhere.  (If lots of
     statements start in columns 1 through 6, that's a strong indicator
     of free-form source.)  Consecutive keywords must be separated by
     spaces, so `REALX,Y' is not valid, while `REAL X,Y' is.  There are
     no comment lines per se, but `!' starts a comment anywhere in a
     line (other than within a character or Hollerith constant).

     See Source Form, for more information.

   * The source file is in fixed form and has been edited without
     sensitivity to the column requirements.

     Statements in fixed-form code must be entirely contained within
     columns 7 through 72 on a given line.  Starting them "early" is
     more likely to result in diagnostics than finishing them "late",
     though both kinds of errors are often caught at compile time.

     For example, if the following code fragment is edited by following
     the commented instructions literally, the result, shown afterward,
     would produce a diagnostic when compiled:

          C On XYZZY systems, remove "C" on next line:
          C     CALL XYZZY_RESET

     The result of editing the above line might be:

          C On XYZZY systems, remove "C" on next line:
               CALL XYZZY_RESET

     However, that leaves the first `C' in the `CALL' statement in
     column 6, making it a comment line, which is not really what the
     author intended, and which is likely to result in one of the
     above-listed diagnostics.

     *Replacing* the `C' in column 1 with a space is the proper change
     to make, to ensure the `CALL' keyword starts in or after column 7.

     Another common mistake like this is to forget that fixed-form
     source lines are significant through only column 72, and that,
     normally, any text beyond column 72 is ignored or is diagnosed at
     compile time.

     See Source Form, for more information.

   * The source file requires preprocessing, and the preprocessing is
     not being specified at compile time.

     A source file containing lines beginning with `#define',
     `#include', `#if', and so on is likely one that requires
     preprocessing.

     If the file's suffix is `.f', `.for', or `.FOR', the file normally
     will be compiled *without* preprocessing by `g77'.

     Change the file's suffix from `.f' to `.F' (or, on systems with
     case-insensitive file names, to `.fpp' or `.FPP'), from `.for' to
     `.fpp', or from `.FOR' to `.FPP'.  `g77' compiles files with such
     names *with* preprocessing.

     Or, learn how to use `gcc''s `-x' option to specify the language
     `f77-cpp-input' for Fortran files that require preprocessing.
     See gcc.

   * The source file is preprocessed, and the results of preprocessing
     result in syntactic errors that are not necessarily obvious to
     someone examining the source file itself.

     Examples of errors resulting from preprocessor macro expansion
     include exceeding the line-length limit, improperly starting,
     terminating, or incorporating the apostrophe or double-quote in a
     character constant, improperly forming a Hollerith constant, and
     so on.

     See Options Controlling the Kind of Output, for
     suggestions about how to use, and not use, preprocessing for
     Fortran code.

`GLOBALS'
=========

     Global name NAME defined at ... already defined...
     Global name NAME at ... has different type...
     Too many arguments passed to NAME at ...
     Too few arguments passed to NAME at ...
     Argument #N of NAME is ...

   These messages all identify disagreements about the global procedure
named NAME among different program units (usually including NAME
itself).

   Whether a particular disagreement is reported as a warning or an
error can depend on the relative order of the disagreeing portions of
the source file.

   Disagreements between a procedure invocation and the *subsequent*
procedure itself are, usually, diagnosed as errors when the procedure
itself *precedes* the invocation.  Other disagreements are diagnosed
via warnings.

   This distinction, between warnings and errors, is due primarily to
the present tendency of the `gcc' back end to inline only those
procedure invocations that are *preceded* by the corresponding
procedure definitions.  If the `gcc' back end is changed to inline
"forward references", in which invocations precede definitions, the
`g77' front end will be changed to treat both orderings as errors,
accordingly.

   The sorts of disagreements that are diagnosed by `g77' include
whether a procedure is a subroutine or function; if it is a function,
the type of the return value of the procedure; the number of arguments
the procedure accepts; and the type of each argument.

   Disagreements regarding global names among program units in a
Fortran program *should* be fixed in the code itself.  However, if that
is not immediately practical, and the code has been working for some
time, it is possible it will work when compiled with the `-fno-globals'
option.

   The `-fno-globals' option causes these diagnostics to all be warnings
and disables all inlining of references to global procedures (to avoid
subsequent compiler crashes and bad-code generation).  Use of the
`-Wno-globals' option as well as `-fno-globals' suppresses all of these
diagnostics.  (`-Wno-globals' by itself disables only the warnings, not
the errors.)

   After using `-fno-globals' to work around these problems, it is wise
to stop using that option and address them by fixing the Fortran code,
because such problems, while they might not actually result in bugs on
some systems, indicate that the code is not as portable as it could be.
In particular, the code might appear to work on a particular system,
but have bugs that affect the reliability of the data without
exhibiting any other outward manifestations of the bugs.

`LINKFAIL'
==========

     If the above command failed due to an unresolved reference
     to strtoul, _strtoul, bsearch, _bsearch, or similar, see
     [info -f g77 M LINKFAIL] (a node in the g77 documentation)
     for information on what causes this, how to work around
     the problem by editing ${srcdir}/proj.c, and what else to do.

   See Missing strtoul or bsearch, for more information on this
problem, which occurs only in releases of `g77' based on `gcc'.  (It
does not occur in `egcs'.)

   On AIX 4.1, `g77' might not build with the native (non-GNU) tools
due to a linker bug in coping with the `-bbigtoc' option which leads to
a `Relocation overflow' error.  The GNU linker is not recommended on
current AIX versions, though; it was developed under a now-unsupported
version.  This bug is said to be fixed by `update PTF U455193 for APAR
IX75823'.

   Compiling with `-mminimal-toc' might solve this problem, e.g. by
adding
     BOOT_CFLAGS='-mminimal-toc -O2 -g'
   to the `make bootstrap' command line.

`Y2KBAD'
========

     Intrinsic `NAME', invoked at (^), known to be non-Y2K-compliant...

   This diagnostic indicates that the specific intrinsic invoked by the
name NAME is known to have an interface that is not Year-2000 (Y2K)
compliant.

   See Year 2000 (Y2K) Problems.