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

User-visible Changes
********************

   This chapter describes changes to `g77' that are visible to the
programmers who actually write and maintain Fortran code they compile
with `g77'.  Information on changes to installation procedures, changes
to the documentation, and bug fixes is not provided here, unless it is
likely to affect how users use `g77'.  See News About GNU Fortran,
for information on such changes to `g77'.

   Note that two variants of `g77' are tracked below.  The `egcs'
variant is described vis-a-vis previous versions of `egcs' and/or an
official FSF version, as appropriate.

   Therefore, `egcs' versions sometimes have multiple listings to help
clarify how they differ from other versions, though this can make
getting a complete picture of what a particular `egcs' version contains
somewhat more difficult.

   For information on bugs in the GCC-2.95 version of `g77', see
Known Bugs In GNU Fortran.

   The following information was last updated on 1999-07-08:

In 0.5.25, `GCC' 2.95 (`EGCS' 1.2) versus `EGCS' 1.1.2:
=======================================================

   * The new `-fbounds-check' option causes `g77' to compile run-time
     bounds checks of array subscripts, as well as of substring start
     and end points.

   * `libg2c' now supports building as multilibbed library, which
     provides better support for systems that require options such as
     `-mieee' to work properly.

   * Source file names with the suffixes `.FOR' and `.FPP' now are
     recognized by `g77' as if they ended in `.for' and `.fpp',
     respectively.

   * The order of arguments to the *subroutine* forms of the `CTime',
     `DTime', `ETime', and `TtyNam' intrinsics has been swapped.  The
     argument serving as the returned value for the corresponding
     function forms now is the *second* argument, making these
     consistent with the other subroutine forms of `libU77' intrinsics.

   * `g77' now warns about a reference to an intrinsic that has an
     interface that is not Year 2000 (Y2K) compliant.  Also, `libg2c'
     has been changed to increase the likelihood of catching references
     to the implementations of these intrinsics using the `EXTERNAL'
     mechanism (which would avoid the new warnings).

     See Year 2000 (Y2K) Problems, for more information.

   * `-fno-emulate-complex' is now the default option.  This should
     result in improved performance of code that uses the `COMPLEX'
     data type.

   * The `-malign-double' option now reliably aligns *all*
     double-precision variables and arrays on Intel x86 targets.

   * `g77' no longer generates code to maintain `errno', a C-language
     concept, when performing operations such as the `SqRt' intrinsic.

   * Support for the `-fugly' option has been removed.

In 0.5.24 versus 0.5.23:
========================

   There is no `g77' version 0.5.24 at this time, or planned.  0.5.24
is the version number designated for bug fixes and, perhaps, some new
features added, to 0.5.23.  Version 0.5.23 requires `gcc' 2.8.1, as
0.5.24 was planned to require.

   Due to `EGCS' becoming `GCC' (which is now an acronym for "GNU
Compiler Collection"), and `EGCS' 1.2 becoming officially designated
`GCC' 2.95, there seems to be no need for an actual 0.5.24 release.

   To reduce the confusion already resulting from use of 0.5.24 to
designate `g77' versions within `EGCS' versions 1.0 and 1.1, as well as
in versions of `g77' documentation and notices during that period,
"mainline" `g77' version numbering resumes at 0.5.25 with `GCC' 2.95
(`EGCS' 1.2), skipping over 0.5.24 as a placeholder version number.

   To repeat, there is no `g77' 0.5.24, but there is now a 0.5.25.
Please remain calm and return to your keypunch units.

In `EGCS' 1.1.2 versus `EGCS' 1.1.1:
====================================

In `EGCS' 1.1.1 versus `EGCS' 1.1:
==================================

In `EGCS' 1.1 versus `EGCS' 1.0.3:
==================================

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.

In `EGCS' 1.1 versus `g77' 0.5.23:
==================================

   * `g77' now treats `%LOC(EXPR)' and `LOC(EXPR)' as "ordinary"
     expressions when they are used as arguments in procedure calls.
     This change applies only to global (filewide) analysis, making it
     consistent with how `g77' actually generates code for these cases.

     Previously, `g77' treated these expressions as denoting special
     "pointer" arguments for the purposes of filewide analysis.

   * Align static double-precision variables and arrays on Intel x86
     targets regardless of whether `-malign-double' is specified.

     Generally, this affects only local variables and arrays having the
     `SAVE' attribute or given initial values via `DATA'.

   * The `g77' driver now ensures that `-lg2c' is specified in the link
     phase prior to any occurrence of `-lm'.  This prevents
     accidentally linking to a routine in the SunOS4 `-lm' library when
     the generated code wants to link to the one in `libf2c' (`libg2c').

   * `g77' emits more debugging information when `-g' is used.

     This new information allows, for example, `which __g77_length_a'
     to be used in `gdb' to determine the type of the phantom length
     argument supplied with `CHARACTER' variables.

     This information pertains to internally-generated type, variable,
     and other information, not to the longstanding deficiencies
     vis-a-vis `COMMON' and `EQUIVALENCE'.

   * The F90 `Date_and_Time' intrinsic now is supported.

   * The F90 `System_Clock' intrinsic allows the optional arguments
     (except for the `Count' argument) to be omitted.

In 0.5.23 versus 0.5.22:
========================

   * This release contains several regressions against version 0.5.22
     of `g77', due to using the "vanilla" `gcc' back end instead of
     patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for `__restrict__' keyword, the options
          `-fargument-alias', `-fargument-noalias', and
          `-fargument-noalias-global', and the corresponding
          alias-analysis code.

          (`egcs' has the alias-analysis code, but not the
          `__restrict__' keyword.  `egcs' `g77' users benefit from the
          alias-analysis code despite the lack of the `__restrict__'
          keyword, which is a C-language construct.)

        - Support for the GNU compiler options `-fmove-all-movables',
          `-freduce-all-givs', and `-frerun-loop-opt'.

          (`egcs' supports these options.  `g77' users of `egcs'
          benefit from them even if they are not explicitly specified,
          because the defaults are optimized for `g77' users.)

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

   * Support `gcc' version 2.8, and remove support for prior versions
     of `gcc'.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.

In 0.5.22 versus 0.5.21:
========================

   * Fix `Signal' intrinsic so it offers portable support for 64-bit
     systems (such as Digital Alphas running GNU/Linux).

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * Rename the `gcc' keyword `restrict' to `__restrict__', to avoid
     rejecting valid, existing, C programs.  Support for `restrict' is
     now more like support for `complex'.

   * Fix `-fugly-comma' to affect invocations of only external
     procedures.  Restore rejection of gratuitous trailing omitted
     arguments to intrinsics, as in `I=MAX(3,4,,)'.

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

In `EGCS' 1.0.2 versus `EGCS' 1.0.1:
====================================

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

In `EGCS' 1.0.1 versus `EGCS' 1.0:
==================================

In `EGCS' 1.0 versus `g77' 0.5.21:
==================================

   * Version 1.0 of `egcs' contains several regressions against version
     0.5.21 of `g77', due to using the "vanilla" `gcc' back end instead
     of patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for the C-language `restrict' keyword.

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

In 0.5.21:
==========

136. When the `-W' option is specified, `gcc', `g77', and other GNU
     compilers that incorporate the `gcc' back end as modified by
     `g77', issue a warning about integer division by constant zero.

   * New option `-Wno-globals' disables warnings about "suspicious" use
     of a name both as a global name and as the implicit name of an
     intrinsic, and warnings about disagreements over the number or
     natures of arguments passed to global procedures, or the natures
     of the procedures themselves.

     The default is to issue such warnings, which are new as of this
     version of `g77'.

   * New option `-fno-globals' disables diagnostics about potentially
     fatal disagreements analysis problems, such as disagreements over
     the number or natures of arguments passed to global procedures, or
     the natures of those procedures themselves.

     The default is to issue such diagnostics and flag the compilation
     as unsuccessful.  With this option, the diagnostics are issued as
     warnings, or, if `-Wno-globals' is specified, are not issued at
     all.

     This option also disables inlining of global procedures, to avoid
     compiler crashes resulting from coding errors that these
     diagnostics normally would identify.

   * Fix `libU77' routines that accept file and other names to strip
     trailing blanks from them, for consistency with other
     implementations.  Blanks may be forcibly appended to such names by
     appending a single null character (`CHAR(0)') to the significant
     trailing blanks.

   * Fix `CHMOD' intrinsic to work with file names that have embedded
     blanks, commas, and so on.

   * Fix `SIGNAL' intrinsic so it accepts an optional third `Status'
     argument.

   * Make many changes to `libU77' intrinsics to support existing code
     more directly.

     Such changes include allowing both subroutine and function forms
     of many routines, changing `MCLOCK()' and `TIME()' to return
     `INTEGER(KIND=1)' values, introducing `MCLOCK8()' and `TIME8()' to
     return `INTEGER(KIND=2)' values, and placing functions that are
     intended to perform side effects in a new intrinsic group,
     `badu77'.

   * Add options `-fbadu77-intrinsics-delete',
     `-fbadu77-intrinsics-hide', and so on.

   * Add `INT2' and `INT8' intrinsics.

   * Add `CPU_TIME' intrinsic.

   * Add `ALARM' intrinsic.

   * `CTIME' intrinsic now accepts any `INTEGER' argument, not just
     `INTEGER(KIND=2)'.

   * `g77' driver now prints version information (such as produced by
     `g77 -v') to `stderr' instead of `stdout'.

   * The `.r' suffix now designates a Ratfor source file, to be
     preprocessed via the `ratfor' command, available separately.

In 0.5.20:
==========

   * The `-fno-typeless-boz' option is now the default.

     This option specifies that non-decimal-radix constants using the
     prefixed-radix form (such as `Z'1234'') are to be interpreted as
     `INTEGER(KIND=1)' constants.  Specify `-ftypeless-boz' to cause
     such constants to be interpreted as typeless.

     (Version 0.5.19 introduced `-fno-typeless-boz' and its inverse.)

     See Options Controlling Fortran Dialect,
     for information on the `-ftypeless-boz' option.

   * Options `-ff90-intrinsics-enable' and `-fvxt-intrinsics-enable'
     now are the defaults.

     Some programs might use names that clash with intrinsic names
     defined (and now enabled) by these options or by the new `libU77'
     intrinsics.  Users of such programs might need to compile them
     differently (using, for example, `-ff90-intrinsics-disable') or,
     better yet, insert appropriate `EXTERNAL' statements specifying
     that these names are not intended to be names of intrinsics.

   * The `ALWAYS_FLUSH' macro is no longer defined when building
     `libf2c', which should result in improved I/O performance,
     especially over NFS.

     *Note:* If you have code that depends on the behavior of `libf2c'
     when built with `ALWAYS_FLUSH' defined, you will have to modify
     `libf2c' accordingly before building it from this and future
     versions of `g77'.

     See Output Assumed To Flush, for more information.

   * Dave Love's implementation of `libU77' has been added to the
     version of `libf2c' distributed with and built as part of `g77'.
     `g77' now knows about the routines in this library as intrinsics.

   * New option `-fvxt' specifies that the source file is written in
     VXT Fortran, instead of GNU Fortran.

     See VXT Fortran, for more information on the constructs
     recognized when the `-fvxt' option is specified.

   * The `-fvxt-not-f90' option has been deleted, along with its
     inverse, `-ff90-not-vxt'.

     If you used one of these deleted options, you should re-read the
     pertinent documentation to determine which options, if any, are
     appropriate for compiling your code with this version of `g77'.

     See Other Dialects, for more information.

   * The `-fugly' option now issues a warning, as it likely will be
     removed in a future version.

     (Enabling all the `-fugly-*' options is unlikely to be feasible,
     or sensible, in the future, so users should learn to specify only
     those `-fugly-*' options they really need for a particular source
     file.)

   * The `-fugly-assumed' option, introduced in version 0.5.19, has
     been changed to better accommodate old and new code.

     See Ugly Assumed-Size Arrays, for more information.

   * Related to supporting Alpha (AXP) machines, the `LOC()' intrinsic
     and `%LOC()' construct now return values of `INTEGER(KIND=0)' type,
     as defined by the GNU Fortran language.

     This type is wide enough (holds the same number of bits) as the
     character-pointer type on the machine.

     On most machines, this won't make a difference, whereas, on Alphas
     and other systems with 64-bit pointers, the `INTEGER(KIND=0)' type
     is equivalent to `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') instead of the more common `INTEGER(KIND=1)' (often
     referred to as `INTEGER*4').

   * Emulate `COMPLEX' arithmetic in the `g77' front end, to avoid bugs
     in `complex' support in the `gcc' back end.  New option
     `-fno-emulate-complex' causes `g77' to revert the 0.5.19 behavior.

   * Dummy arguments are no longer assumed to potentially alias
     (overlap) other dummy arguments or `COMMON' areas when any of
     these are defined (assigned to) by Fortran code.

     This can result in faster and/or smaller programs when compiling
     with optimization enabled, though on some systems this effect is
     observed only when `-fforce-addr' also is specified.

     New options `-falias-check', `-fargument-alias',
     `-fargument-noalias', and `-fno-argument-noalias-global' control
     the way `g77' handles potential aliasing.

     See Aliasing Assumed To Work, for detailed information on why
     the new defaults might result in some programs no longer working
     the way they did when compiled by previous versions of `g77'.

   * New option `-fugly-assign' specifies that the same memory
     locations are to be used to hold the values assigned by both
     statements `I = 3' and `ASSIGN 10 TO I', for example.  (Normally,
     `g77' uses a separate memory location to hold assigned statement
     labels.)

     See Ugly Assigned Labels, for more information.

   * `FORMAT' and `ENTRY' statements now are allowed to precede
     `IMPLICIT NONE' statements.

   * Enable full support of `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') available in `libf2c' and `f2c.h' so that `f2c' users
     may make full use of its features via the `g77' version of `f2c.h'
     and the `INTEGER(KIND=2)' support routines in the `g77' version of
     `libf2c'.

   * Improve `g77' driver and `libf2c' so that `g77 -v' yields version
     information on the library.

   * The `SNGL' and `FLOAT' intrinsics now are specific intrinsics,
     instead of synonyms for the generic intrinsic `REAL'.

   * New intrinsics have been added.  These are `REALPART', `IMAGPART',
     `COMPLEX', `LONG', and `SHORT'.

   * A new group of intrinsics, `gnu', has been added to contain the
     new `REALPART', `IMAGPART', and `COMPLEX' intrinsics.  An old
     group, `dcp', has been removed.

   * Complain about industry-wide ambiguous references `REAL(EXPR)' and
     `AIMAG(EXPR)', where EXPR is `DOUBLE COMPLEX' (or any complex type
     other than `COMPLEX'), unless `-ff90' option specifies Fortran 90
     interpretation or new `-fugly-complex' option, in conjunction with
     `-fnot-f90', specifies `f2c' interpretation.

In previous versions:
=====================

   Information on previous versions is archived in
`egcs/gcc/f/news.texi' following the test of the `DOC-OLDNEWS' macro.

The GNU Fortran Language
************************

   GNU Fortran supports a variety of extensions to, and dialects of,
the Fortran language.  Its primary base is the ANSI FORTRAN 77
standard, currently available on the network at
`http://www.fortran.com/fortran/F77_std/rjcnf0001.html' or as
monolithic text at
`http://www.fortran.com/fortran/F77_std/f77_std.html'.  It offers some
extensions that are popular among users of UNIX `f77' and `f2c'
compilers, some that are popular among users of other compilers (such
as Digital products), some that are popular among users of the newer
Fortran 90 standard, and some that are introduced by GNU Fortran.

   (If you need a text on Fortran, a few freely available electronic
references have pointers from `http://www.fortran.com/fortran/Books/'.
There is a `cooperative net project', `User Notes on Fortran
Programming' at `ftp://vms.huji.ac.il/fortran/' and mirrors elsewhere;
some of this material might not apply specifically to `g77'.)

   Part of what defines a particular implementation of a Fortran
system, such as `g77', is the particular characteristics of how it
supports types, constants, and so on.  Much of this is left up to the
implementation by the various Fortran standards and accepted practice
in the industry.

   The GNU Fortran *language* is described below.  Much of the material
is organized along the same lines as the ANSI FORTRAN 77 standard
itself.

   See Other Dialects, for information on features `g77' supports
that are not part of the GNU Fortran language.

   *Note*: This portion of the documentation definitely needs a lot of
work!

Relationship to the ANSI FORTRAN 77 standard:

Extensions to the ANSI FORTRAN 77 standard:

Direction of Language Development
=================================

   The purpose of the following description of the GNU Fortran language
is to promote wide portability of GNU Fortran programs.

   GNU Fortran is an evolving language, due to the fact that `g77'
itself is in beta test.  Some current features of the language might
later be redefined as dialects of Fortran supported by `g77' when
better ways to express these features are added to `g77', for example.
Such features would still be supported by `g77', but would be available
only when one or more command-line options were used.

   The GNU Fortran *language* is distinct from the GNU Fortran
*compilation system* (`g77').

   For example, `g77' supports various dialects of Fortran--in a sense,
these are languages other than GNU Fortran--though its primary purpose
is to support the GNU Fortran language, which also is described in its
documentation and by its implementation.

   On the other hand, non-GNU compilers might offer support for the GNU
Fortran language, and are encouraged to do so.

   Currently, the GNU Fortran language is a fairly fuzzy object.  It
represents something of a cross between what `g77' accepts when
compiling using the prevailing defaults and what this document
describes as being part of the language.

   Future versions of `g77' are expected to clarify the definition of
the language in the documentation.  Often, this will mean adding new
features to the language, in the form of both new documentation and new
support in `g77'.  However, it might occasionally mean removing a
feature from the language itself to "dialect" status.  In such a case,
the documentation would be adjusted to reflect the change, and `g77'
itself would likely be changed to require one or more command-line
options to continue supporting the feature.

   The development of the GNU Fortran language is intended to strike a
balance between:

   * Serving as a mostly-upwards-compatible language from the de facto
     UNIX Fortran dialect as supported by `f77'.

   * Offering new, well-designed language features.  Attributes of such
     features include not making existing code any harder to read (for
     those who might be unaware that the new features are not in use)
     and not making state-of-the-art compilers take longer to issue
     diagnostics, among others.

   * Supporting existing, well-written code without gratuitously
     rejecting non-standard constructs, regardless of the origin of the
     code (its dialect).

   * Offering default behavior and command-line options to reduce and,
     where reasonable, eliminate the need for programmers to make any
     modifications to code that already works in existing production
     environments.

   * Diagnosing constructs that have different meanings in different
     systems, languages, and dialects, while offering clear, less
     ambiguous ways to express each of the different meanings so
     programmers can change their code appropriately.

   One of the biggest practical challenges for the developers of the
GNU Fortran language is meeting the sometimes contradictory demands of
the above items.

   For example, a feature might be widely used in one popular
environment, but the exact same code that utilizes that feature might
not work as expected--perhaps it might mean something entirely
different--in another popular environment.

   Traditionally, Fortran compilers--even portable ones--have solved
this problem by simply offering the appropriate feature to users of the
respective systems.  This approach treats users of various Fortran
systems and dialects as remote "islands", or camps, of programmers, and
assume that these camps rarely come into contact with each other (or,
especially, with each other's code).

   Project GNU takes a radically different approach to software and
language design, in that it assumes that users of GNU software do not
necessarily care what kind of underlying system they are using,
regardless of whether they are using software (at the user-interface
level) or writing it (for example, writing Fortran or C code).

   As such, GNU users rarely need consider just what kind of underlying
hardware (or, in many cases, operating system) they are using at any
particular time.  They can use and write software designed for a
general-purpose, widely portable, heterogenous environment--the GNU
environment.

   In line with this philosophy, GNU Fortran must evolve into a product
that is widely ported and portable not only in the sense that it can be
successfully built, installed, and run by users, but in the larger
sense that its users can use it in the same way, and expect largely the
same behaviors from it, regardless of the kind of system they are using
at any particular time.

   This approach constrains the solutions `g77' can use to resolve
conflicts between various camps of Fortran users.  If these two camps
disagree about what a particular construct should mean, `g77' cannot
simply be changed to treat that particular construct as having one
meaning without comment (such as a warning), lest the users expecting
it to have the other meaning are unpleasantly surprised that their code
misbehaves when executed.

   The use of the ASCII backslash character in character constants is
an excellent (and still somewhat unresolved) example of this kind of
controversy.  See Backslash in Constants.  Other examples are
likely to arise in the future, as `g77' developers strive to improve
its ability to accept an ever-wider variety of existing Fortran code
without requiring significant modifications to said code.

   Development of GNU Fortran is further constrained by the desire to
avoid requiring programmers to change their code.  This is important
because it allows programmers, administrators, and others to more
faithfully evaluate and validate `g77' (as an overall product and as
new versions are distributed) without having to support multiple
versions of their programs so that they continue to work the same way
on their existing systems (non-GNU perhaps, but possibly also earlier
versions of `g77').

ANSI FORTRAN 77 Standard Support
================================

   GNU Fortran supports ANSI FORTRAN 77 with the following caveats.  In
summary, the only ANSI FORTRAN 77 features `g77' doesn't support are
those that are probably rarely used in actual code, some of which are
explicitly disallowed by the Fortran 90 standard.

No Passing External Assumed-length
----------------------------------

   `g77' disallows passing of an external procedure as an actual
argument if the procedure's type is declared `CHARACTER*(*)'.  For
example:

     CHARACTER*(*) CFUNC
     EXTERNAL CFUNC
     CALL FOO(CFUNC)
     END

It isn't clear whether the standard considers this conforming.

No Passing Dummy Assumed-length
-------------------------------

   `g77' disallows passing of a dummy procedure as an actual argument
if the procedure's type is declared `CHARACTER*(*)'.

     SUBROUTINE BAR(CFUNC)
     CHARACTER*(*) CFUNC
     EXTERNAL CFUNC
     CALL FOO(CFUNC)
     END

It isn't clear whether the standard considers this conforming.

No Pathological Implied-DO
--------------------------

   The `DO' variable for an implied-`DO' construct in a `DATA'
statement may not be used as the `DO' variable for an outer
implied-`DO' construct.  For example, this fragment is disallowed by
`g77':

     DATA ((A(I, I), I= 1, 10), I= 1, 10) /.../

This also is disallowed by Fortran 90, as it offers no additional
capabilities and would have a variety of possible meanings.

   Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.

No Useless Implied-DO
---------------------

   An array element initializer in an implied-`DO' construct in a
`DATA' statement must contain at least one reference to the `DO'
variables of each outer implied-`DO' construct.  For example, this
fragment is disallowed by `g77':

     DATA (A, I= 1, 1) /1./

This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities.  However, `g77' doesn't
necessarily diagnose all cases where this requirement is not met.

   Note that it is *very* unlikely that any production Fortran code
tries to use this unsupported construct.

Conformance
===========

   (The following information augments or overrides the information in
Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.  Chapter 1 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)

   The definition of the GNU Fortran language is akin to that of the
ANSI FORTRAN 77 language in that it does not generally require
conforming implementations to diagnose cases where programs do not
conform to the language.

   However, `g77' as a compiler is being developed in a way that is
intended to enable it to diagnose such cases in an easy-to-understand
manner.

   A program that conforms to the GNU Fortran language should, when
compiled, linked, and executed using a properly installed `g77' system,
perform as described by the GNU Fortran language definition.  Reasons
for different behavior include, among others:

   * Use of resources (memory--heap, stack, and so on; disk space; CPU
     time; etc.) exceeds those of the system.

   * Range and/or precision of calculations required by the program
     exceeds that of the system.

   * Excessive reliance on behaviors that are system-dependent
     (non-portable Fortran code).

   * Bugs in the program.

   * Bug in `g77'.

   * Bugs in the system.

   Despite these "loopholes", the availability of a clear specification
of the language of programs submitted to `g77', as this document is
intended to provide, is considered an important aspect of providing a
robust, clean, predictable Fortran implementation.

   The definition of the GNU Fortran language, while having no special
legal status, can therefore be viewed as a sort of contract, or
agreement.  This agreement says, in essence, "if you write a program in
this language, and run it in an environment (such as a `g77' system)
that supports this language, the program should behave in a largely
predictable way".

Notation Used in This Chapter
=============================

   (The following information augments or overrides the information in
Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.  Chapter 1 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)

   In this chapter, "must" denotes a requirement, "may" denotes
permission, and "must not" and "may not" denote prohibition.  Terms
such as "might", "should", and "can" generally add little or nothing in
the way of weight to the GNU Fortran language itself, but are used to
explain or illustrate the language.

   For example:

     ``The `FROBNITZ' statement must precede all executable
     statements in a program unit, and may not specify any dummy
     arguments.  It may specify local or common variables and arrays.
     Its use should be limited to portions of the program designed to
     be non-portable and system-specific, because it might cause the
     containing program unit to behave quite differently on different
     systems.''

   Insofar as the GNU Fortran language is specified, the requirements
and permissions denoted by the above sample statement are limited to
the placement of the statement and the kinds of things it may specify.
The rest of the statement--the content regarding non-portable portions
of the program and the differing behavior of program units containing
the `FROBNITZ' statement--does not pertain the GNU Fortran language
itself.  That content offers advice and warnings about the `FROBNITZ'
statement.

   *Remember:* The GNU Fortran language definition specifies both what
constitutes a valid GNU Fortran program and how, given such a program,
a valid GNU Fortran implementation is to interpret that program.

   It is *not* incumbent upon a valid GNU Fortran implementation to
behave in any particular way, any consistent way, or any predictable
way when it is asked to interpret input that is *not* a valid GNU
Fortran program.

   Such input is said to have "undefined" behavior when interpreted by
a valid GNU Fortran implementation, though an implementation may choose
to specify behaviors for some cases of inputs that are not valid GNU
Fortran programs.

   Other notation used herein is that of the GNU texinfo format, which
is used to generate printed hardcopy, on-line hypertext (Info), and
on-line HTML versions, all from a single source document.  This
notation is used as follows:

   * Keywords defined by the GNU Fortran language are shown in
     uppercase, as in: `COMMON', `INTEGER', and `BLOCK DATA'.

     Note that, in practice, many Fortran programs are written in
     lowercase--uppercase is used in this manual as a means to readily
     distinguish keywords and sample Fortran-related text from the
     prose in this document.

   * Portions of actual sample program, input, or output text look like
     this: `Actual program text'.

     Generally, uppercase is used for all Fortran-specific and
     Fortran-related text, though this does not always include literal
     text within Fortran code.

     For example: `PRINT *, 'My name is Bob''.

   * A metasyntactic variable--that is, a name used in this document to
     serve as a placeholder for whatever text is used by the user or
     programmer--appears as shown in the following example:

     "The `INTEGER IVAR' statement specifies that IVAR is a variable or
     array of type `INTEGER'."

     In the above example, any valid text may be substituted for the
     metasyntactic variable IVAR to make the statement apply to a
     specific instance, as long as the same text is substituted for
     *both* occurrences of IVAR.

   * Ellipses ("...") are used to indicate further text that is either
     unimportant or expanded upon further, elsewhere.

   * Names of data types are in the style of Fortran 90, in most cases.

     See Kind Notation, for information on the relationship between
     Fortran 90 nomenclature (such as `INTEGER(KIND=1)') and the more
     traditional, less portably concise nomenclature (such as
     `INTEGER*4').

Fortran Terms and Concepts
==========================

   (The following information augments or overrides the information in
Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.  Chapter 2 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)

Syntactic Items
---------------

   (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)

   In GNU Fortran, a symbolic name is at least one character long, and
has no arbitrary upper limit on length.  However, names of entities
requiring external linkage (such as external functions, external
subroutines, and `COMMON' areas) might be restricted to some arbitrary
length by the system.  Such a restriction is no more constrained than
that of one through six characters.

   Underscores (`_') are accepted in symbol names after the first
character (which must be a letter).

Statements, Comments, and Lines
-------------------------------

   (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)

   Use of an exclamation point (`!') to begin a trailing comment (a
comment that extends to the end of the same source line) is permitted
under the following conditions:

   * The exclamation point does not appear in column 6.  Otherwise, it
     is treated as an indicator of a continuation line.

   * The exclamation point appears outside a character or Hollerith
     constant.  Otherwise, the exclamation point is considered part of
     the constant.

   * The exclamation point appears to the left of any other possible
     trailing comment.  That is, a trailing comment may contain
     exclamation points in their commentary text.

   Use of a semicolon (`;') as a statement separator is permitted under
the following conditions:

   * The semicolon appears outside a character or Hollerith constant.
     Otherwise, the semicolon is considered part of the constant.

   * The semicolon appears to the left of a trailing comment.
     Otherwise, the semicolon is considered part of that comment.

   * Neither a logical `IF' statement nor a non-construct `WHERE'
     statement (a Fortran 90 feature) may be followed (in the same,
     possibly continued, line) by a semicolon used as a statement
     separator.

     This restriction avoids the confusion that can result when reading
     a line such as:

          IF (VALIDP) CALL FOO; CALL BAR

     Some readers might think the `CALL BAR' is executed only if
     `VALIDP' is `.TRUE.', while others might assume its execution is
     unconditional.

     (At present, `g77' does not diagnose code that violates this
     restriction.)

Scope of Symbolic Names and Statement Labels
--------------------------------------------

   (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)

   Included in the list of entities that have a scope of a program unit
are construct names (a Fortran 90 feature).  See Construct Names,
for more information.

Characters, Lines, and Execution Sequence
=========================================

   (The following information augments or overrides the information in
Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
language.  Chapter 3 of that document otherwise serves as the basis for
the relevant aspects of GNU Fortran.)

GNU Fortran Character Set
-------------------------

   (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)

   Letters include uppercase letters (the twenty-six characters of the
English alphabet) and lowercase letters (their lowercase equivalent).
Generally, lowercase letters may be used in place of uppercase letters,
though in character and Hollerith constants, they are distinct.

   Special characters include:

   * Semicolon (`;')

   * Exclamation point (`!')

   * Double quote (`"')

   * Backslash (`\')

   * Question mark (`?')

   * Hash mark (`#')

   * Ampersand (`&')

   * Percent sign (`%')

   * Underscore (`_')

   * Open angle (`<')

   * Close angle (`>')

   * The FORTRAN 77 special characters (<SPC>, `=', `+', `-', `*', `/',
     `(', `)', `,', `.', `$', `'', and `:')

   Note that this document refers to <SPC> as "space", while X3.9-1978
FORTRAN 77 refers to it as "blank".

Lines
-----

   (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)

   The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler, since those choices are
explicitly left to the implementation by the published Fortran
standards.

   The GNU Fortran language mandates a view applicable to UNIX-like
text files--files that are made up of an arbitrary number of lines,
each with an arbitrary number of characters (sometimes called
stream-based files).

   This view does not apply to types of files that are specified as
having a particular number of characters on every single line (sometimes
referred to as record-based files).

   Because a "line in a program unit is a sequence of 72 characters",
to quote X3.9-1978, the GNU Fortran language specifies that a
stream-based text file is translated to GNU Fortran lines as follows:

   * A newline in the file is the character that represents the end of
     a line of text to the underlying system.  For example, on
     ASCII-based systems, a newline is the <NL> character, which has
     ASCII value 10 (decimal).

   * Each newline in the file serves to end the line of text that
     precedes it (and that does not contain a newline).

   * The end-of-file marker (`EOF') also serves to end the line of text
     that precedes it (and that does not contain a newline).

   * Any line of text that is shorter than 72 characters is padded to
     that length with spaces (called "blanks" in the standard).

   * Any line of text that is longer than 72 characters is truncated to
     that length, but the truncated remainder must consist entirely of
     spaces.

   * Characters other than newline and the GNU Fortran character set
     are invalid.

   For the purposes of the remainder of this description of the GNU
Fortran language, the translation described above has already taken
place, unless otherwise specified.

   The result of the above translation is that the source file appears,
in terms of the remainder of this description of the GNU Fortran
language, as if it had an arbitrary number of 72-character lines, each
character being among the GNU Fortran character set.

   For example, if the source file itself has two newlines in a row,
the second newline becomes, after the above translation, a single line
containing 72 spaces.

Continuation Line
-----------------

   (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)

   A continuation line is any line that both

   * Contains a continuation character, and

   * Contains only spaces in columns 1 through 5

   A continuation character is any character of the GNU Fortran
character set other than space (<SPC>) or zero (`0') in column 6, or a
digit (`0' through `9') in column 7 through 72 of a line that has only
spaces to the left of that digit.

   The continuation character is ignored as far as the content of the
statement is concerned.

   The GNU Fortran language places no limit on the number of
continuation lines in a statement.  In practice, the limit depends on a
variety of factors, such as available memory, statement content, and so
on, but no GNU Fortran system may impose an arbitrary limit.

Statements
----------

   (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)

   Statements may be written using an arbitrary number of continuation
lines.

   Statements may be separated using the semicolon (`;'), except that
the logical `IF' and non-construct `WHERE' statements may not be
separated from subsequent statements using only a semicolon as
statement separator.

   The `END PROGRAM', `END SUBROUTINE', `END FUNCTION', and `END BLOCK
DATA' statements are alternatives to the `END' statement.  These
alternatives may be written as normal statements--they are not subject
to the restrictions of the `END' statement.

   However, no statement other than `END' may have an initial line that
appears to be an `END' statement--even `END PROGRAM', for example, must
not be written as:

           END
          &PROGRAM

Statement Labels
----------------

   (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)

   A statement separated from its predecessor via a semicolon may be
labeled as follows:

   * The semicolon is followed by the label for the statement, which in
     turn follows the label.

   * The label must be no more than five digits in length.

   * The first digit of the label for the statement is not the first
     non-space character on a line.  Otherwise, that character is
     treated as a continuation character.

   A statement may have only one label defined for it.

Order of Statements and Lines
-----------------------------

   (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)

   Generally, `DATA' statements may precede executable statements.
However, specification statements pertaining to any entities
initialized by a `DATA' statement must precede that `DATA' statement.
For example, after `DATA I/1/', `INTEGER I' is not permitted, but
`INTEGER J' is permitted.

   The last line of a program unit may be an `END' statement, or may be:

   * An `END PROGRAM' statement, if the program unit is a main program.

   * An `END SUBROUTINE' statement, if the program unit is a subroutine.

   * An `END FUNCTION' statement, if the program unit is a function.

   * An `END BLOCK DATA' statement, if the program unit is a block data.