This is g77.info, produced by makeinfo version 4.0 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.0 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 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: Intrinsics in PARAMETER Statements,  Next: Arbitrary Concatenation,  Prev: Fortran 90 Support,  Up: Missing Features

Intrinsics in `PARAMETER' Statements
------------------------------------

   `g77' doesn't allow intrinsics in `PARAMETER' statements.  This
feature is considered to be absolutely vital, even though it is not
standard-conforming, and is scheduled for version 0.6.

   Related to this, `g77' doesn't allow non-integral exponentiation in
`PARAMETER' statements, such as `PARAMETER (R=2**.25)'.  It is unlikely
`g77' will ever support this feature, as doing it properly requires
complete emulation of a target computer's floating-point facilities when
building `g77' as a cross-compiler.  But, if the `gcc' back end is
enhanced to provide such a facility, `g77' will likely use that facility
in implementing this feature soon afterwards.


File: g77.info,  Node: Arbitrary Concatenation,  Next: SELECT CASE on CHARACTER Type,  Prev: Intrinsics in PARAMETER Statements,  Up: Missing Features

Arbitrary Concatenation
-----------------------

   `g77' doesn't support arbitrary operands for concatenation in
contexts where run-time allocation is required.  For example:

     SUBROUTINE X(A)
     CHARACTER*(*) A
     CALL FOO(A // 'suffix')


File: g77.info,  Node: SELECT CASE on CHARACTER Type,  Next: RECURSIVE Keyword,  Prev: Arbitrary Concatenation,  Up: Missing Features

`SELECT CASE' on `CHARACTER' Type
---------------------------------

   Character-type selector/cases for `SELECT CASE' currently are not
supported.


File: g77.info,  Node: RECURSIVE Keyword,  Next: Popular Non-standard Types,  Prev: SELECT CASE on CHARACTER Type,  Up: Missing Features

`RECURSIVE' Keyword
-------------------

   `g77' doesn't support the `RECURSIVE' keyword that F90 compilers do.
Nor does it provide any means for compiling procedures designed to do
recursion.

   All recursive code can be rewritten to not use recursion, but the
result is not pretty.


File: g77.info,  Node: Increasing Precision/Range,  Next: Enabling Debug Lines,  Prev: Support for Threads,  Up: Missing Features

Increasing Precision/Range
--------------------------

   Some compilers, such as `f2c', have an option (`-r8', `-qrealsize=8'
or similar) that provides automatic treatment of `REAL' entities such
that they have twice the storage size, and a corresponding increase in
the range and precision, of what would normally be the `REAL(KIND=1)'
(default `REAL') type.  (This affects `COMPLEX' the same way.)

   They also typically offer another option (`-i8') to increase
`INTEGER' entities so they are twice as large (with roughly twice as
much range).

   (There are potential pitfalls in using these options.)

   `g77' does not yet offer any option that performs these kinds of
transformations.  Part of the problem is the lack of detailed
specifications regarding exactly how these options affect the
interpretation of constants, intrinsics, and so on.

   Until `g77' addresses this need, programmers could improve the
portability of their code by modifying it to not require compile-time
options to produce correct results.  Some free tools are available
which may help, specifically in Toolpack (which one would expect to be
sound) and the `fortran' section of the Netlib repository.

   Use of preprocessors can provide a fairly portable means to work
around the lack of widely portable methods in the Fortran language
itself (though increasing acceptance of Fortran 90 would alleviate this
problem).


File: g77.info,  Node: Popular Non-standard Types,  Next: Full Support for Compiler Types,  Prev: RECURSIVE Keyword,  Up: Missing Features

Popular Non-standard Types
--------------------------

   `g77' doesn't fully support `INTEGER*2', `LOGICAL*1', and similar.
Version 0.6 will provide full support for this very popular set of
features.  In the meantime, version 0.5.18 provides rudimentary support
for them.


File: g77.info,  Node: Full Support for Compiler Types,  Next: Array Bounds Expressions,  Prev: Popular Non-standard Types,  Up: Missing Features

Full Support for Compiler Types
-------------------------------

   `g77' doesn't support `INTEGER', `REAL', and `COMPLEX' equivalents
for _all_ applicable back-end-supported types (`char', `short int',
`int', `long int', `long long int', and `long double').  This means
providing intrinsic support, and maybe constant support (using F90
syntax) as well, and, for most machines will result in automatic
support of `INTEGER*1', `INTEGER*2', `INTEGER*8', maybe even `REAL*16',
and so on.  This is scheduled for version 0.6.


File: g77.info,  Node: Array Bounds Expressions,  Next: POINTER Statements,  Prev: Full Support for Compiler Types,  Up: Missing Features

Array Bounds Expressions
------------------------

   `g77' doesn't support more general expressions to dimension arrays,
such as array element references, function references, etc.

   For example, `g77' currently does not accept the following:

     SUBROUTINE X(M, N)
     INTEGER N(10), M(N(2), N(1))


File: g77.info,  Node: POINTER Statements,  Next: Sensible Non-standard Constructs,  Prev: Array Bounds Expressions,  Up: Missing Features

POINTER Statements
------------------

   `g77' doesn't support pointers or allocatable objects (other than
automatic arrays).  This set of features is probably considered just
behind intrinsics in `PARAMETER' statements on the list of large,
important things to add to `g77'.

   In the meantime, consider using the `INTEGER(KIND=7)' declaration to
specify that a variable must be able to hold a pointer.  This construct
is not portable to other non-GNU compilers, but it is portable to all
machines GNU Fortran supports when `g77' is used.

   *Note Functions and Subroutines::, for information on `%VAL()',
`%REF()', and `%DESCR()' constructs, which are useful for passing
pointers to procedures written in languages other than Fortran.


File: g77.info,  Node: Sensible Non-standard Constructs,  Next: READONLY Keyword,  Prev: POINTER Statements,  Up: Missing Features

Sensible Non-standard Constructs
--------------------------------

   `g77' rejects things other compilers accept, like `INTRINSIC
SQRT,SQRT'.  As time permits in the future, some of these things that
are easy for humans to read and write and unlikely to be intended to
mean something else will be accepted by `g77' (though `-fpedantic'
should trigger warnings about such non-standard constructs).

   Until `g77' no longer gratuitously rejects sensible code, you might
as well fix your code to be more standard-conforming and portable.

   The kind of case that is important to except from the recommendation
to change your code is one where following good coding rules would
force you to write non-standard code that nevertheless has a clear
meaning.

   For example, when writing an `INCLUDE' file that defines a common
block, it might be appropriate to include a `SAVE' statement for the
common block (such as `SAVE /CBLOCK/'), so that variables defined in
the common block retain their values even when all procedures declaring
the common block become inactive (return to their callers).

   However, putting `SAVE' statements in an `INCLUDE' file would
prevent otherwise standard-conforming code from also specifying the
`SAVE' statement, by itself, to indicate that all local variables and
arrays are to have the `SAVE' attribute.

   For this reason, `g77' already has been changed to allow this
combination, because although the general problem of gratuitously
rejecting unambiguous and "safe" constructs still exists in `g77', this
particular construct was deemed useful enough that it was worth fixing
`g77' for just this case.

   So, while there is no need to change your code to avoid using this
particular construct, there might be other, equally appropriate but
non-standard constructs, that you shouldn't have to stop using just
because `g77' (or any other compiler) gratuitously rejects it.

   Until the general problem is solved, if you have any such construct
you believe is worthwhile using (e.g. not just an arbitrary, redundant
specification of an attribute), please submit a bug report with an
explanation, so we can consider fixing `g77' just for cases like yours.


File: g77.info,  Node: READONLY Keyword,  Next: FLUSH Statement,  Prev: Sensible Non-standard Constructs,  Up: Missing Features

`READONLY' Keyword
------------------

   Support for `READONLY', in `OPEN' statements, requires `libg2c'
support, to make sure that `CLOSE(...,STATUS='DELETE')' does not delete
a file opened on a unit with the `READONLY' keyword, and perhaps to
trigger a fatal diagnostic if a `WRITE' or `PRINT' to such a unit is
attempted.

   _Note:_ It is not sufficient for `g77' and `libg2c' (its version of
`libf2c') to assume that `READONLY' does not need some kind of explicit
support at run time, due to UNIX systems not (generally) needing it.
`g77' is not just a UNIX-based compiler!

   Further, mounting of non-UNIX filesystems on UNIX systems (such as
via NFS) might require proper `READONLY' support.

   (Similar issues might be involved with supporting the `SHARED'
keyword.)


File: g77.info,  Node: FLUSH Statement,  Next: Expressions in FORMAT Statements,  Prev: READONLY Keyword,  Up: Missing Features

`FLUSH' Statement
-----------------

   `g77' could perhaps use a `FLUSH' statement that does what `CALL
FLUSH' does, but that supports `*' as the unit designator (same unit as
for `PRINT') and accepts `ERR=' and/or `IOSTAT=' specifiers.


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

   `g77' doesn't support `FORM='PRINT'' or an equivalent to translate
the traditional `carriage control' characters in column 1 of output to
use backspaces, carriage returns and the like.  However programs exist
to translate them in output files (or standard output).  These are
typically called either `fpr' or `asa'.  You can get a version of `asa'
from `ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran' for GNU
systems which will probably build easily on other systems.
Alternatively, `fpr' is in BSD distributions in various archive sites.


File: g77.info,  Node: ENCODE and DECODE,  Next: AUTOMATIC Statement,  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: AUTOMATIC Statement,  Next: Suppressing Space Padding,  Prev: ENCODE and DECODE,  Up: Missing Features

`AUTOMATIC' Statement
---------------------

   `g77' doesn't support the `AUTOMATIC' statement that `f2c' does.

   `AUTOMATIC' would identify a variable or array as not being
`SAVE''d, which is normally the default, but which would be especially
useful for code that, _generally_, needed to be compiled with the
`-fno-automatic' option.

   `AUTOMATIC' also would serve as a hint to the compiler that placing
the variable or array--even a very large array-on the stack is
acceptable.

   `AUTOMATIC' would not, by itself, designate the containing procedure
as recursive.

   `AUTOMATIC' should work syntactically like `SAVE', in that
`AUTOMATIC' with no variables listed should apply to all pertinent
variables and arrays (which would not include common blocks or their
members).

   Variables and arrays denoted as `AUTOMATIC' would not be permitted
to be initialized via `DATA' or other specification of any initial
values, requiring explicit initialization, such as via assignment
statements.

   Perhaps `UNSAVE' and `STATIC', as strict semantic opposites to
`SAVE' and `AUTOMATIC', should be provided as well.


File: g77.info,  Node: Suppressing Space Padding,  Next: Fortran Preprocessor,  Prev: AUTOMATIC Statement,  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: Really Ugly Character Assignments,  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: Really Ugly Character Assignments,  Next: POSIX Standard,  Prev: Bit Operations on Floating-point Data,  Up: Missing Features

Really Ugly Character Assignments
---------------------------------

   An option such as `-fugly-char' should be provided to allow

     REAL*8 A1
     DATA A1 / '12345678' /

   and:

     REAL*8 A1
     A1 = 'ABCDEFGH'


File: g77.info,  Node: POSIX Standard,  Next: Floating-point Exception Handling,  Prev: Really Ugly Character Assignments,  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
general 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 normally inherited from the system-dependent startup code, though
some targets, such as the Alpha, have code generation options which
change the behaviour.

   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
a GNU system using glibc 2.2 or newer:

     #define _GNU_SOURCE 1
     #include <fenv.h>
     static void __attribute__ ((constructor))
     trapfpe ()
     {
       /* Enable some exceptions.  At startup all exceptions are masked.  */
     
       feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
     }

   A convenient trick is to compile this something like:
     gcc -o libtrapfpe.a trapfpe.c
   and then use it by adding `-trapfpe' to the `g77' command line when
linking.


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-logint' 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: Enabling Debug Lines,  Next: Better Warnings,  Prev: Increasing Precision/Range,  Up: Missing Features

Enabling Debug Lines
--------------------

   An option such as `-fdebug-lines' should be provided to turn
fixed-form lines beginning with `D' to be treated as if they began with
a space, instead of as if they began with a `C' (as comment lines).


File: g77.info,  Node: Better Warnings,  Next: Gracefully Handle Sensible Bad Code,  Prev: Enabling Debug Lines,  Up: Missing Features

Better Warnings
---------------

   Because of how `g77' generates code via the back end, it doesn't
always provide warnings the user wants.  Consider:

     PROGRAM X
     PRINT *, A
     END

   Currently, the above is not flagged as a case of using an
uninitialized variable, because `g77' generates a run-time library call
that looks, to the GBE, like it might actually _modify_ `A' at run time.
(And, in fact, depending on the previous run-time library call, it
would!)

   Fixing this requires one of the following:

   * Switch to new library, `libg77', that provides a more "clean"
     interface, vis-a-vis input, output, and modified arguments, so the
     GBE can tell what's going on.

     This would provide a pretty big performance improvement, at least
     theoretically, and, ultimately, in practice, for some types of
     code.

   * Have `g77' pass a pointer to a temporary containing a copy of `A',
     instead of to `A' itself.  The GBE would then complain about the
     copy operation involving a potentially uninitialized variable.

     This might also provide a performance boost for some code, because
     `A' might then end up living in a register, which could help with
     inner loops.

   * Have `g77' use a GBE construct similar to `ADDR_EXPR' but with
     extra information on the fact that the item pointed to won't be
     modified (a la `const' in C).

     Probably the best solution for now, but not quite trivial to
     implement in the general case.  Worth considering after `g77' 0.6
     is considered pretty solid.


File: g77.info,  Node: Gracefully Handle Sensible Bad Code,  Next: Non-standard Conversions,  Prev: Better Warnings,  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: Portable Unformatted Files,  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: Portable Unformatted Files,  Next: Better List-directed I/O,  Prev: Uninitialized Variables at Run Time,  Up: Missing Features

Portable Unformatted Files
--------------------------

   `g77' has no facility for exchanging unformatted files with systems
using different number formats--even differing only in endianness (byte
order)--or written by other compilers.  Some compilers provide
facilities at least for doing byte-swapping during unformatted I/O.

   It is unrealistic to expect to cope with exchanging unformatted files
with arbitrary other compiler runtimes, but the `g77' runtime should at
least be able to read files written by `g77' on systems with different
number formats, particularly if they differ only in byte order.

   In case you do need to write a program to translate to or from `g77'
(`libf2c') unformatted files, they are written as follows:
Sequential
     Unformatted sequential records consist of
       1. A number giving the length of the record contents;

       2. the length of record contents again (for backspace).

     The record length is of C type `long'; this means that it is 8
     bytes on 64-bit systems such as Alpha GNU/Linux and 4 bytes on
     other systems, such as x86 GNU/Linux.  Consequently such files
     cannot be exchanged between 64-bit and 32-bit systems, even with
     the same basic number format.

Direct access
     Unformatted direct access files form a byte stream of length
     RECORDS*RECL bytes, where RECORDS is the maximum record number
     (`REC=RECORDS') written and RECL is the record length in bytes
     specified in the `OPEN' statement (`RECL=RECL').  Data appear in
     the records as determined by the relevant `WRITE' statement.
     Dummy records with arbitrary contents appear in the file in place
     of records which haven't been written.

   Thus for exchanging a sequential or direct access unformatted file
between big- and little-endian 32-bit systems using IEEE 754 floating
point it would be sufficient to reverse the bytes in consecutive words
in the file if, and _only_ if, only `REAL*4', `COMPLEX', `INTEGER*4'
and/or `LOGICAL*4' data have been written to it by `g77'.

   If necessary, it is possible to do byte-oriented i/o with `g77''s
`FGETC' and `FPUTC' intrinsics.  Byte-swapping can be done in Fortran
by equivalencing larger sized variables to an `INTEGER*1' array or a
set of scalars.

   If you need to exchange binary data between arbitrary system and
compiler variations, we recommend using a portable binary format with
Fortran bindings, such as NCSA's HDF (`http://hdf.ncsa.uiuc.edu/') or
PACT's PDB(1) (`http://www.llnl.gov/def_sci/pact/pact_homepage.html').
(Unlike, say, CDF or XDR, HDF-like systems write in the native number
formats and only incur overhead when they are read on a system with a
different format.)  A future `g77' runtime library should use such
techniques.

   ---------- Footnotes ----------

   (1) No, not _that_ one.


File: g77.info,  Node: Better List-directed I/O,  Next: Default to Console I/O,  Prev: Portable Unformatted Files,  Up: Missing Features

Better List-directed I/O
------------------------

   Values output using list-directed I/O (`PRINT *, R, D') should be
written with a field width, precision, and so on appropriate for the
type (precision) of each value.

   (Currently, no distinction is made between single-precision and
double-precision values by `libf2c'.)

   It is likely this item will require the `libg77' project to be
undertaken.

   In the meantime, use of formatted I/O is recommended.  While it
might be of little consolation, `g77' does support
`FORMAT(F<WIDTH>.4)', for example, as long as `WIDTH' is defined as a
named constant (via `PARAMETER').  That at least allows some
compile-time specification of the precision of a data type, perhaps
controlled by preprocessing directives.


File: g77.info,  Node: Default to Console I/O,  Next: Labels Visible to Debugger,  Prev: Better List-directed I/O,  Up: Missing Features

Default to Console I/O
----------------------

   The default I/O units, specified by `READ FMT', `READ (UNIT=*)',
`WRITE (UNIT=*)', and `PRINT FMT', should not be units 5 (input) and 6
(output), but, rather, unit numbers not normally available for use in
statements such as `OPEN' and `CLOSE'.

   Changing this would allow a program to connect units 5 and 6 to
files via `OPEN', but still use `READ (UNIT=*)' and `PRINT' to do I/O
to the "console".

   This change probably requires the `libg77' project.


File: g77.info,  Node: Labels Visible to Debugger,  Prev: Default to Console I/O,  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'.

