This is Info file ../g77-0.5.23/f/g77.info, produced by Makeinfo
version 1.68 from the input file ../g77-0.5.23/f/g77.texi.

   This file explains how to use the GNU Fortran system.

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

   Copyright (C) 1995-1997 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 (<burley@gnu.org>).  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>).

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* g77: (g77).                  The GNU Fortran compiler.
END-INFO-DIR-ENTRY


File: g77.info,  Node: Expressions in FORMAT Statements,  Next: Explicit Assembler Code,  Prev: FLUSH Statement,  Up: Missing Features

Expressions in `FORMAT' Statements
----------------------------------

   `g77' doesn't support `FORMAT(I<J>)' and the like.  Supporting this
requires a significant redesign or replacement of `libg2c'.

   However, `g77' does support this construct when the expression is
constant (as of version 0.5.22).  For example:

           PARAMETER (IWIDTH = 12)
     10    FORMAT (I<IWIDTH>)

   Otherwise, at least for output (`PRINT' and `WRITE'), Fortran code
making use of this feature can be rewritten to avoid it by constructing
the `FORMAT' string in a `CHARACTER' variable or array, then using that
variable or array in place of the `FORMAT' statement label to do the
original `PRINT' or `WRITE'.

   Many uses of this feature on input can be rewritten this way as
well, but not all can.  For example, this can be rewritten:

           READ 20, I
     20    FORMAT (I<J>)

   However, this cannot, in general, be rewritten, especially when
`ERR=' and `END=' constructs are employed:

           READ 30, J, I
     30    FORMAT (I<J>)


File: g77.info,  Node: Explicit Assembler Code,  Next: Q Edit Descriptor,  Prev: Expressions in FORMAT Statements,  Up: Missing Features

Explicit Assembler Code
-----------------------

   `g77' needs to provide some way, a la `gcc', for `g77' code to
specify explicit assembler code.


File: g77.info,  Node: Q Edit Descriptor,  Next: Old-style PARAMETER Statements,  Prev: Explicit Assembler Code,  Up: Missing Features

Q Edit Descriptor
-----------------

   The `Q' edit descriptor in `FORMAT's isn't supported.  (This is
meant to get the number of characters remaining in an input record.)
Supporting this requires a significant redesign or replacement of
`libg2c'.

   A workaround might be using internal I/O or the stream-based
intrinsics.  *Note FGetC Intrinsic (subroutine)::.


File: g77.info,  Node: Old-style PARAMETER Statements,  Next: TYPE and ACCEPT I/O Statements,  Prev: Q Edit Descriptor,  Up: Missing Features

Old-style PARAMETER Statements
------------------------------

   `g77' doesn't accept `PARAMETER I=1'.  Supporting this obsolete form
of the `PARAMETER' statement would not be particularly hard, as most of
the parsing code is already in place and working.

   Until time/money is spent implementing it, you might as well fix
your code to use the standard form, `PARAMETER (I=1)' (possibly needing
`INTEGER I' preceding the `PARAMETER' statement as well, otherwise, in
the obsolete form of `PARAMETER', the type of the variable is set from
the type of the constant being assigned to it).


File: g77.info,  Node: TYPE and ACCEPT I/O Statements,  Next: STRUCTURE UNION RECORD MAP,  Prev: Old-style PARAMETER Statements,  Up: Missing Features

`TYPE' and `ACCEPT' I/O Statements
----------------------------------

   `g77' doesn't support the I/O statements `TYPE' and `ACCEPT'.  These
are common extensions that should be easy to support, but also are
fairly easy to work around in user code.

   Generally, any `TYPE fmt,list' I/O statement can be replaced by
`PRINT fmt,list'.  And, any `ACCEPT fmt,list' statement can be replaced
by `READ fmt,list'.


File: g77.info,  Node: STRUCTURE UNION RECORD MAP,  Next: OPEN CLOSE and INQUIRE Keywords,  Prev: TYPE and ACCEPT I/O Statements,  Up: Missing Features

`STRUCTURE', `UNION', `RECORD', `MAP'
-------------------------------------

   `g77' doesn't support `STRUCTURE', `UNION', `RECORD', `MAP'.  This
set of extensions is quite a bit lower on the list of large, important
things to add to `g77', partly because it requires a great deal of work
either upgrading or replacing `libg2c'.


File: g77.info,  Node: OPEN CLOSE and INQUIRE Keywords,  Next: ENCODE and DECODE,  Prev: STRUCTURE UNION RECORD MAP,  Up: Missing Features

`OPEN', `CLOSE', and `INQUIRE' Keywords
---------------------------------------

   `g77' doesn't have support for keywords such as `DISP='DELETE'' in
the `OPEN', `CLOSE', and `INQUIRE' statements.  These extensions are
easy to add to `g77' itself, but require much more work on `libg2c'.


File: g77.info,  Node: ENCODE and DECODE,  Next: Suppressing Space Padding,  Prev: OPEN CLOSE and INQUIRE Keywords,  Up: Missing Features

`ENCODE' and `DECODE'
---------------------

   `g77' doesn't support `ENCODE' or `DECODE'.

   These statements are best replaced by READ and WRITE statements
involving internal files (CHARACTER variables and arrays).

   For example, replace a code fragment like

           INTEGER*1 LINE(80)
     ...
           DECODE (80, 9000, LINE) A, B, C
     ...
     9000  FORMAT (1X, 3(F10.5))

with:

           CHARACTER*80 LINE
     ...
           READ (UNIT=LINE, FMT=9000) A, B, C
     ...
     9000  FORMAT (1X, 3(F10.5))

   Similarly, replace a code fragment like

           INTEGER*1 LINE(80)
     ...
           ENCODE (80, 9000, LINE) A, B, C
     ...
     9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

with:

           CHARACTER*80 LINE
     ...
           WRITE (UNIT=LINE, FMT=9000) A, B, C
     ...
     9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))

   It is entirely possible that `ENCODE' and `DECODE' will be supported
by a future version of `g77'.


File: g77.info,  Node: Suppressing Space Padding,  Next: Fortran Preprocessor,  Prev: ENCODE and DECODE,  Up: Missing Features

Suppressing Space Padding of Source Lines
-----------------------------------------

   `g77' should offer VXT-Fortran-style suppression of virtual spaces
at the end of a source line if an appropriate command-line option is
specified.

   This affects cases where a character constant is continued onto the
next line in a fixed-form source file, as in the following example:

     10    PRINT *,'HOW MANY
          1 SPACES?'

`g77', and many other compilers, virtually extend the continued line
through column 72 with spaces that become part of the character
constant, but Digital Fortran normally didn't, leaving only one space
between `MANY' and `SPACES?'  in the output of the above statement.

   Fairly recently, at least one version of Digital Fortran was
enhanced to provide the other behavior when a command-line option is
specified, apparently due to demand from readers of the USENET group
`comp.lang.fortran' to offer conformance to this widespread practice in
the industry.  `g77' should return the favor by offering conformance to
Digital's approach to handling the above example.


File: g77.info,  Node: Fortran Preprocessor,  Next: Bit Operations on Floating-point Data,  Prev: Suppressing Space Padding,  Up: Missing Features

Fortran Preprocessor
--------------------

   `g77' should offer a preprocessor designed specifically for Fortran
to replace `cpp -traditional'.  There are several out there worth
evaluating, at least.

   Such a preprocessor would recognize Hollerith constants, properly
parse comments and character constants, and so on.  It might also
recognize, process, and thus preprocess files included via the
`INCLUDE' directive.


File: g77.info,  Node: Bit Operations on Floating-point Data,  Next: POSIX Standard,  Prev: Fortran Preprocessor,  Up: Missing Features

Bit Operations on Floating-point Data
-------------------------------------

   `g77' does not allow `REAL' and other non-integral types for
arguments to intrinsics like `AND', `OR', and `SHIFT'.

   For example, this program is rejected by `g77', because the
intrinsic `IAND' does not accept `REAL' arguments:

     DATA A/7.54/, B/9.112/
     PRINT *, IAND(A, B)
     END


File: g77.info,  Node: POSIX Standard,  Next: Floating-point Exception Handling,  Prev: Bit Operations on Floating-point Data,  Up: Missing Features

`POSIX' Standard
----------------

   `g77' should support the POSIX standard for Fortran.


File: g77.info,  Node: Floating-point Exception Handling,  Next: Nonportable Conversions,  Prev: POSIX Standard,  Up: Missing Features

Floating-point Exception Handling
---------------------------------

   The `gcc' backend and, consequently, `g77', currently provides no
control over whether or not floating-point exceptions are trapped or
ignored.  (Ignoring them typically results in NaN values being
propagated in systems that conform to IEEE 754.)  The behaviour is
inherited from the system-dependent startup code.

   Most systems provide some C-callable mechanism to change this; this
can be invoked at startup using `gcc''s `constructor' attribute.  For
example, just compiling and linking the following C code with your
program will turn on exception trapping for the "common" exceptions on
an x86-based GNU system:

     #include <fpu_control.h>
     void __attribute__ ((constructor))
     trapfpe () {
       (void) __setfpucw (_FPU_DEFAULT &
                          ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
     }


File: g77.info,  Node: Nonportable Conversions,  Next: Large Automatic Arrays,  Prev: Floating-point Exception Handling,  Up: Missing Features

Nonportable Conversions
-----------------------

   `g77' doesn't accept some particularly nonportable, silent data-type
conversions such as `LOGICAL' to `REAL' (as in `A=.FALSE.', where `A'
is type `REAL'), that other compilers might quietly accept.

   Some of these conversions are accepted by `g77' when the `-fugly'
option is specified.  Perhaps it should accept more or all of them.


File: g77.info,  Node: Large Automatic Arrays,  Next: Support for Threads,  Prev: Nonportable Conversions,  Up: Missing Features

Large Automatic Arrays
----------------------

   Currently, automatic arrays always are allocated on the stack.  For
situations where the stack cannot be made large enough, `g77' should
offer a compiler option that specifies allocation of automatic arrays
in heap storage.


File: g77.info,  Node: Support for Threads,  Next: Increasing Precision/Range,  Prev: Large Automatic Arrays,  Up: Missing Features

Support for Threads
-------------------

   Neither the code produced by `g77' nor the `libg2c' library are
thread-safe, nor does `g77' have support for parallel processing (other
than the instruction-level parallelism available on some processors).
A package such as PVM might help here.


File: g77.info,  Node: Gracefully Handle Sensible Bad Code,  Next: Non-standard Conversions,  Prev: Increasing Precision/Range,  Up: Missing Features

Gracefully Handle Sensible Bad Code
-----------------------------------

   `g77' generally should continue processing for warnings and
recoverable (user) errors whenever possible--that is, it shouldn't
gratuitously make bad or useless code.

   For example:

     INTRINSIC ZABS
     CALL FOO(ZABS)
     END

When compiling the above with `-ff2c-intrinsics-disable', `g77' should
indeed complain about passing `ZABS', but it still should compile,
instead of rejecting the entire `CALL' statement.  (Some of this is
related to improving the compiler internals to improve how statements
are analyzed.)


File: g77.info,  Node: Non-standard Conversions,  Next: Non-standard Intrinsics,  Prev: Gracefully Handle Sensible Bad Code,  Up: Missing Features

Non-standard Conversions
------------------------

   `-Wconversion' and related should flag places where non-standard
conversions are found.  Perhaps much of this would be part of `-Wugly*'.


File: g77.info,  Node: Non-standard Intrinsics,  Next: Modifying DO Variable,  Prev: Non-standard Conversions,  Up: Missing Features

Non-standard Intrinsics
-----------------------

   `g77' needs a new option, like `-Wintrinsics', to warn about use of
non-standard intrinsics without explicit `INTRINSIC' statements for
them.  This would help find code that might fail silently when ported
to another compiler.


File: g77.info,  Node: Modifying DO Variable,  Next: Better Pedantic Compilation,  Prev: Non-standard Intrinsics,  Up: Missing Features

Modifying `DO' Variable
-----------------------

   `g77' should warn about modifying `DO' variables via `EQUIVALENCE'.
(The internal information gathered to produce this warning might also
be useful in setting the internal "doiter" flag for a variable or even
array reference within a loop, since that might produce faster code
someday.)

   For example, this code is invalid, so `g77' should warn about the
invalid assignment to `NOTHER':

     EQUIVALENCE (I, NOTHER)
     DO I = 1, 100
        IF (I.EQ. 10) NOTHER = 20
     END DO


File: g77.info,  Node: Better Pedantic Compilation,  Next: Warn About Implicit Conversions,  Prev: Modifying DO Variable,  Up: Missing Features

Better Pedantic Compilation
---------------------------

   `g77' needs to support `-fpedantic' more thoroughly, and use it only
to generate warnings instead of rejecting constructs outright.  Have it
warn: if a variable that dimensions an array is not a dummy or placed
explicitly in `COMMON' (F77 does not allow it to be placed in `COMMON'
via `EQUIVALENCE'); if specification statements follow
statement-function-definition statements; about all sorts of syntactic
extensions.


File: g77.info,  Node: Warn About Implicit Conversions,  Next: Invalid Use of Hollerith Constant,  Prev: Better Pedantic Compilation,  Up: Missing Features

Warn About Implicit Conversions
-------------------------------

   `g77' needs a `-Wpromotions' option to warn if source code appears
to expect automatic, silent, and somewhat dangerous compiler-assisted
conversion of `REAL(KIND=1)' constants to `REAL(KIND=2)' based on
context.

   For example, it would warn about cases like this:

     DOUBLE PRECISION FOO
     PARAMETER (TZPHI = 9.435784839284958)
     FOO = TZPHI * 3D0


File: g77.info,  Node: Invalid Use of Hollerith Constant,  Next: Dummy Array Without Dimensioning Dummy,  Prev: Warn About Implicit Conversions,  Up: Missing Features

Invalid Use of Hollerith Constant
---------------------------------

   `g77' should disallow statements like `RETURN 2HAB', which are
invalid in both source forms (unlike `RETURN (2HAB)', which probably
still makes no sense but at least can be reliably parsed).  Fixed-form
processing rejects it, but not free-form, except in a way that is a bit
difficult to understand.


File: g77.info,  Node: Dummy Array Without Dimensioning Dummy,  Next: Invalid FORMAT Specifiers,  Prev: Invalid Use of Hollerith Constant,  Up: Missing Features

Dummy Array Without Dimensioning Dummy
--------------------------------------

   `g77' should complain when a list of dummy arguments containing an
adjustable dummy array does not also contain every variable listed in
the dimension list of the adjustable array.

   Currently, `g77' does complain about a variable that dimensions an
array but doesn't appear in any dummy list or `COMMON' area, but this
needs to be extended to catch cases where it doesn't appear in every
dummy list that also lists any arrays it dimensions.

   For example, `g77' should warn about the entry point `ALT' below,
since it includes `ARRAY' but not `ISIZE' in its list of arguments:

     SUBROUTINE PRIMARY(ARRAY, ISIZE)
     REAL ARRAY(ISIZE)
     ENTRY ALT(ARRAY)


File: g77.info,  Node: Invalid FORMAT Specifiers,  Next: Ambiguous Dialects,  Prev: Dummy Array Without Dimensioning Dummy,  Up: Missing Features

Invalid FORMAT Specifiers
-------------------------

   `g77' should check `FORMAT' specifiers for validity as it does
`FORMAT' statements.

   For example, a diagnostic would be produced for:

     PRINT 'HI THERE!'  !User meant PRINT *, 'HI THERE!'


File: g77.info,  Node: Ambiguous Dialects,  Next: Unused Labels,  Prev: Invalid FORMAT Specifiers,  Up: Missing Features

Ambiguous Dialects
------------------

   `g77' needs a set of options such as `-Wugly*', `-Wautomatic',
`-Wvxt', `-Wf90', and so on.  These would warn about places in the
user's source where ambiguities are found, helpful in resolving
ambiguities in the program's dialect or dialects.


File: g77.info,  Node: Unused Labels,  Next: Informational Messages,  Prev: Ambiguous Dialects,  Up: Missing Features

Unused Labels
-------------

   `g77' should warn about unused labels when `-Wunused' is in effect.


File: g77.info,  Node: Informational Messages,  Next: Uninitialized Variables at Run Time,  Prev: Unused Labels,  Up: Missing Features

Informational Messages
----------------------

   `g77' needs an option to suppress information messages (notes).
`-w' does this but also suppresses warnings.  The default should be to
suppress info messages.

   Perhaps info messages should simply be eliminated.


File: g77.info,  Node: Uninitialized Variables at Run Time,  Next: Bounds Checking at Run Time,  Prev: Informational Messages,  Up: Missing Features

Uninitialized Variables at Run Time
-----------------------------------

   `g77' needs an option to initialize everything (not otherwise
explicitly initialized) to "weird" (machine-dependent) values, e.g.
NaNs, bad (non-`NULL') pointers, and largest-magnitude integers, would
help track down references to some kinds of uninitialized variables at
run time.

   Note that use of the options `-O -Wuninitialized' can catch many
such bugs at compile time.


File: g77.info,  Node: Bounds Checking at Run Time,  Next: Labels Visible to Debugger,  Prev: Uninitialized Variables at Run Time,  Up: Missing Features

Bounds Checking at Run Time
---------------------------

   `g77' should offer run-time bounds-checking of array/subscript
references in a fashion similar to `f2c'.

   Note that `g77' already warns about references to out-of-bounds
elements of arrays when it detects these at compile time.


File: g77.info,  Node: Labels Visible to Debugger,  Prev: Bounds Checking at Run Time,  Up: Missing Features

Labels Visible to Debugger
--------------------------

   `g77' should output debugging information for statements labels, for
use by debuggers that know how to support them.  Same with weirder
things like construct names.  It is not yet known if any debug formats
or debuggers support these.


File: g77.info,  Node: Disappointments,  Next: Non-bugs,  Prev: Missing Features,  Up: Trouble

Disappointments and Misunderstandings
=====================================

   These problems are perhaps regrettable, but we don't know any
practical way around them for now.

* Menu:

* Mangling of Names::                       `SUBROUTINE FOO' is given
                                              external name `foo_'.
* Multiple Definitions of External Names::  No doing both `COMMON /FOO/'
                                              and `SUBROUTINE FOO'.
* Limitation on Implicit Declarations::     No `IMPLICIT CHARACTER*(*)'.


File: g77.info,  Node: Mangling of Names,  Next: Multiple Definitions of External Names,  Up: Disappointments

Mangling of Names in Source Code
--------------------------------

   The current external-interface design, which includes naming of
external procedures, COMMON blocks, and the library interface, has
various usability problems, including things like adding underscores
where not really necessary (and preventing easier inter-language
operability) and yet not providing complete namespace freedom for user
C code linked with Fortran apps (due to the naming of functions in the
library, among other things).

   Project GNU should at least get all this "right" for systems it
fully controls, such as the Hurd, and provide defaults and options for
compatibility with existing systems and interoperability with popular
existing compilers.


File: g77.info,  Node: Multiple Definitions of External Names,  Next: Limitation on Implicit Declarations,  Prev: Mangling of Names,  Up: Disappointments

Multiple Definitions of External Names
--------------------------------------

   `g77' doesn't allow a common block and an external procedure or
`BLOCK DATA' to have the same name.  Some systems allow this, but `g77'
does not, to be compatible with `f2c'.

   `g77' could special-case the way it handles `BLOCK DATA', since it
is not compatible with `f2c' in this particular area (necessarily,
since `g77' offers an important feature here), but it is likely that
such special-casing would be very annoying to people with programs that
use `EXTERNAL FOO', with no other mention of `FOO' in the same program
unit, to refer to external procedures, since the result would be that
`g77' would treat these references as requests to force-load BLOCK DATA
program units.

   In that case, if `g77' modified names of `BLOCK DATA' so they could
have the same names as `COMMON', users would find that their programs
wouldn't link because the `FOO' procedure didn't have its name
translated the same way.

   (Strictly speaking, `g77' could emit a
null-but-externally-satisfying definition of `FOO' with its name
transformed as if it had been a `BLOCK DATA', but that probably invites
more trouble than it's worth.)


File: g77.info,  Node: Limitation on Implicit Declarations,  Prev: Multiple Definitions of External Names,  Up: Disappointments

Limitation on Implicit Declarations
-----------------------------------

   `g77' disallows `IMPLICIT CHARACTER*(*)'.  This is not
standard-conforming.


File: g77.info,  Node: Non-bugs,  Next: Warnings and Errors,  Prev: Disappointments,  Up: Trouble

Certain Changes We Don't Want to Make
=====================================

   This section lists changes that people frequently request, but which
we do not make because we think GNU Fortran is better without them.

* Menu:

* Backslash in Constants::           Why `'\\'' is a constant that
                                       is one, not two, characters long.
* Initializing Before Specifying::   Why `DATA VAR/1/' can't precede
                                       `COMMON VAR'.
* Context-Sensitive Intrinsicness::  Why `CALL SQRT' won't work.
* Context-Sensitive Constants::      Why `9.435784839284958' is a
                                       single-precision constant,
                                       and might be interpreted as
                                       `9.435785' or similar.
* Equivalence Versus Equality::      Why `.TRUE. .EQ. .TRUE.' won't work.
* Order of Side Effects::            Why `J = IFUNC() - IFUNC()' might
                                       not behave as expected.


File: g77.info,  Node: Backslash in Constants,  Next: Initializing Before Specifying,  Up: Non-bugs

Backslash in Constants
----------------------

   In the opinion of many experienced Fortran users, `-fno-backslash'
should be the default, not `-fbackslash', as currently set by `g77'.

   First of all, you can always specify `-fno-backslash' to turn off
this processing.

   Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard, `g77' defaults to
`-fbackslash' because that is what most UNIX `f77' commands default to,
and apparently lots of code depends on this feature.

   This is a particularly troubling issue.  The use of a C construct in
the midst of Fortran code is bad enough, worse when it makes existing
Fortran programs stop working (as happens when programs written for
non-UNIX systems are ported to UNIX systems with compilers that provide
the `-fbackslash' feature as the default--sometimes with no option to
turn it off).

   The author of GNU Fortran wished, for reasons of linguistic purity,
to make `-fno-backslash' the default for GNU Fortran and thus require
users of UNIX `f77' and `f2c' to specify `-fbackslash' to get the UNIX
behavior.

   However, the realization that `g77' is intended as a replacement for
*UNIX* `f77', caused the author to choose to make `g77' as compatible
with `f77' as feasible, which meant making `-fbackslash' the default.

   The primary focus on compatibility is at the source-code level, and
the question became "What will users expect a replacement for `f77' to
do, by default?"  Although at least one UNIX `f77' does not provide
`-fbackslash' as a default, it appears that the majority of them do,
which suggests that the majority of code that is compiled by UNIX `f77'
compilers expects `-fbackslash' to be the default.

   It is probably the case that more code exists that would *not* work
with `-fbackslash' in force than code that requires it be in force.

   However, most of *that* code is not being compiled with `f77', and
when it is, new build procedures (shell scripts, makefiles, and so on)
must be set up anyway so that they work under UNIX.  That makes a much
more natural and safe opportunity for non-UNIX users to adapt their
build procedures for `g77''s default of `-fbackslash' than would exist
for the majority of UNIX `f77' users who would have to modify existing,
working build procedures to explicitly specify `-fbackslash' if that was
not the default.

   One suggestion has been to configure the default for `-fbackslash'
(and perhaps other options as well) based on the configuration of `g77'.

   This is technically quite straightforward, but will be avoided even
in cases where not configuring defaults to be dependent on a particular
configuration greatly inconveniences some users of legacy code.

   Many users appreciate the GNU compilers because they provide an
environment that is uniform across machines.  These users would be
inconvenienced if the compiler treated things like the format of the
source code differently on certain machines.

   Occasionally users write programs intended only for a particular
machine type.  On these occasions, the users would benefit if the GNU
Fortran compiler were to support by default the same dialect as the
other compilers on that machine.  But such applications are rare.  And
users writing a program to run on more than one type of machine cannot
possibly benefit from this kind of compatibility.  (This is consistent
with the design goals for `gcc'.  To change them for `g77', you must
first change them for `gcc'.  Do not ask the maintainers of `g77' to do
this for you, or to disassociate `g77' from the widely understood, if
not widely agreed-upon, goals for GNU compilers in general.)

   This is why GNU Fortran does and will treat backslashes in the same
fashion on all types of machines (by default).  *Note Direction of
Language Development::, for more information on this overall philosophy
guiding the development of the GNU Fortran language.

   Of course, users strongly concerned about portability should indicate
explicitly in their build procedures which options are expected by
their source code, or write source code that has as few such
expectations as possible.

   For example, avoid writing code that depends on backslash (`\')
being interpreted either way in particular, such as by starting a
program unit with:

     CHARACTER BACKSL
     PARAMETER (BACKSL = '\\')

Then, use concatenation of `BACKSL' anyplace a backslash is desired.
In this way, users can write programs which have the same meaning in
many Fortran dialects.

   (However, this technique does not work for Hollerith constants--which
is just as well, since the only generally portable uses for Hollerith
constants are in places where character constants can and should be
used instead, for readability.)


File: g77.info,  Node: Initializing Before Specifying,  Next: Context-Sensitive Intrinsicness,  Prev: Backslash in Constants,  Up: Non-bugs

Initializing Before Specifying
------------------------------

   `g77' does not allow `DATA VAR/1/' to appear in the source code
before `COMMON VAR', `DIMENSION VAR(10)', `INTEGER VAR', and so on.  In
general, `g77' requires initialization of a variable or array to be
specified *after* all other specifications of attributes (type, size,
placement, and so on) of that variable or array are specified (though
*confirmation* of data type is permitted).

   It is *possible* `g77' will someday allow all of this, even though
it is not allowed by the FORTRAN 77 standard.

   Then again, maybe it is better to have `g77' always require
placement of `DATA' so that it can possibly immediately write constants
to the output file, thus saving time and space.

   That is, `DATA A/1000000*1/' should perhaps always be immediately
writable to canonical assembler, unless it's already known to be in a
`COMMON' area following as-yet-uninitialized stuff, and to do this it
cannot be followed by `COMMON A'.


File: g77.info,  Node: Context-Sensitive Intrinsicness,  Next: Context-Sensitive Constants,  Prev: Initializing Before Specifying,  Up: Non-bugs

Context-Sensitive Intrinsicness
-------------------------------

   `g77' treats procedure references to *possible* intrinsic names as
always enabling their intrinsic nature, regardless of whether the
*form* of the reference is valid for that intrinsic.

   For example, `CALL SQRT' is interpreted by `g77' as an invalid
reference to the `SQRT' intrinsic function, because the reference is a
subroutine invocation.

   First, `g77' recognizes the statement `CALL SQRT' as a reference to
a *procedure* named `SQRT', not to a *variable* with that name (as it
would for a statement such as `V = SQRT').

   Next, `g77' establishes that, in the program unit being compiled,
`SQRT' is an intrinsic--not a subroutine that happens to have the same
name as an intrinsic (as would be the case if, for example, `EXTERNAL
SQRT' was present).

   Finally, `g77' recognizes that the *form* of the reference is
invalid for that particular intrinsic.  That is, it recognizes that it
is invalid for an intrinsic *function*, such as `SQRT', to be invoked as
a *subroutine*.

   At that point, `g77' issues a diagnostic.

   Some users claim that it is "obvious" that `CALL SQRT' references an
external subroutine of their own, not an intrinsic function.

   However, `g77' knows about intrinsic subroutines, not just
functions, and is able to support both having the same names, for
example.

   As a result of this, `g77' rejects calls to intrinsics that are not
subroutines, and function invocations of intrinsics that are not
functions, just as it (and most compilers) rejects invocations of
intrinsics with the wrong number (or types) of arguments.

   So, use the `EXTERNAL SQRT' statement in a program unit that calls a
user-written subroutine named `SQRT'.


File: g77.info,  Node: Context-Sensitive Constants,  Next: Equivalence Versus Equality,  Prev: Context-Sensitive Intrinsicness,  Up: Non-bugs

Context-Sensitive Constants
---------------------------

   `g77' does not use context to determine the types of constants or
named constants (`PARAMETER'), except for (non-standard) typeless
constants such as `'123'O'.

   For example, consider the following statement:

     PRINT *, 9.435784839284958 * 2D0

`g77' will interpret the (truncated) constant `9.435784839284958' as a
`REAL(KIND=1)', not `REAL(KIND=2)', constant, because the suffix `D0'
is not specified.

   As a result, the output of the above statement when compiled by
`g77' will appear to have "less precision" than when compiled by other
compilers.

   In these and other cases, some compilers detect the fact that a
single-precision constant is used in a double-precision context and
therefore interpret the single-precision constant as if it was
*explicitly* specified as a double-precision constant.  (This has the
effect of appending *decimal*, not *binary*, zeros to the fractional
part of the number--producing different computational results.)

   The reason this misfeature is dangerous is that a slight, apparently
innocuous change to the source code can change the computational
results.  Consider:

     REAL ALMOST, CLOSE
     DOUBLE PRECISION FIVE
     PARAMETER (ALMOST = 5.000000000001)
     FIVE = 5
     CLOSE = 5.000000000001
     PRINT *, 5.000000000001 - FIVE
     PRINT *, ALMOST - FIVE
     PRINT *, CLOSE - FIVE
     END

Running the above program should result in the same value being printed
three times.  With `g77' as the compiler, it does.

   However, compiled by many other compilers, running the above program
would print two or three distinct values, because in two or three of
the statements, the constant `5.000000000001', which on most systems is
exactly equal to `5.'  when interpreted as a single-precision constant,
is instead interpreted as a double-precision constant, preserving the
represented precision.  However, this "clever" promotion of type does
not extend to variables or, in some compilers, to named constants.

   Since programmers often are encouraged to replace manifest constants
or permanently-assigned variables with named constants (`PARAMETER' in
Fortran), and might need to replace some constants with variables
having the same values for pertinent portions of code, it is important
that compilers treat code so modified in the same way so that the
results of such programs are the same.  `g77' helps in this regard by
treating constants just the same as variables in terms of determining
their types in a context-independent way.

   Still, there is a lot of existing Fortran code that has been written
to depend on the way other compilers freely interpret constants' types
based on context, so anything `g77' can do to help flag cases of this
in such code could be very helpful.


File: g77.info,  Node: Equivalence Versus Equality,  Next: Order of Side Effects,  Prev: Context-Sensitive Constants,  Up: Non-bugs

Equivalence Versus Equality
---------------------------

   Use of `.EQ.' and `.NE.' on `LOGICAL' operands is not supported,
except via `-fugly', which is not recommended except for legacy code
(where the behavior expected by the *code* is assumed).

   Legacy code should be changed, as resources permit, to use `.EQV.'
and `.NEQV.' instead, as these are permitted by the various Fortran
standards.

   New code should never be written expecting `.EQ.' or `.NE.'  to work
if either of its operands is `LOGICAL'.

   The problem with supporting this "feature" is that there is unlikely
to be consensus on how it works, as illustrated by the following sample
program:

     LOGICAL L,M,N
     DATA L,M,N /3*.FALSE./
     IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
     END

   The issue raised by the above sample program is: what is the
precedence of `.EQ.' (and `.NE.') when applied to `LOGICAL' operands?

   Some programmers will argue that it is the same as the precedence
for `.EQ.' when applied to numeric (such as `INTEGER') operands.  By
this interpretation, the subexpression `M.EQ.N' must be evaluated first
in the above program, resulting in a program that, when run, does not
execute the `PRINT' statement.

   Other programmers will argue that the precedence is the same as the
precedence for `.EQV.', which is restricted by the standards to
`LOGICAL' operands.  By this interpretation, the subexpression
`L.AND.M' must be evaluated first, resulting in a program that *does*
execute the `PRINT' statement.

   Assigning arbitrary semantic interpretations to syntactic expressions
that might legitimately have more than one "obvious" interpretation is
generally unwise.

   The creators of the various Fortran standards have done a good job
in this case, requiring a distinct set of operators (which have their
own distinct precedence) to compare `LOGICAL' operands.  This
requirement results in expression syntax with more certain precedence
(without requiring substantial context), making it easier for
programmers to read existing code.  `g77' will avoid muddying up
elements of the Fortran language that were well-designed in the first
place.

   (Ask C programmers about the precedence of expressions such as `(a)
& (b)' and `(a) - (b)'--they cannot even tell you, without knowing more
context, whether the `&' and `-' operators are infix (binary) or unary!)


File: g77.info,  Node: Order of Side Effects,  Prev: Equivalence Versus Equality,  Up: Non-bugs

Order of Side Effects
---------------------

   `g77' does not necessarily produce code that, when run, performs
side effects (such as those performed by function invocations) in the
same order as in some other compiler--or even in the same order as
another version, port, or invocation (using different command-line
options) of `g77'.

   It is never safe to depend on the order of evaluation of side
effects.  For example, an expression like this may very well behave
differently from one compiler to another:

     J = IFUNC() - IFUNC()

There is no guarantee that `IFUNC' will be evaluated in any particular
order.  Either invocation might happen first.  If `IFUNC' returns 5 the
first time it is invoked, and returns 12 the second time, `J' might end
up with the value `7', or it might end up with `-7'.

   Generally, in Fortran, procedures with side-effects intended to be
visible to the caller are best designed as *subroutines*, not functions.
Examples of such side-effects include:

   * The generation of random numbers that are intended to influence
     return values.

   * Performing I/O (other than internal I/O to local variables).

   * Updating information in common blocks.

   An example of a side-effect that is not intended to be visible to
the caller is a function that maintains a cache of recently calculated
results, intended solely to speed repeated invocations of the function
with identical arguments.  Such a function can be safely used in
expressions, because if the compiler optimizes away one or more calls
to the function, operation of the program is unaffected (aside from
being speeded up).


File: g77.info,  Node: Warnings and Errors,  Prev: Non-bugs,  Up: Trouble

Warning Messages and Error Messages
===================================

   The GNU compiler can produce two kinds of diagnostics: errors and
warnings.  Each kind has a different purpose:

     *Errors* report problems that make it impossible to compile your
     program.  GNU Fortran reports errors with the source file name,
     line number, and column within the line where the problem is
     apparent.

     *Warnings* report other unusual conditions in your code that
     *might* indicate a problem, although compilation can (and does)
     proceed.  Warning messages also report the source file name, line
     number, and column information, but include the text `warning:' to
     distinguish them from error messages.

   Warnings might indicate danger points where you should check to make
sure that your program really does what you intend; or the use of
obsolete features; or the use of nonstandard features of GNU Fortran.
Many warnings are issued only if you ask for them, with one of the `-W'
options (for instance, `-Wall' requests a variety of useful warnings).

   *Note:* Currently, the text of the line and a pointer to the column
is printed in most `g77' diagnostics.  Probably, as of version 0.6,
`g77' will no longer print the text of the source line, instead printing
the column number following the file name and line number in a form
that GNU Emacs recognizes.  This change is expected to speed up and
reduce the memory usage of the `g77' compiler.

   *Note Options to Request or Suppress Warnings: Warning Options, for
more detail on these and related command-line options.


File: g77.info,  Node: Open Questions,  Next: Bugs,  Prev: Trouble,  Up: Top

Open Questions
**************

   Please consider offering useful answers to these questions!

   * `LOC()' and other intrinsics are probably somewhat misclassified.
     Is the a need for more precise classification of intrinsics, and
     if so, what are the appropriate groupings?  Is there a need to
     individually enable/disable/delete/hide intrinsics from the
     command line?


File: g77.info,  Node: Bugs,  Next: Service,  Prev: Open Questions,  Up: Top

Reporting Bugs
**************

   Your bug reports play an essential role in making GNU Fortran
reliable.

   When you encounter a problem, the first thing to do is to see if it
is already known.  *Note Trouble::.  If it isn't known, then you should
report the problem.

   Reporting a bug might help you by bringing a solution to your
problem, or it might not.  (If it does not, look in the service
directory; see *Note Service::.)  In any case, the principal function
of a bug report is to help the entire community by making the next
version of GNU Fortran work better.  Bug reports are your contribution
to the maintenance of GNU Fortran.

   Since the maintainers are very overloaded, we cannot respond to every
bug report.  However, if the bug has not been fixed, we are likely to
send you a patch and ask you to tell us whether it works.

   In order for a bug report to serve its purpose, you must include the
information that makes for fixing the bug.

* Menu:

* Criteria: Bug Criteria.    Have you really found a bug?
* Where: Bug Lists.          Where to send your bug report.
* Reporting: Bug Reporting.  How to report a bug effectively.
* Patches: Sending Patches.  How to send a patch for GNU Fortran.

   *Note Known Causes of Trouble with GNU Fortran: Trouble, for
information on problems we already know about.

   *Note How To Get Help with GNU Fortran: Service, for information on
where to ask for help.


File: g77.info,  Node: Bug Criteria,  Next: Bug Lists,  Up: Bugs

Have You Found a Bug?
=====================

   If you are not sure whether you have found a bug, here are some
guidelines:

   * If the compiler gets a fatal signal, for any input whatever, that
     is a compiler bug.  Reliable compilers never crash--they just
     remain obsolete.

   * If the compiler produces invalid assembly code, for any input
     whatever, that is a compiler bug, unless the compiler reports
     errors (not just warnings) which would ordinarily prevent the
     assembler from being run.

   * If the compiler produces valid assembly code that does not
     correctly execute the input source code, that is a compiler bug.

     However, you must double-check to make sure, because you might
     have run into an incompatibility between GNU Fortran and
     traditional Fortran.  These incompatibilities might be considered
     bugs, but they are inescapable consequences of valuable features.

     Or you might have a program whose behavior is undefined, which
     happened by chance to give the desired results with another
     Fortran compiler.  It is best to check the relevant Fortran
     standard thoroughly if it is possible that the program indeed does
     something undefined.

     After you have localized the error to a single source line, it
     should be easy to check for these things.  If your program is
     correct and well defined, you have found a compiler bug.

     It might help if, in your submission, you identified the specific
     language in the relevant Fortran standard that specifies the
     desired behavior, if it isn't likely to be obvious and agreed-upon
     by all Fortran users.

   * If the compiler produces an error message for valid input, that is
     a compiler bug.

   * If the compiler does not produce an error message for invalid
     input, that is a compiler bug.  However, you should note that your
     idea of "invalid input" might be someone else's idea of "an
     extension" or "support for traditional practice".

   * If you are an experienced user of Fortran compilers, your
     suggestions for improvement of GNU Fortran are welcome in any case.

   Many, perhaps most, bug reports against `g77' turn out to be bugs in
the user's code.  While we find such bug reports educational, they
sometimes take a considerable amount of time to track down or at least
respond to--time we could be spending making `g77', not some user's
code, better.

   Some steps you can take to verify that the bug is not certainly in
the code you're compiling with `g77':

   * Compile your code using the `g77' options `-W -Wall -O'.  These
     options enable many useful warning; the `-O' option enables flow
     analysis that enables the uninitialized-variable warning.

     If you investigate the warnings and find evidence of possible bugs
     in your code, fix them first and retry `g77'.

   * Compile your code using the `g77' options `-finit-local-zero',
     `-fno-automatic', `-ffloat-store', and various combinations
     thereof.

     If your code works with any of these combinations, that is not
     proof that the bug isn't in `g77'--a `g77' bug exposed by your
     code might simply be avoided, or have a different, more subtle
     effect, when different options are used--but it can be a strong
     indicator that your code is making unawarranted assumptions about
     the Fortran dialect and/or underlying machine it is being compiled
     and run on.

     *Note Overly Convenient Command-Line Options: Overly Convenient
     Options, for information on the `-fno-automatic' and
     `-finit-local-zero' options and how to convert their use into
     selective changes in your own code.

   * Validate your code with `ftnchek' or a similar code-checking tool.
     `ftncheck' can be found at `ftp://ftp.netlib.org/fortran' or
     `ftp://ftp.dsm.fordham.edu'.

     Here are some sample `Makefile' rules using `ftnchek' "project"
     files to do cross-file checking and `sfmakedepend' (from
     `ftp://ahab.rutgers.edu/pub/perl/sfmakedepend') to maintain
     dependencies automatically.  These assume the use of GNU `make'.

          # Dummy suffix for ftnchek targets:
          .SUFFIXES: .chek
          .PHONY: chekall
          
          # How to compile .f files (for implicit rule):
          FC = g77
          # Assume `include' directory:
          FFLAGS = -Iinclude -g -O -Wall
          
          # Flags for ftnchek:
          CHEK1 = -array=0 -include=includes -noarray
          CHEK2 = -nonovice -usage=1 -notruncation
          CHEKFLAGS = $(CHEK1) $(CHEK2)
          
          # Run ftnchek with all the .prj files except the one corresponding
          # to the target's root:
          %.chek : %.f ; \
            ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
              -noextern -library $<
          
          # Derive a project file from a source file:
          %.prj : %.f ; \
            ftnchek $(CHEKFLAGS) -noextern -project -library $<
          
          # The list of objects is assumed to be in variable OBJS.
          # Sources corresponding to the objects:
          SRCS = $(OBJS:%.o=%.f)
          # ftnchek project files:
          PRJS = $(OBJS:%.o=%.prj)
          
          # Build the program
          prog: $(OBJS) ; \
            $(FC) -o $ $(OBJS)
          
          chekall: $(PRJS) ; \
            ftnchek $(CHEKFLAGS) $(PRJS)
          
          prjs: $(PRJS)
          
          # For Emacs M-x find-tag:
          TAGS: $(SRCS) ; \
            etags $(SRCS)
          
          # Rebuild dependencies:
          depend: ; \
            sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)

   * Try your code out using other Fortran compilers, such as `f2c'.
     If it does not work on at least one other compiler (assuming the
     compiler supports the features the code needs), that is a strong
     indicator of a bug in the code.

     However, even if your code works on many compilers *except* `g77',
     that does *not* mean the bug is in `g77'.  It might mean the bug
     is in your code, and that `g77' simply exposes it more readily
     than other compilers.


File: g77.info,  Node: Bug Lists,  Next: Bug Reporting,  Prev: Bug Criteria,  Up: Bugs

Where to Report Bugs
====================

   Send bug reports for GNU Fortran to <fortran@gnu.org>.

   Often people think of posting bug reports to a newsgroup instead of
mailing them.  This sometimes appears to work, but it has one problem
which can be crucial: a newsgroup posting does not contain a mail path
back to the sender.  Thus, if maintainers need more information, they
might be unable to reach you.  For this reason, you should always send
bug reports by mail to the proper mailing list.

   As a last resort, send bug reports on paper to:

     GNU Compiler Bugs
     Free Software Foundation
     59 Temple Place - Suite 330
     Boston, MA 02111-1307, USA

