This is g77.info, produced by makeinfo version 4.2 from g77.texi.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* g77: (g77).                  The GNU Fortran compiler.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU Fortran
(`g77') compiler.  It corresponds to the GCC-3.1 version of `g77'.

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

   Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002 Free Software
Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.1 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.

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


File: g77.info,  Node: Case Sensitivity,  Next: VXT Fortran,  Prev: Dollar Signs,  Up: Other Dialects

Case Sensitivity
================

   GNU Fortran offers the programmer way too much flexibility in
deciding how source files are to be treated vis-a-vis uppercase and
lowercase characters.  There are 66 useful settings that affect case
sensitivity, plus 10 settings that are nearly useless, with the
remaining 116 settings being either redundant or useless.

   None of these settings have any effect on the contents of comments
(the text after a `c' or `C' in Column 1, for example) or of character
or Hollerith constants.  Note that things like the `E' in the statement
`CALL FOO(3.2E10)' and the `TO' in `ASSIGN 10 TO LAB' are considered
built-in keywords, and so are affected by these settings.

   Low-level switches are identified in this section as follows:

     A Source Case Conversion:

          0 Preserve (see Note 1)

          1 Convert to Upper Case

          2 Convert to Lower Case

     B Built-in Keyword Matching:

          0 Match Any Case (per-character basis)

          1 Match Upper Case Only

          2 Match Lower Case Only

          3 Match InitialCaps Only (see tables for spellings)

     C Built-in Intrinsic Matching:

          0 Match Any Case (per-character basis)

          1 Match Upper Case Only

          2 Match Lower Case Only

          3 Match InitialCaps Only (see tables for spellings)

     D User-defined Symbol Possibilities (warnings only):

          0 Allow Any Case (per-character basis)

          1 Allow Upper Case Only

          2 Allow Lower Case Only

          3 Allow InitialCaps Only (see Note 2)

   Note 1: `g77' eventually will support `NAMELIST' in a manner that is
consistent with these source switches--in the sense that input will be
expected to meet the same requirements as source code in terms of
matching symbol names and keywords (for the exponent letters).

   Currently, however, `NAMELIST' is supported by `libg2c', which
uppercases `NAMELIST' input and symbol names for matching.  This means
not only that `NAMELIST' output currently shows symbol (and keyword)
names in uppercase even if lower-case source conversion (option A2) is
selected, but that `NAMELIST' cannot be adequately supported when
source case preservation (option A0) is selected.

   If A0 is selected, a warning message will be output for each
`NAMELIST' statement to this effect.  The behavior of the program is
undefined at run time if two or more symbol names appear in a given
`NAMELIST' such that the names are identical when converted to upper
case (e.g. `NAMELIST /X/ VAR, Var, var').  For complete and total
elegance, perhaps there should be a warning when option A2 is selected,
since the output of NAMELIST is currently in uppercase but will someday
be lowercase (when a `libg77' is written), but that seems to be
overkill for a product in beta test.

   Note 2: Rules for InitialCaps names are:

   - Must be a single uppercase letter, *or*

   - Must start with an uppercase letter and contain at least one
     lowercase letter.

   So `A', `Ab', `ABc', `AbC', and `Abc' are valid InitialCaps names,
but `AB', `A2', and `ABC' are not.  Note that most, but not all,
built-in names meet these requirements--the exceptions are some of the
two-letter format specifiers, such as `BN' and `BZ'.

   Here are the names of the corresponding command-line options:

     A0: -fsource-case-preserve
     A1: -fsource-case-upper
     A2: -fsource-case-lower
     
     B0: -fmatch-case-any
     B1: -fmatch-case-upper
     B2: -fmatch-case-lower
     B3: -fmatch-case-initcap
     
     C0: -fintrin-case-any
     C1: -fintrin-case-upper
     C2: -fintrin-case-lower
     C3: -fintrin-case-initcap
     
     D0: -fsymbol-case-any
     D1: -fsymbol-case-upper
     D2: -fsymbol-case-lower
     D3: -fsymbol-case-initcap

   Useful combinations of the above settings, along with abbreviated
option names that set some of these combinations all at once:

      1: A0--  B0---  C0---  D0---    -fcase-preserve
      2: A0--  B0---  C0---  D-1--
      3: A0--  B0---  C0---  D--2-
      4: A0--  B0---  C0---  D---3
      5: A0--  B0---  C-1--  D0---
      6: A0--  B0---  C-1--  D-1--
      7: A0--  B0---  C-1--  D--2-
      8: A0--  B0---  C-1--  D---3
      9: A0--  B0---  C--2-  D0---
     10: A0--  B0---  C--2-  D-1--
     11: A0--  B0---  C--2-  D--2-
     12: A0--  B0---  C--2-  D---3
     13: A0--  B0---  C---3  D0---
     14: A0--  B0---  C---3  D-1--
     15: A0--  B0---  C---3  D--2-
     16: A0--  B0---  C---3  D---3
     17: A0--  B-1--  C0---  D0---
     18: A0--  B-1--  C0---  D-1--
     19: A0--  B-1--  C0---  D--2-
     20: A0--  B-1--  C0---  D---3
     21: A0--  B-1--  C-1--  D0---
     22: A0--  B-1--  C-1--  D-1--    -fcase-strict-upper
     23: A0--  B-1--  C-1--  D--2-
     24: A0--  B-1--  C-1--  D---3
     25: A0--  B-1--  C--2-  D0---
     26: A0--  B-1--  C--2-  D-1--
     27: A0--  B-1--  C--2-  D--2-
     28: A0--  B-1--  C--2-  D---3
     29: A0--  B-1--  C---3  D0---
     30: A0--  B-1--  C---3  D-1--
     31: A0--  B-1--  C---3  D--2-
     32: A0--  B-1--  C---3  D---3
     33: A0--  B--2-  C0---  D0---
     34: A0--  B--2-  C0---  D-1--
     35: A0--  B--2-  C0---  D--2-
     36: A0--  B--2-  C0---  D---3
     37: A0--  B--2-  C-1--  D0---
     38: A0--  B--2-  C-1--  D-1--
     39: A0--  B--2-  C-1--  D--2-
     40: A0--  B--2-  C-1--  D---3
     41: A0--  B--2-  C--2-  D0---
     42: A0--  B--2-  C--2-  D-1--
     43: A0--  B--2-  C--2-  D--2-    -fcase-strict-lower
     44: A0--  B--2-  C--2-  D---3
     45: A0--  B--2-  C---3  D0---
     46: A0--  B--2-  C---3  D-1--
     47: A0--  B--2-  C---3  D--2-
     48: A0--  B--2-  C---3  D---3
     49: A0--  B---3  C0---  D0---
     50: A0--  B---3  C0---  D-1--
     51: A0--  B---3  C0---  D--2-
     52: A0--  B---3  C0---  D---3
     53: A0--  B---3  C-1--  D0---
     54: A0--  B---3  C-1--  D-1--
     55: A0--  B---3  C-1--  D--2-
     56: A0--  B---3  C-1--  D---3
     57: A0--  B---3  C--2-  D0---
     58: A0--  B---3  C--2-  D-1--
     59: A0--  B---3  C--2-  D--2-
     60: A0--  B---3  C--2-  D---3
     61: A0--  B---3  C---3  D0---
     62: A0--  B---3  C---3  D-1--
     63: A0--  B---3  C---3  D--2-
     64: A0--  B---3  C---3  D---3    -fcase-initcap
     65: A-1-  B01--  C01--  D01--    -fcase-upper
     66: A--2  B0-2-  C0-2-  D0-2-    -fcase-lower

   Number 22 is the "strict" ANSI FORTRAN 77 model wherein all input
(except comments, character constants, and Hollerith strings) must be
entered in uppercase.  Use `-fcase-strict-upper' to specify this
combination.

   Number 43 is like Number 22 except all input must be lowercase.  Use
`-fcase-strict-lower' to specify this combination.

   Number 65 is the "classic" ANSI FORTRAN 77 model as implemented on
many non-UNIX machines whereby all the source is translated to
uppercase.  Use `-fcase-upper' to specify this combination.

   Number 66 is the "canonical" UNIX model whereby all the source is
translated to lowercase.  Use `-fcase-lower' to specify this
combination.

   There are a few nearly useless combinations:

     67: A-1-  B01--  C01--  D--2-
     68: A-1-  B01--  C01--  D---3
     69: A-1-  B01--  C--23  D01--
     70: A-1-  B01--  C--23  D--2-
     71: A-1-  B01--  C--23  D---3
     72: A--2  B01--  C0-2-  D-1--
     73: A--2  B01--  C0-2-  D---3
     74: A--2  B01--  C-1-3  D0-2-
     75: A--2  B01--  C-1-3  D-1--
     76: A--2  B01--  C-1-3  D---3

   The above allow some programs to be compiled but with restrictions
that make most useful programs impossible: Numbers 67 and 72 warn about
_any_ user-defined symbol names (such as `SUBROUTINE FOO'); Numbers 68
and 73 warn about any user-defined symbol names longer than one
character that don't have at least one non-alphabetic character after
the first; Numbers 69 and 74 disallow any references to intrinsics; and
Numbers 70, 71, 75, and 76 are combinations of the restrictions in
67+69, 68+69, 72+74, and 73+74, respectively.

   All redundant combinations are shown in the above tables anyplace
where more than one setting is shown for a low-level switch.  For
example, `B0-2-' means either setting 0 or 2 is valid for switch B.
The "proper" setting in such a case is the one that copies the setting
of switch A--any other setting might slightly reduce the speed of the
compiler, though possibly to an unmeasurable extent.

   All remaining combinations are useless in that they prevent
successful compilation of non-null source files (source files with
something other than comments).


File: g77.info,  Node: VXT Fortran,  Next: Fortran 90,  Prev: Case Sensitivity,  Up: Other Dialects

VXT Fortran
===========

   `g77' supports certain constructs that have different meanings in
VXT Fortran than they do in the GNU Fortran language.

   Generally, this manual uses the invented term VXT Fortran to refer
VAX FORTRAN (circa v4).  That compiler offered many popular features,
though not necessarily those that are specific to the VAX processor
architecture, the VMS operating system, or Digital Equipment
Corporation's Fortran product line.  (VAX and VMS probably are
trademarks of Digital Equipment Corporation.)

   An extension offered by a Digital Fortran product that also is
offered by several other Fortran products for different kinds of
systems is probably going to be considered for inclusion in `g77'
someday, and is considered a VXT Fortran feature.

   The `-fvxt' option generally specifies that, where the meaning of a
construct is ambiguous (means one thing in GNU Fortran and another in
VXT Fortran), the VXT Fortran meaning is to be assumed.

* Menu:

* Double Quote Meaning::  `"2000' as octal constant.
* Exclamation Point::     `!' in column 6.


File: g77.info,  Node: Double Quote Meaning,  Next: Exclamation Point,  Up: VXT Fortran

Meaning of Double Quote
-----------------------

   `g77' treats double-quote (`"') as beginning an octal constant of
`INTEGER(KIND=1)' type when the `-fvxt' option is specified.  The form
of this octal constant is

     "OCTAL-DIGITS

where OCTAL-DIGITS is a nonempty string of characters in the set
`01234567'.

   For example, the `-fvxt' option permits this:

     PRINT *, "20
     END

The above program would print the value `16'.

   *Note Integer Type::, for information on the preferred construct for
integer constants specified using GNU Fortran's octal notation.

   (In the GNU Fortran language, the double-quote character (`"')
delimits a character constant just as does apostrophe (`'').  There is
no way to allow both constructs in the general case, since statements
like `PRINT *,"2000 !comment?"' would be ambiguous.)


File: g77.info,  Node: Exclamation Point,  Prev: Double Quote Meaning,  Up: VXT Fortran

Meaning of Exclamation Point in Column 6
----------------------------------------

   `g77' treats an exclamation point (`!') in column 6 of a fixed-form
source file as a continuation character rather than as the beginning of
a comment (as it does in any other column) when the `-fvxt' option is
specified.

   The following program, when run, prints a message indicating whether
it is interpreted according to GNU Fortran (and Fortran 90) rules or
VXT Fortran rules:

     C234567  (This line begins in column 1.)
           I = 0
          !1
           IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
           IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
           IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
           END

   (In the GNU Fortran and Fortran 90 languages, exclamation point is a
valid character and, unlike space (<SPC>) or zero (`0'), marks a line
as a continuation line when it appears in column 6.)


File: g77.info,  Node: Fortran 90,  Next: Pedantic Compilation,  Prev: VXT Fortran,  Up: Other Dialects

Fortran 90
==========

   The GNU Fortran language includes a number of features that are part
of Fortran 90, even when the `-ff90' option is not specified.  The
features enabled by `-ff90' are intended to be those that, when `-ff90'
is not specified, would have another meaning to `g77'--usually meaning
something invalid in the GNU Fortran language.

   So, the purpose of `-ff90' is not to specify whether `g77' is to
gratuitously reject Fortran 90 constructs.  The `-pedantic' option
specified with `-fno-f90' is intended to do that, although its
implementation is certainly incomplete at this point.

   When `-ff90' is specified:

   * The type of `REAL(EXPR)' and `AIMAG(EXPR)', where EXPR is
     `COMPLEX' type, is the same type as the real part of EXPR.

     For example, assuming `Z' is type `COMPLEX(KIND=2)', `REAL(Z)'
     would return a value of type `REAL(KIND=2)', not of type
     `REAL(KIND=1)', since `-ff90' is specified.


File: g77.info,  Node: Pedantic Compilation,  Next: Distensions,  Prev: Fortran 90,  Up: Other Dialects

Pedantic Compilation
====================

   The `-fpedantic' command-line option specifies that `g77' is to warn
about code that is not standard-conforming.  This is useful for finding
some extensions `g77' accepts that other compilers might not accept.
(Note that the `-pedantic' and `-pedantic-errors' options always imply
`-fpedantic'.)

   With `-fno-f90' in force, ANSI FORTRAN 77 is used as the standard
for conforming code.  With `-ff90' in force, Fortran 90 is used.

   The constructs for which `g77' issues diagnostics when `-fpedantic'
and `-fno-f90' are in force are:

   * Automatic arrays, as in

          SUBROUTINE X(N)
          REAL A(N)
          ...

     where `A' is not listed in any `ENTRY' statement, and thus is not
     a dummy argument.

   * The commas in `READ (5), I' and `WRITE (10), J'.

     These commas are disallowed by FORTRAN 77, but, while strictly
     superfluous, are syntactically elegant, especially given that
     commas are required in statements such as `READ 99, I' and `PRINT
     *, J'.  Many compilers permit the superfluous commas for this
     reason.

   * `DOUBLE COMPLEX', either explicitly or implicitly.

     An explicit use of this type is via a `DOUBLE COMPLEX' or
     `IMPLICIT DOUBLE COMPLEX' statement, for examples.

     An example of an implicit use is the expression `C*D', where `C'
     is `COMPLEX(KIND=1)' and `D' is `DOUBLE PRECISION'.  This
     expression is prohibited by ANSI FORTRAN 77 because the rules of
     promotion would suggest that it produce a `DOUBLE COMPLEX'
     result--a type not provided for by that standard.

   * Automatic conversion of numeric expressions to `INTEGER(KIND=1)'
     in contexts such as:

        - Array-reference indexes.

        - Alternate-return values.

        - Computed `GOTO'.

        - `FORMAT' run-time expressions (not yet supported).

        - Dimension lists in specification statements.

        - Numbers for I/O statements (such as `READ (UNIT=3.2), I')

        - Sizes of `CHARACTER' entities in specification statements.

        - Kind types in specification entities (a Fortran 90 feature).

        - Initial, terminal, and incrementation parameters for
          implied-`DO' constructs in `DATA' statements.

   * Automatic conversion of `LOGICAL' expressions to `INTEGER' in
     contexts such as arithmetic `IF' (where `COMPLEX' expressions are
     disallowed anyway).

   * Zero-size array dimensions, as in:

          INTEGER I(10,20,4:2)

   * Zero-length `CHARACTER' entities, as in:

          PRINT *, ''

   * Substring operators applied to character constants and named
     constants, as in:

          PRINT *, 'hello'(3:5)

   * Null arguments passed to statement function, as in:

          PRINT *, FOO(,3)

   * Disagreement among program units regarding whether a given `COMMON'
     area is `SAVE'd (for targets where program units in a single source
     file are "glued" together as they typically are for UNIX
     development environments).

   * Disagreement among program units regarding the size of a named
     `COMMON' block.

   * Specification statements following first `DATA' statement.

     (In the GNU Fortran language, `DATA I/1/' may be followed by
     `INTEGER J', but not `INTEGER I'.  The `-fpedantic' option
     disallows both of these.)

   * Semicolon as statement separator, as in:

          CALL FOO; CALL BAR

   * Use of `&' in column 1 of fixed-form source (to indicate
     continuation).

   * Use of `CHARACTER' constants to initialize numeric entities, and
     vice versa.

   * Expressions having two arithmetic operators in a row, such as
     `X*-Y'.

   If `-fpedantic' is specified along with `-ff90', the following
constructs result in diagnostics:

   * Use of semicolon as a statement separator on a line that has an
     `INCLUDE' directive.


File: g77.info,  Node: Distensions,  Prev: Pedantic Compilation,  Up: Other Dialects

Distensions
===========

   The `-fugly-*' command-line options determine whether certain
features supported by VAX FORTRAN and other such compilers, but
considered too ugly to be in code that can be changed to use safer
and/or more portable constructs, are accepted.  These are humorously
referred to as "distensions", extensions that just plain look ugly in
the harsh light of day.

* Menu:

* Ugly Implicit Argument Conversion::  Disabled via `-fno-ugly-args'.
* Ugly Assumed-Size Arrays::           Enabled via `-fugly-assumed'.
* Ugly Null Arguments::                Enabled via `-fugly-comma'.
* Ugly Complex Part Extraction::       Enabled via `-fugly-complex'.
* Ugly Conversion of Initializers::    Disabled via `-fno-ugly-init'.
* Ugly Integer Conversions::           Enabled via `-fugly-logint'.
* Ugly Assigned Labels::               Enabled via `-fugly-assign'.


File: g77.info,  Node: Ugly Implicit Argument Conversion,  Next: Ugly Assumed-Size Arrays,  Up: Distensions

Implicit Argument Conversion
----------------------------

   The `-fno-ugly-args' option disables passing typeless and Hollerith
constants as actual arguments in procedure invocations.  For example:

     CALL FOO(4HABCD)
     CALL BAR('123'O)

These constructs can be too easily used to create non-portable code,
but are not considered as "ugly" as others.  Further, they are widely
used in existing Fortran source code in ways that often are quite
portable.  Therefore, they are enabled by default.


File: g77.info,  Node: Ugly Assumed-Size Arrays,  Next: Ugly Null Arguments,  Prev: Ugly Implicit Argument Conversion,  Up: Distensions

Ugly Assumed-Size Arrays
------------------------

   The `-fugly-assumed' option enables the treatment of any array with
a final dimension specified as `1' as an assumed-size array, as if `*'
had been specified instead.

   For example, `DIMENSION X(1)' is treated as if it had read
`DIMENSION X(*)' if `X' is listed as a dummy argument in a preceding
`SUBROUTINE', `FUNCTION', or `ENTRY' statement in the same program unit.

   Use an explicit lower bound to avoid this interpretation.  For
example, `DIMENSION X(1:1)' is never treated as if it had read
`DIMENSION X(*)' or `DIMENSION X(1:*)'.  Nor is `DIMENSION X(2-1)'
affected by this option, since that kind of expression is unlikely to
have been intended to designate an assumed-size array.

   This option is used to prevent warnings being issued about apparent
out-of-bounds reference such as `X(2) = 99'.

   It also prevents the array from being used in contexts that disallow
assumed-size arrays, such as `PRINT *,X'.  In such cases, a diagnostic
is generated and the source file is not compiled.

   The construct affected by this option is used only in old code that
pre-exists the widespread acceptance of adjustable and assumed-size
arrays in the Fortran community.

   _Note:_ This option does not affect how `DIMENSION X(1)' is treated
if `X' is listed as a dummy argument only _after_ the `DIMENSION'
statement (presumably in an `ENTRY' statement).  For example,
`-fugly-assumed' has no effect on the following program unit:

     SUBROUTINE X
     REAL A(1)
     RETURN
     ENTRY Y(A)
     PRINT *, A
     END


File: g77.info,  Node: Ugly Complex Part Extraction,  Next: Ugly Conversion of Initializers,  Prev: Ugly Null Arguments,  Up: Distensions

Ugly Complex Part Extraction
----------------------------

   The `-fugly-complex' option enables use of the `REAL()' and `AIMAG()'
intrinsics with arguments that are `COMPLEX' types other than
`COMPLEX(KIND=1)'.

   With `-ff90' in effect, these intrinsics return the unconverted real
and imaginary parts (respectively) of their argument.

   With `-fno-f90' in effect, these intrinsics convert the real and
imaginary parts to `REAL(KIND=1)', and return the result of that
conversion.

   Due to this ambiguity, the GNU Fortran language defines these
constructs as invalid, except in the specific case where they are
entirely and solely passed as an argument to an invocation of the
`REAL()' intrinsic.  For example,

     REAL(REAL(Z))

is permitted even when `Z' is `COMPLEX(KIND=2)' and `-fno-ugly-complex'
is in effect, because the meaning is clear.

   `g77' enforces this restriction, unless `-fugly-complex' is
specified, in which case the appropriate interpretation is chosen and
no diagnostic is issued.

   *Note CMPAMBIG::, for information on how to cope with existing code
with unclear expectations of `REAL()' and `AIMAG()' with
`COMPLEX(KIND=2)' arguments.

   *Note RealPart Intrinsic::, for information on the `REALPART()'
intrinsic, used to extract the real part of a complex expression
without conversion.  *Note ImagPart Intrinsic::, for information on the
`IMAGPART()' intrinsic, used to extract the imaginary part of a complex
expression without conversion.


File: g77.info,  Node: Ugly Null Arguments,  Next: Ugly Complex Part Extraction,  Prev: Ugly Assumed-Size Arrays,  Up: Distensions

Ugly Null Arguments
-------------------

   The `-fugly-comma' option enables use of a single trailing comma to
mean "pass an extra trailing null argument" in a list of actual
arguments to an external procedure, and use of an empty list of
arguments to such a procedure to mean "pass a single null argument".

   (Null arguments often are used in some procedure-calling schemes to
indicate omitted arguments.)

   For example, `CALL FOO(,)' means "pass two null arguments", rather
than "pass one null argument".  Also, `CALL BAR()' means "pass one null
argument".

   This construct is considered "ugly" because it does not provide an
elegant way to pass a single null argument that is syntactically
distinct from passing no arguments.  That is, this construct changes
the meaning of code that makes no use of the construct.

   So, with `-fugly-comma' in force, `CALL FOO()' and `I = JFUNC()'
pass a single null argument, instead of passing no arguments as
required by the Fortran 77 and 90 standards.

   _Note:_ Many systems gracefully allow the case where a procedure
call passes one extra argument that the called procedure does not
expect.

   So, in practice, there might be no difference in the behavior of a
program that does `CALL FOO()' or `I = JFUNC()' and is compiled with
`-fugly-comma' in force as compared to its behavior when compiled with
the default, `-fno-ugly-comma', in force, assuming `FOO' and `JFUNC' do
not expect any arguments to be passed.


File: g77.info,  Node: Ugly Conversion of Initializers,  Next: Ugly Integer Conversions,  Prev: Ugly Complex Part Extraction,  Up: Distensions

Ugly Conversion of Initializers
-------------------------------

   The constructs disabled by `-fno-ugly-init' are:

   * Use of Hollerith and typeless constants in contexts where they set
     initial (compile-time) values for variables, arrays, and named
     constants--that is, `DATA' and `PARAMETER' statements, plus
     type-declaration statements specifying initial values.

     Here are some sample initializations that are disabled by the
     `-fno-ugly-init' option:

          PARAMETER (VAL='9A304FFE'X)
          REAL*8 STRING/8HOUTPUT00/
          DATA VAR/4HABCD/

   * In the same contexts as above, use of character constants to
     initialize numeric items and vice versa (one constant per item).

     Here are more sample initializations that are disabled by the
     `-fno-ugly-init' option:

          INTEGER IA
          CHARACTER BELL
          PARAMETER (IA = 'A')
          PARAMETER (BELL = 7)

   * Use of Hollerith and typeless constants on the right-hand side of
     assignment statements to numeric types, and in other contexts
     (such as passing arguments in invocations of intrinsic procedures
     and statement functions) that are treated as assignments to known
     types (the dummy arguments, in these cases).

     Here are sample statements that are disabled by the
     `-fno-ugly-init' option:

          IVAR = 4HABCD
          PRINT *, IMAX0(2HAB, 2HBA)

   The above constructs, when used, can tend to result in non-portable
code.  But, they are widely used in existing Fortran code in ways that
often are quite portable.  Therefore, they are enabled by default.


File: g77.info,  Node: Ugly Integer Conversions,  Next: Ugly Assigned Labels,  Prev: Ugly Conversion of Initializers,  Up: Distensions

Ugly Integer Conversions
------------------------

   The constructs enabled via `-fugly-logint' are:

   * Automatic conversion between `INTEGER' and `LOGICAL' as dictated by
     context (typically implies nonportable dependencies on how a
     particular implementation encodes `.TRUE.' and `.FALSE.').

   * Use of a `LOGICAL' variable in `ASSIGN' and assigned-`GOTO'
     statements.

   The above constructs are disabled by default because use of them
tends to lead to non-portable code.  Even existing Fortran code that
uses that often turns out to be non-portable, if not outright buggy.

   Some of this is due to differences among implementations as far as
how `.TRUE.' and `.FALSE.' are encoded as `INTEGER' values--Fortran
code that assumes a particular coding is likely to use one of the above
constructs, and is also likely to not work correctly on implementations
using different encodings.

   *Note Equivalence Versus Equality::, for more information.


File: g77.info,  Node: Ugly Assigned Labels,  Prev: Ugly Integer Conversions,  Up: Distensions

Ugly Assigned Labels
--------------------

   The `-fugly-assign' option forces `g77' to use the same storage for
assigned labels as it would for a normal assignment to the same
variable.

   For example, consider the following code fragment:

     I = 3
     ASSIGN 10 TO I

Normally, for portability and improved diagnostics, `g77' reserves
distinct storage for a "sibling" of `I', used only for `ASSIGN'
statements to that variable (along with the corresponding
assigned-`GOTO' and assigned-`FORMAT'-I/O statements that reference the
variable).

   However, some code (that violates the ANSI FORTRAN 77 standard)
attempts to copy assigned labels among variables involved with `ASSIGN'
statements, as in:

     ASSIGN 10 TO I
     ISTATE(5) = I
     ...
     J = ISTATE(ICUR)
     GOTO J

Such code doesn't work under `g77' unless `-fugly-assign' is specified
on the command-line, ensuring that the value of `I' referenced in the
second line is whatever value `g77' uses to designate statement label
`10', so the value may be copied into the `ISTATE' array, later
retrieved into a variable of the appropriate type (`J'), and used as
the target of an assigned-`GOTO' statement.

   _Note:_ To avoid subtle program bugs, when `-fugly-assign' is
specified, `g77' requires the type of variables specified in
assigned-label contexts _must_ be the same type returned by `%LOC()'.
On many systems, this type is effectively the same as
`INTEGER(KIND=1)', while, on others, it is effectively the same as
`INTEGER(KIND=2)'.

   Do _not_ depend on `g77' actually writing valid pointers to these
variables, however.  While `g77' currently chooses that implementation,
it might be changed in the future.

   *Note Assigned Statement Labels (ASSIGN and GOTO): Assigned
Statement Labels, for implementation details on assigned-statement
labels.


File: g77.info,  Node: Compiler,  Next: Other Dialects,  Prev: Language,  Up: Top

The GNU Fortran Compiler
************************

   The GNU Fortran compiler, `g77', supports programs written in the
GNU Fortran language and in some other dialects of Fortran.

   Some aspects of how `g77' works are universal regardless of dialect,
and yet are not properly part of the GNU Fortran language itself.
These are described below.

   _Note: This portion of the documentation definitely needs a lot of
work!_

* Menu:

* Compiler Limits::
* Run-time Environment Limits::
* Compiler Types::
* Compiler Constants::
* Compiler Intrinsics::


File: g77.info,  Node: Compiler Limits,  Next: Run-time Environment Limits,  Up: Compiler

Compiler Limits
===============

   `g77', as with GNU tools in general, imposes few arbitrary
restrictions on lengths of identifiers, number of continuation lines,
number of external symbols in a program, and so on.

   For example, some other Fortran compiler have an option (such as
`-NlX') to increase the limit on the number of continuation lines.
Also, some Fortran compilation systems have an option (such as `-NxX')
to increase the limit on the number of external symbols.

   `g77', `gcc', and GNU `ld' (the GNU linker) have no equivalent
options, since they do not impose arbitrary limits in these areas.

   `g77' does currently limit the number of dimensions in an array to
the same degree as do the Fortran standards--seven (7).  This
restriction might be lifted in a future version.


File: g77.info,  Node: Run-time Environment Limits,  Next: Compiler Types,  Prev: Compiler Limits,  Up: Compiler

Run-time Environment Limits
===========================

   As a portable Fortran implementation, `g77' offers its users direct
access to, and otherwise depends upon, the underlying facilities of the
system used to build `g77', the system on which `g77' itself is used to
compile programs, and the system on which the `g77'-compiled program is
actually run.  (For most users, the three systems are of the same
type--combination of operating environment and hardware--often the same
physical system.)

   The run-time environment for a particular system inevitably imposes
some limits on a program's use of various system facilities.  These
limits vary from system to system.

   Even when such limits might be well beyond the possibility of being
encountered on a particular system, the `g77' run-time environment has
certain built-in limits, usually, but not always, stemming from
intrinsics with inherently limited interfaces.

   Currently, the `g77' run-time environment does not generally offer a
less-limiting environment by augmenting the underlying system's own
environment.

   Therefore, code written in the GNU Fortran language, while
syntactically and semantically portable, might nevertheless make
non-portable assumptions about the run-time environment--assumptions
that prove to be false for some particular environments.

   The GNU Fortran language, the `g77' compiler and run-time
environment, and the `g77' documentation do not yet offer comprehensive
portable work-arounds for such limits, though programmers should be
able to find their own in specific instances.

   Not all of the limitations are described in this document.  Some of
the known limitations include:

* Menu:

* Timer Wraparounds::
* Year 2000 (Y2K) Problems::
* Array Size::
* Character-variable Length::
* Year 10000 (Y10K) Problems::


File: g77.info,  Node: Timer Wraparounds,  Next: Year 2000 (Y2K) Problems,  Up: Run-time Environment Limits

Timer Wraparounds
-----------------

   Intrinsics that return values computed from system timers, whether
elapsed (wall-clock) timers, process CPU timers, or other kinds of
timers, are prone to experiencing wrap-around errors (or returning
wrapped-around values from successive calls) due to insufficient ranges
offered by the underlying system's timers.

   Some of the symptoms of such behaviors include apparently negative
time being computed for a duration, an extremely short amount of time
being computed for a long duration, and an extremely long amount of
time being computed for a short duration.

   See the following for intrinsics known to have potential problems in
these areas on at least some systems: *Note CPU_Time Intrinsic::, *Note
DTime Intrinsic (function)::, *Note DTime Intrinsic (subroutine)::,
*Note ETime Intrinsic (function)::, *Note ETime Intrinsic
(subroutine)::, *Note MClock Intrinsic::, *Note MClock8 Intrinsic::,
*Note Secnds Intrinsic::, *Note Second Intrinsic (function)::, *Note
Second Intrinsic (subroutine)::, *Note System_Clock Intrinsic::, *Note
Time Intrinsic (UNIX)::, *Note Time Intrinsic (VXT)::, *Note Time8
Intrinsic::.


File: g77.info,  Node: Year 2000 (Y2K) Problems,  Next: Array Size,  Prev: Timer Wraparounds,  Up: Run-time Environment Limits

Year 2000 (Y2K) Problems
------------------------

   While the `g77' compiler itself is believed to be Year-2000 (Y2K)
compliant, some intrinsics are not, and, potentially, some underlying
systems are not, perhaps rendering some Y2K-compliant intrinsics
non-compliant when used on those particular systems.

   Fortran code that uses non-Y2K-compliant intrinsics (listed below)
is, itself, almost certainly not compliant, and should be modified to
use Y2K-compliant intrinsics instead.

   Fortran code that uses no non-Y2K-compliant intrinsics, but which
currently is running on a non-Y2K-compliant system, can be made more
Y2K compliant by compiling and linking it for use on a new
Y2K-compliant system, such as a new version of an old,
non-Y2K-compliant, system.

   Currently, information on Y2K and related issues is being maintained
at `http://www.gnu.org/software/year2000-list.html'.

   See the following for intrinsics known to have potential problems in
these areas on at least some systems: *Note Date Intrinsic::, *Note
IDate Intrinsic (VXT)::.

   The `libg2c' library shipped with any `g77' that warns about
invocation of a non-Y2K-compliant intrinsic has renamed the `EXTERNAL'
procedure names of those intrinsics.  This is done so that the `libg2c'
implementations of these intrinsics cannot be directly linked to as
`EXTERNAL' names (which normally would avoid the non-Y2K-intrinsic
warning).

   The renamed forms of the `EXTERNAL' names of these renamed procedures
may be linked to by appending the string `_y2kbug' to the name of the
procedure in the source code.  For example:

     CHARACTER*20 STR
     INTEGER YY, MM, DD
     EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
     CALL DATE_Y2KBUG (STR)
     CALL VXTIDATE_Y2KBUG (MM, DD, YY)

   (Note that the `EXTERNAL' statement is not actually required, since
the modified names are not recognized as intrinsics by the current
version of `g77'.  But it is shown in this specific case, for purposes
of illustration.)

   The renaming of `EXTERNAL' procedure names of these intrinsics
causes unresolved references at link time.  For example, `EXTERNAL
DATE; CALL DATE(STR)' is normally compiled by `g77' as, in C,
`date_(&str, 20);'.  This, in turn, links to the `date_' procedure in
the `libE77' portion of `libg2c', which purposely calls a nonexistent
procedure named `G77_date_y2kbuggy_0'.  The resulting link-time error
is designed, via this name, to encourage the programmer to look up the
index entries to this portion of the `g77' documentation.

   Generally, we recommend that the `EXTERNAL' method of invoking
procedures in `libg2c' _not_ be used.  When used, some of the
correctness checking normally performed by `g77' is skipped.

   In particular, it is probably better to use the `INTRINSIC' method
of invoking non-Y2K-compliant procedures, so anyone compiling the code
can quickly notice the potential Y2K problems (via the warnings
printing by `g77') without having to even look at the code itself.

   If there are problems linking `libg2c' to code compiled by `g77'
that involve the string `y2kbug', and these are not explained above,
that probably indicates that a version of `libg2c' older than `g77' is
being linked to, or that the new library is being linked to code
compiled by an older version of `g77'.

   That's because, as of the version that warns about non-Y2K-compliant
intrinsic invocation, `g77' references the `libg2c' implementations of
those intrinsics using new names, containing the string `y2kbug'.

   So, linking newly-compiled code (invoking one of the intrinsics in
question) to an old library might yield an unresolved reference to
`G77_date_y2kbug_0'.  (The old library calls it `G77_date_0'.)

   Similarly, linking previously-compiled code to a new library might
yield an unresolved reference to `G77_vxtidate_0'.  (The new library
calls it `G77_vxtidate_y2kbug_0'.)

   The proper fix for the above problems is to obtain the latest
release of `g77' and related products (including `libg2c') and install
them on all systems, then recompile, relink, and install (as
appropriate) all existing Fortran programs.

   (Normally, this sort of renaming is steadfastly avoided.  In this
case, however, it seems more important to highlight potential Y2K
problems than to ease the transition of potentially non-Y2K-compliant
code to new versions of `g77' and `libg2c'.)


File: g77.info,  Node: Array Size,  Next: Character-variable Length,  Prev: Year 2000 (Y2K) Problems,  Up: Run-time Environment Limits

Array Size
----------

   Currently, `g77' uses the default `INTEGER' type for array indexes,
which limits the sizes of single-dimension arrays on systems offering a
larger address space than can be addressed by that type.  (That `g77'
puts all arrays in memory could be considered another limitation--it
could use large temporary files--but that decision is left to the
programmer as an implementation choice by most Fortran implementations.)

   It is not yet clear whether this limitation never, sometimes, or
always applies to the sizes of multiple-dimension arrays as a whole.

   For example, on a system with 64-bit addresses and 32-bit default
`INTEGER', an array with a size greater than can be addressed by a
32-bit offset can be declared using multiple dimensions.  Such an array
is therefore larger than a single-dimension array can be, on the same
system.

   Whether large multiple-dimension arrays are reliably supported
depends mostly on the `gcc' back end (code generator) used by `g77',
and has not yet been fully investigated.


File: g77.info,  Node: Character-variable Length,  Next: Year 10000 (Y10K) Problems,  Prev: Array Size,  Up: Run-time Environment Limits

Character-variable Length
-------------------------

   Currently, `g77' uses the default `INTEGER' type for the lengths of
`CHARACTER' variables and array elements.

   This means that, for example, a system with a 64-bit address space
and a 32-bit default `INTEGER' type does not, under `g77', support a
`CHARACTER*N' declaration where N is greater than 2147483647.


File: g77.info,  Node: Year 10000 (Y10K) Problems,  Prev: Character-variable Length,  Up: Run-time Environment Limits

Year 10000 (Y10K) Problems
--------------------------

   Most intrinsics returning, or computing values based on, date
information are prone to Year-10000 (Y10K) problems, due to supporting
only 4 digits for the year.

   See the following for examples: *Note FDate Intrinsic (function)::,
*Note FDate Intrinsic (subroutine)::, *Note IDate Intrinsic (UNIX)::,
*Note Time Intrinsic (VXT)::, *Note Date_and_Time Intrinsic::.


File: g77.info,  Node: Compiler Types,  Next: Compiler Constants,  Prev: Run-time Environment Limits,  Up: Compiler

Compiler Types
==============

   Fortran implementations have a fair amount of freedom given them by
the standard as far as how much storage space is used and how much
precision and range is offered by the various types such as
`LOGICAL(KIND=1)', `INTEGER(KIND=1)', `REAL(KIND=1)', `REAL(KIND=2)',
`COMPLEX(KIND=1)', and `CHARACTER'.  Further, many compilers offer
so-called `*N' notation, but the interpretation of N varies across
compilers and target architectures.

   The standard requires that `LOGICAL(KIND=1)', `INTEGER(KIND=1)', and
`REAL(KIND=1)' occupy the same amount of storage space, and that
`COMPLEX(KIND=1)' and `REAL(KIND=2)' take twice as much storage space
as `REAL(KIND=1)'.  Further, it requires that `COMPLEX(KIND=1)'
entities be ordered such that when a `COMPLEX(KIND=1)' variable is
storage-associated (such as via `EQUIVALENCE') with a two-element
`REAL(KIND=1)' array named `R', `R(1)' corresponds to the real element
and `R(2)' to the imaginary element of the `COMPLEX(KIND=1)' variable.

   (Few requirements as to precision or ranges of any of these are
placed on the implementation, nor is the relationship of storage sizes
of these types to the `CHARACTER' type specified, by the standard.)

   `g77' follows the above requirements, warning when compiling a
program requires placement of items in memory that contradict the
requirements of the target architecture.  (For example, a program can
require placement of a `REAL(KIND=2)' on a boundary that is not an even
multiple of its size, but still an even multiple of the size of a
`REAL(KIND=1)' variable.  On some target architectures, using the
canonical mapping of Fortran types to underlying architectural types,
such placement is prohibited by the machine definition or the
Application Binary Interface (ABI) in force for the configuration
defined for building `gcc' and `g77'.  `g77' warns about such
situations when it encounters them.)

   `g77' follows consistent rules for configuring the mapping between
Fortran types, including the `*N' notation, and the underlying
architectural types as accessed by a similarly-configured applicable
version of the `gcc' compiler.  These rules offer a widely portable,
consistent Fortran/C environment, although they might well conflict
with the expectations of users of Fortran compilers designed and
written for particular architectures.

   These rules are based on the configuration that is in force for the
version of `gcc' built in the same release as `g77' (and which was
therefore used to build both the `g77' compiler components and the
`libg2c' run-time library):

`REAL(KIND=1)'
     Same as `float' type.

`REAL(KIND=2)'
     Same as whatever floating-point type that is twice the size of a
     `float'--usually, this is a `double'.

`INTEGER(KIND=1)'
     Same as an integral type that is occupies the same amount of
     memory storage as `float'--usually, this is either an `int' or a
     `long int'.

`LOGICAL(KIND=1)'
     Same `gcc' type as `INTEGER(KIND=1)'.

`INTEGER(KIND=2)'
     Twice the size, and usually nearly twice the range, as
     `INTEGER(KIND=1)'--usually, this is either a `long int' or a `long
     long int'.

`LOGICAL(KIND=2)'
     Same `gcc' type as `INTEGER(KIND=2)'.

`INTEGER(KIND=3)'
     Same `gcc' type as signed `char'.

`LOGICAL(KIND=3)'
     Same `gcc' type as `INTEGER(KIND=3)'.

`INTEGER(KIND=6)'
     Twice the size, and usually nearly twice the range, as
     `INTEGER(KIND=3)'--usually, this is a `short'.

`LOGICAL(KIND=6)'
     Same `gcc' type as `INTEGER(KIND=6)'.

`COMPLEX(KIND=1)'
     Two `REAL(KIND=1)' scalars (one for the real part followed by one
     for the imaginary part).

`COMPLEX(KIND=2)'
     Two `REAL(KIND=2)' scalars.

`NUMERIC-TYPE*N'
     (Where NUMERIC-TYPE is any type other than `CHARACTER'.)  Same as
     whatever `gcc' type occupies N times the storage space of a `gcc'
     `char' item.

`DOUBLE PRECISION'
     Same as `REAL(KIND=2)'.

`DOUBLE COMPLEX'
     Same as `COMPLEX(KIND=2)'.

   Note that the above are proposed correspondences and might change in
future versions of `g77'--avoid writing code depending on them.

   Other types supported by `g77' are derived from gcc types such as
`char', `short', `int', `long int', `long long int', `long double', and
so on.  That is, whatever types `gcc' already supports, `g77' supports
now or probably will support in a future version.  The rules for the
`NUMERIC-TYPE*N' notation apply to these types, and new values for
`NUMERIC-TYPE(KIND=N)' will be assigned in a way that encourages
clarity, consistency, and portability.


File: g77.info,  Node: Compiler Constants,  Next: Compiler Intrinsics,  Prev: Compiler Types,  Up: Compiler

Compiler Constants
==================

   `g77' strictly assigns types to _all_ constants not documented as
"typeless" (typeless constants including `'1'Z', for example).  Many
other Fortran compilers attempt to assign types to typed constants
based on their context.  This results in hard-to-find bugs, nonportable
code, and is not in the spirit (though it strictly follows the letter)
of the 77 and 90 standards.

   `g77' might offer, in a future release, explicit constructs by which
a wider variety of typeless constants may be specified, and/or
user-requested warnings indicating places where `g77' might differ from
how other compilers assign types to constants.

   *Note Context-Sensitive Constants::, for more information on this
issue.


File: g77.info,  Node: Compiler Intrinsics,  Prev: Compiler Constants,  Up: Compiler

Compiler Intrinsics
===================

   `g77' offers an ever-widening set of intrinsics.  Currently these
all are procedures (functions and subroutines).

   Some of these intrinsics are unimplemented, but their names reserved
to reduce future problems with existing code as they are implemented.
Others are implemented as part of the GNU Fortran language, while yet
others are provided for compatibility with other dialects of Fortran
but are not part of the GNU Fortran language.

   To manage these distinctions, `g77' provides intrinsic _groups_, a
facility that is simply an extension of the intrinsic groups provided
by the GNU Fortran language.

* Menu:

* Intrinsic Groups::  How intrinsics are grouped for easy management.
* Other Intrinsics::  Intrinsics other than those in the GNU
                       Fortran language.


File: g77.info,  Node: Intrinsic Groups,  Next: Other Intrinsics,  Up: Compiler Intrinsics

Intrinsic Groups
----------------

   A given specific intrinsic belongs in one or more groups.  Each
group is deleted, disabled, hidden, or enabled by default or a
command-line option.  The meaning of each term follows.

Deleted
     No intrinsics are recognized as belonging to that group.

Disabled
     Intrinsics are recognized as belonging to the group, but
     references to them (other than via the `INTRINSIC' statement) are
     disallowed through that group.

Hidden
     Intrinsics in that group are recognized and enabled (if
     implemented) _only_ if the first mention of the actual name of an
     intrinsic in a program unit is in an `INTRINSIC' statement.

Enabled
     Intrinsics in that group are recognized and enabled (if
     implemented).

   The distinction between deleting and disabling a group is illustrated
by the following example.  Assume intrinsic `FOO' belongs only to group
`FGR'.  If group `FGR' is deleted, the following program unit will
successfully compile, because `FOO()' will be seen as a reference to an
external function named `FOO':

     PRINT *, FOO()
     END

If group `FGR' is disabled, compiling the above program will produce
diagnostics, either because the `FOO' intrinsic is improperly invoked
or, if properly invoked, it is not enabled.  To change the above
program so it references an external function `FOO' instead of the
disabled `FOO' intrinsic, add the following line to the top:

     EXTERNAL FOO

So, deleting a group tells `g77' to pretend as though the intrinsics in
that group do not exist at all, whereas disabling it tells `g77' to
recognize them as (disabled) intrinsics in intrinsic-like contexts.

   Hiding a group is like enabling it, but the intrinsic must be first
named in an `INTRINSIC' statement to be considered a reference to the
intrinsic rather than to an external procedure.  This might be the
"safest" way to treat a new group of intrinsics when compiling old
code, because it allows the old code to be generally written as if
those new intrinsics never existed, but to be changed to use them by
inserting `INTRINSIC' statements in the appropriate places.  However,
it should be the goal of development to use `EXTERNAL' for all names of
external procedures that might be intrinsic names.

   If an intrinsic is in more than one group, it is enabled if any of
its containing groups are enabled; if not so enabled, it is hidden if
any of its containing groups are hidden; if not so hidden, it is
disabled if any of its containing groups are disabled; if not so
disabled, it is deleted.  This extra complication is necessary because
some intrinsics, such as `IBITS', belong to more than one group, and
hence should be enabled if any of the groups to which they belong are
enabled, and so on.

   The groups are:

`badu77'
     UNIX intrinsics having inappropriate forms (usually functions that
     have intended side effects).

`gnu'
     Intrinsics the GNU Fortran language supports that are extensions to
     the Fortran standards (77 and 90).

`f2c'
     Intrinsics supported by AT&T's `f2c' converter and/or `libf2c'.

`f90'
     Fortran 90 intrinsics.

`mil'
     MIL-STD 1753 intrinsics (`MVBITS', `IAND', `BTEST', and so on).

`unix'
     UNIX intrinsics (`IARGC', `EXIT', `ERF', and so on).

`vxt'
     VAX/VMS FORTRAN (current as of v4) intrinsics.

