PR libstdc++/3584

[official-gcc.git] / gcc / f / g77.texi

\input texinfo  @c -*-texinfo-*-
@c %**start of header
@setfilename g77.info

@set last-update 2002-04-29
@set copyrights-g77 1995,1996,1997,1998,1999,2000,2001,2002

@include root.texi

@c This tells @include'd files that they're part of the overall G77 doc
@c set.  (They might be part of a higher-level doc set too.)
@set DOC-G77

@c @setfilename useg77.info
@c @setfilename portg77.info
@c To produce the full manual, use the "g77.info" setfilename, and
@c make sure the following do NOT begin with '@c' (and the @clear lines DO)
@set INTERNALS
@set USING
@c To produce a user-only manual, use the "useg77.info" setfilename, and
@c make sure the following does NOT begin with '@c':
@c @clear INTERNALS
@c To produce a porter-only manual, use the "portg77.info" setfilename,
@c and make sure the following does NOT begin with '@c':
@c @clear USING

@c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi)
@c @smallbook

@c i also commented out the finalout command, so if there *are* any
@c overfulls, you'll (hopefully) see the rectangle in the right hand
@c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi).
@c @finalout

@macro gcctabopt{body}
@code{\body\}
@end macro
@macro gccoptlist{body}
@smallexample
\body\
@end smallexample
@end macro
@c Makeinfo handles the above macro OK, TeX needs manual line breaks;
@c they get lost at some point in handling the macro.  But if @macro is
@c used here rather than @alias, it produces double line breaks.
@iftex
@alias gol = *
@end iftex
@ifnottex
@macro gol
@end macro
@end ifnottex

@ifset INTERNALS
@ifset USING
@settitle Using and Porting GNU Fortran
@end ifset
@end ifset
@c seems reasonable to assume at least one of INTERNALS or USING is set...
@ifclear INTERNALS
@settitle Using GNU Fortran
@end ifclear
@ifclear USING
@settitle Porting GNU Fortran
@end ifclear
@c then again, have some fun
@ifclear INTERNALS
@ifclear USING
@settitle Doing Squat with GNU Fortran
@end ifclear
@end ifclear

@syncodeindex fn cp
@syncodeindex vr cp
@c %**end of header

@c Cause even numbered pages to be printed on the left hand side of
@c the page and odd numbered pages to be printed on the right hand
@c side of the page.  Using this, you can print on both sides of a
@c sheet of paper and have the text on the same part of the sheet.

@c The text on right hand pages is pushed towards the right hand
@c margin and the text on left hand pages is pushed toward the left
@c hand margin.
@c (To provide the reverse effect, set bindingoffset to -0.75in.)

@c @tex
@c \global\bindingoffset=0.75in
@c \global\normaloffset =0.75in
@c @end tex

@ifinfo
@dircategory Programming
@direntry
* g77: (g77).                  The GNU Fortran compiler.
@end direntry
@ifset INTERNALS
@ifset USING
This file documents the use and the internals of the GNU Fortran (@command{g77})
compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifset
@end ifset
@ifclear USING
This file documents the internals of the GNU Fortran (@command{g77}) compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear
@ifclear INTERNALS
This file documents the use of the GNU Fortran (@command{g77}) compiler.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear

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

Copyright (C) @value{copyrights-g77} 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.
@end ifinfo

Contributed by James Craig Burley (@email{@value{email-burley}}).
Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).

@setchapternewpage odd
@c @finalout
@titlepage
@ifset INTERNALS
@ifset USING
@center @titlefont{Using and Porting GNU Fortran}

@end ifset
@end ifset
@ifclear INTERNALS
@title Using GNU Fortran
@end ifclear
@ifclear USING
@title Porting GNU Fortran
@end ifclear
@sp 2
@center James Craig Burley
@sp 3
@center Last updated @value{last-update}
@sp 1
@center for version @value{which-g77}
@page
@vskip 0pt plus 1filll
Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.
@sp 2
For the @value{which-g77} Version*
@sp 1
Published by the Free Software Foundation @*
59 Temple Place - Suite 330@*
Boston, MA 02111-1307, USA@*
@c Last printed ??ber, 19??.@*
@c Printed copies are available for $? each.@*
@c ISBN ???
@sp 1
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.
@end titlepage
@summarycontents
@contents
@page

@node Top, Copying,, (DIR)
@top Introduction
@cindex Introduction

@ifset INTERNALS
@ifset USING
This manual documents how to run, install and port @command{g77},
as well as its new features and incompatibilities,
and how to report bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifset
@end ifset

@ifclear INTERNALS
This manual documents how to run and install @command{g77},
as well as its new features and incompatibilities, and how to report
bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear
@ifclear USING
This manual documents how to port @command{g77},
as well as its new features and incompatibilities,
and how to report bugs.
It corresponds to the @value{which-g77} version of @command{g77}.
@end ifclear

@ifset DEVELOPMENT
@emph{Warning:} This document is still under development,
and might not accurately reflect the @command{g77} code base
of which it is a part.
Efforts are made to keep it somewhat up-to-date,
but they are particularly concentrated
on any version of this information
that is distributed as part of a @emph{released} @command{g77}.

In particular, while this document is intended to apply to
the @value{which-g77} version of @command{g77},
only an official @emph{release} of that version
is expected to contain documentation that is
most consistent with the @command{g77} product in that version.
@end ifset

@menu
* Copying::         GNU General Public License says
                    how you can copy and share GNU Fortran.
* GNU Free Documentation License::
                    How you can copy and share this manual.
* Contributors::    People who have contributed to GNU Fortran.
* Funding::         How to help assure continued work for free software.
* Funding GNU Fortran::  How to help assure continued work on GNU Fortran.
@ifset USING
* Getting Started:: Finding your way around this manual.
* What is GNU Fortran?::  How @command{g77} fits into the universe.
* G77 and GCC::     You can compile Fortran, C, or other programs.
* Invoking G77::    Command options supported by @command{g77}.
* News::            News about recent releases of @command{g77}.
* Changes::         User-visible changes to recent releases of @command{g77}.
* Language::        The GNU Fortran language.
* Compiler::        The GNU Fortran compiler.
* Other Dialects::  Dialects of Fortran supported by @command{g77}.
* Other Compilers:: Fortran compilers other than @command{g77}.
* Other Languages:: Languages other than Fortran.
* Debugging and Interfacing::  How @command{g77} generates code.
* Collected Fortran Wisdom::  How to avoid Trouble.
* Trouble::         If you have trouble with GNU Fortran.
* Open Questions::  Things we'd like to know.
* Bugs::            How, why, and where to report bugs.
* Service::         How to find suppliers of support for GNU Fortran.
@end ifset
@ifset INTERNALS
* Adding Options::  Guidance on teaching @command{g77} about new options.
* Projects::        Projects for @command{g77} internals hackers.
* Front End::       Design and implementation of the @command{g77} front end.
@end ifset

* M: Diagnostics.   Diagnostics produced by @command{g77}.

* Keyword Index::   Index of concepts and symbol names.
@end menu
@c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!

@include gpl.texi

@include fdl.texi

@node Contributors
@unnumbered Contributors to GNU Fortran
@cindex contributors
@cindex credits

In addition to James Craig Burley, who wrote the front end,
many people have helped create and improve GNU Fortran.

@itemize @bullet
@item
The packaging and compiler portions of GNU Fortran are based largely
on the GNU CC compiler.
@xref{Contributors,,Contributors to GCC,gcc,Using the GNU Compiler
Collection (GCC)},
for more information.

@item
The run-time library used by GNU Fortran is a repackaged version
of the @code{libf2c} library (combined from the @code{libF77} and
@code{libI77} libraries) provided as part of @command{f2c}, available for
free from @code{netlib} sites on the Internet.

@item
Cygnus Support and The Free Software Foundation contributed
significant money and/or equipment to Craig's efforts.

@item
The following individuals served as alpha testers prior to @command{g77}'s
public release.  This work consisted of testing, researching, sometimes
debugging, and occasionally providing small amounts of code and fixes
for @command{g77}, plus offering plenty of helpful advice to Craig:

@itemize @w{}
@item
Jonathan Corbet
@item
Dr.@: Mark Fernyhough
@item
Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
@item
Kate Hedstrom
@item
Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
@item
Dr.@: A. O. V. Le Blanc
@item
Dave Love
@item
Rick Lutowski
@item
Toon Moene
@item
Rick Niles
@item
Derk Reefman
@item
Wayne K. Schroll
@item
Bill Thorson
@item
Pedro A. M. Vazquez
@item
Ian Watson
@end itemize

@item
Dave Love (@email{d.love@@dl.ac.uk})
wrote the libU77 part of the run-time library.

@item
Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
provided the patch to add rudimentary support
for @code{INTEGER*1}, @code{INTEGER*2}, and
@code{LOGICAL*1}.
This inspired Craig to add further support,
even though the resulting support
would still be incomplete.

@item
David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
and encouraged Craig to rewrite the documentation in texinfo
format by contributing a first pass at a translation of the
old @file{g77-0.5.16/f/DOC} file.

@item
Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
some analysis of generated code as part of an overall project
to improve @command{g77} code generation to at least be as good
as @command{f2c} used in conjunction with @command{gcc}.
So far, this has resulted in the three, somewhat
experimental, options added by @command{g77} to the @command{gcc}
compiler and its back end.

(These, in turn, had made their way into the @code{egcs}
version of the compiler, and do not exist in @command{gcc}
version 2.8 or versions of @command{g77} based on that version
of @command{gcc}.)

@item
John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.

@item
Thanks to Mary Cortani and the staff at Craftwork Solutions
(@email{support@@craftwork.com}) for all of their support.

@item
Many other individuals have helped debug, test, and improve @command{g77}
over the past several years, and undoubtedly more people
will be doing so in the future.
If you have done so, and would like
to see your name listed in the above list, please ask!
The default is that people wish to remain anonymous.
@end itemize

@include funding.texi

@node Funding GNU Fortran
@chapter Funding GNU Fortran
@cindex funding improvements
@cindex improvements, funding

James Craig Burley (@email{@value{email-burley}}), the original author
of @command{g77}, stopped working on it in September 1999
(He has a web page at @uref{@value{www-burley}}.)

GNU Fortran is currently maintained by Toon Moene
(@email{toon@@moene.indiv.nluug.nl}), with the help of countless other
volunteers.

As with other GNU software, funding is important because it can pay for
needed equipment, personnel, and so on.

@cindex FSF, funding the
@cindex funding the FSF
The FSF provides information on the best way to fund ongoing
development of GNU software (such as GNU Fortran) in documents
such as the ``GNUS Bulletin''.
Email @email{gnu@@gnu.org} for information on funding the FSF.

Another important way to support work on GNU Fortran is to volunteer
to help out.

Email @email{@value{email-general}} to volunteer for this work.

However, we strongly expect that there will never be a version 0.6
of @command{g77}.  Work on this compiler has stopped as of the release
of GCC 3.1, except for bug fixing.  @command{g77} will be succeeded by
@command{g95} - see @uref{http://g95.sourceforge.net}.

@xref{Funding,,Funding Free Software}, for more information.

@node Getting Started
@chapter Getting Started
@cindex getting started
@cindex new users
@cindex newbies
@cindex beginners

If you don't need help getting started reading the portions
of this manual that are most important to you, you should skip
this portion of the manual.

If you are new to compilers, especially Fortran compilers, or
new to how compilers are structured under UNIX and UNIX-like
systems, you'll want to see @ref{What is GNU Fortran?}.

If you are new to GNU compilers, or have used only one GNU
compiler in the past and not had to delve into how it lets
you manage various versions and configurations of @command{gcc},
you should see @ref{G77 and GCC}.

Everyone except experienced @command{g77} users should
see @ref{Invoking G77}.

If you're acquainted with previous versions of @command{g77},
you should see @ref{News,,News About GNU Fortran}.
Further, if you've actually used previous versions of @command{g77},
especially if you've written or modified Fortran code to
be compiled by previous versions of @command{g77}, you
should see @ref{Changes}.

If you intend to write or otherwise compile code that is
not already strictly conforming ANSI FORTRAN 77---and this
is probably everyone---you should see @ref{Language}.

If you run into trouble getting Fortran code to compile,
link, run, or work properly, you might find answers
if you see @ref{Debugging and Interfacing},
see @ref{Collected Fortran Wisdom},
and see @ref{Trouble}.
You might also find that the problems you are encountering
are bugs in @command{g77}---see @ref{Bugs}, for information on
reporting them, after reading the other material.

If you need further help with @command{g77}, or with
freely redistributable software in general,
see @ref{Service}.

If you would like to help the @command{g77} project,
see @ref{Funding GNU Fortran}, for information on
helping financially, and see @ref{Projects}, for information
on helping in other ways.

If you're generally curious about the future of
@command{g77}, see @ref{Projects}.
If you're curious about its past,
see @ref{Contributors},
and see @ref{Funding GNU Fortran}.

To see a few of the questions maintainers of @command{g77} have,
and that you might be able to answer,
see @ref{Open Questions}.

@ifset USING
@node What is GNU Fortran?
@chapter What is GNU Fortran?
@cindex concepts, basic
@cindex basic concepts

GNU Fortran, or @command{g77}, is designed initially as a free replacement
for, or alternative to, the UNIX @command{f77} command.
(Similarly, @command{gcc} is designed as a replacement
for the UNIX @command{cc} command.)

@command{g77} also is designed to fit in well with the other
fine GNU compilers and tools.

Sometimes these design goals conflict---in such cases, resolution
often is made in favor of fitting in well with Project GNU.
These cases are usually identified in the appropriate
sections of this manual.

@cindex compilers
As compilers, @command{g77}, @command{gcc}, and @command{f77}
share the following characteristics:

@itemize @bullet
@cindex source code
@cindex file, source
@cindex code, source
@cindex source file
@item
They read a user's program, stored in a file and
containing instructions written in the appropriate
language (Fortran, C, and so on).
This file contains @dfn{source code}.

@cindex translation of user programs
@cindex machine code
@cindex code, machine
@cindex mistakes
@item
They translate the user's program into instructions
a computer can carry out more quickly than it takes
to translate the instructions in the first place.
These instructions are called @dfn{machine code}---code
designed to be efficiently translated and processed
by a machine such as a computer.
Humans usually aren't as good writing machine code
as they are at writing Fortran or C, because
it is easy to make tiny mistakes writing machine code.
When writing Fortran or C, it is easy
to make big mistakes.

@cindex debugger
@cindex bugs, finding
@cindex @command{gdb}, command
@cindex commands, @command{gdb}
@item
They provide information in the generated machine code
that can make it easier to find bugs in the program
(using a debugging tool, called a @dfn{debugger},
such as @command{gdb}).

@cindex libraries
@cindex linking
@cindex @command{ld} command
@cindex commands, @command{ld}
@item
They locate and gather machine code already generated
to perform actions requested by statements in
the user's program.
This machine code is organized
into @dfn{libraries} and is located and gathered
during the @dfn{link} phase of the compilation
process.
(Linking often is thought of as a separate
step, because it can be directly invoked via the
@command{ld} command.
However, the @command{g77} and @command{gcc}
commands, as with most compiler commands, automatically
perform the linking step by calling on @command{ld}
directly, unless asked to not do so by the user.)

@cindex language, incorrect use of
@cindex incorrect use of language
@item
They attempt to diagnose cases where the user's
program contains incorrect usages of the language.
The @dfn{diagnostics} produced by the compiler
indicate the problem and the location in the user's
source file where the problem was first noticed.
The user can use this information to locate and
fix the problem.
@cindex diagnostics, incorrect
@cindex incorrect diagnostics
@cindex error messages, incorrect
@cindex incorrect error messages
(Sometimes an incorrect usage
of the language leads to a situation where the
compiler can no longer make any sense of what
follows---while a human might be able to---and
thus ends up complaining about many ``problems''
it encounters that, in fact, stem from just one
problem, usually the first one reported.)

@cindex warnings
@cindex questionable instructions
@item
They attempt to diagnose cases where the user's
program contains a correct usage of the language,
but instructs the computer to do something questionable.
These diagnostics often are in the form of @dfn{warnings},
instead of the @dfn{errors} that indicate incorrect
usage of the language.
@end itemize

How these actions are performed is generally under the
control of the user.
Using command-line options, the user can specify
how persnickety the compiler is to be regarding
the program (whether to diagnose questionable usage
of the language), how much time to spend making
the generated machine code run faster, and so on.

@cindex components of @command{g77}
@cindex @command{g77}, components of
@command{g77} consists of several components:

@cindex @command{gcc}, command
@cindex commands, @command{gcc}
@itemize @bullet
@item
A modified version of the @command{gcc} command, which also might be
installed as the system's @command{cc} command.
(In many cases, @command{cc} refers to the
system's ``native'' C compiler, which
might be a non-GNU compiler, or an older version
of @command{gcc} considered more stable or that is
used to build the operating system kernel.)

@cindex @command{g77}, command
@cindex commands, @command{g77}
@item
The @command{g77} command itself, which also might be installed as the
system's @command{f77} command.

@cindex libg2c library
@cindex libf2c library
@cindex libraries, libf2c
@cindex libraries, libg2c
@cindex run-time, library
@item
The @code{libg2c} run-time library.
This library contains the machine code needed to support
capabilities of the Fortran language that are not directly
provided by the machine code generated by the @command{g77}
compilation phase.

@code{libg2c} is just the unique name @command{g77} gives
to its version of @code{libf2c} to distinguish it from
any copy of @code{libf2c} installed from @command{f2c}
(or versions of @command{g77} that built @code{libf2c} under
that same name)
on the system.

The maintainer of @code{libf2c} currently is
@email{dmg@@bell-labs.com}.

@cindex @code{f771}, program
@cindex programs, @code{f771}
@cindex assembler
@cindex @command{as} command
@cindex commands, @command{as}
@cindex assembly code
@cindex code, assembly
@item
The compiler itself, internally named @code{f771}.

Note that @code{f771} does not generate machine code directly---it
generates @dfn{assembly code} that is a more readable form
of machine code, leaving the conversion to actual machine code
to an @dfn{assembler}, usually named @command{as}.
@end itemize

@command{gcc} is often thought of as ``the C compiler'' only,
but it does more than that.
Based on command-line options and the names given for files
on the command line, @command{gcc} determines which actions to perform, including
preprocessing, compiling (in a variety of possible languages), assembling,
and linking.

@cindex driver, gcc command as
@cindex @command{gcc}, command as driver
@cindex executable file
@cindex files, executable
@cindex cc1 program
@cindex programs, cc1
@cindex preprocessor
@cindex cpp program
@cindex programs, cpp
For example, the command @samp{gcc foo.c} @dfn{drives} the file
@file{foo.c} through the preprocessor @command{cpp}, then
the C compiler (internally named
@code{cc1}), then the assembler (usually @command{as}), then the linker
(@command{ld}), producing an executable program named @file{a.out} (on
UNIX systems).

@cindex cc1plus program
@cindex programs, cc1plus
As another example, the command @samp{gcc foo.cc} would do much the same as
@samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
@command{gcc} would use the C++ compiler (named @code{cc1plus}).

@cindex @code{f771}, program
@cindex programs, @code{f771}
In a GNU Fortran installation, @command{gcc} recognizes Fortran source
files by name just like it does C and C++ source files.
It knows to use the Fortran compiler named @code{f771}, instead of
@code{cc1} or @code{cc1plus}, to compile Fortran files.

@cindex @command{gcc}, not recognizing Fortran source
@cindex unrecognized file format
@cindex file format not recognized
Non-Fortran-related operation of @command{gcc} is generally
unaffected by installing the GNU Fortran version of @command{gcc}.
However, without the installed version of @command{gcc} being the
GNU Fortran version, @command{gcc} will not be able to compile
and link Fortran programs---and since @command{g77} uses @command{gcc}
to do most of the actual work, neither will @command{g77}!

@cindex @command{g77}, command
@cindex commands, @command{g77}
The @command{g77} command is essentially just a front-end for
the @command{gcc} command.
Fortran users will normally use @command{g77} instead of @command{gcc},
because @command{g77}
knows how to specify the libraries needed to link with Fortran programs
(@code{libg2c} and @code{lm}).
@command{g77} can still compile and link programs and
source files written in other languages, just like @command{gcc}.

@cindex printing version information
@cindex version information, printing
The command @samp{g77 -v} is a quick
way to display lots of version information for the various programs
used to compile a typical preprocessed Fortran source file---this
produces much more output than @samp{gcc -v} currently does.
(If it produces an error message near the end of the output---diagnostics
from the linker, usually @command{ld}---you might
have an out-of-date @code{libf2c} that improperly handles
complex arithmetic.)
In the output of this command, the line beginning @samp{GNU Fortran Front
End} identifies the version number of GNU Fortran; immediately
preceding that line is a line identifying the version of @command{gcc}
with which that version of @command{g77} was built.

@cindex libf2c library
@cindex libraries, libf2c
The @code{libf2c} library is distributed with GNU Fortran for
the convenience of its users, but is not part of GNU Fortran.
It contains the procedures
needed by Fortran programs while they are running.

@cindex in-line code
@cindex code, in-line
For example, while code generated by @command{g77} is likely
to do additions, subtractions, and multiplications @dfn{in line}---in
the actual compiled code---it is not likely to do trigonometric
functions this way.

Instead, operations like trigonometric
functions are compiled by the @code{f771} compiler
(invoked by @command{g77} when compiling Fortran code) into machine
code that, when run, calls on functions in @code{libg2c}, so
@code{libg2c} must be linked with almost every useful program
having any component compiled by GNU Fortran.
(As mentioned above, the @command{g77} command takes
care of all this for you.)

The @code{f771} program represents most of what is unique to GNU Fortran.
While much of the @code{libg2c} component comes from
the @code{libf2c} component of @command{f2c},
a free Fortran-to-C converter distributed by Bellcore (AT&T),
plus @code{libU77}, provided by Dave Love,
and the @command{g77} command is just a small front-end to @command{gcc},
@code{f771} is a combination of two rather
large chunks of code.

@cindex GNU Back End (GBE)
@cindex GBE
@cindex @command{gcc}, back end
@cindex back end, gcc
@cindex code generator
One chunk is the so-called @dfn{GNU Back End}, or GBE,
which knows how to generate fast code for a wide variety of processors.
The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
@code{cc1plus}, and @code{f771}, plus others.
Often the GBE is referred to as the ``gcc back end'' or
even just ``gcc''---in this manual, the term GBE is used
whenever the distinction is important.

@cindex GNU Fortran Front End (FFE)
@cindex FFE
@cindex @command{g77}, front end
@cindex front end, @command{g77}
The other chunk of @code{f771} is the
majority of what is unique about GNU Fortran---the code that knows how
to interpret Fortran programs to determine what they are intending to
do, and then communicate that knowledge to the GBE for actual compilation
of those programs.
This chunk is called the @dfn{Fortran Front End} (FFE).
The @code{cc1} and @code{cc1plus} programs have their own front ends,
for the C and C++ languages, respectively.
These fronts ends are responsible for diagnosing
incorrect usage of their respective languages by the
programs the process, and are responsible for most of
the warnings about questionable constructs as well.
(The GBE handles producing some warnings, like those
concerning possible references to undefined variables.)

Because so much is shared among the compilers for various languages,
much of the behavior and many of the user-selectable options for these
compilers are similar.
For example, diagnostics (error messages and
warnings) are similar in appearance; command-line
options like @option{-Wall} have generally similar effects; and the quality
of generated code (in terms of speed and size) is roughly similar
(since that work is done by the shared GBE).

@node G77 and GCC
@chapter Compile Fortran, C, or Other Programs
@cindex compiling programs
@cindex programs, compiling

@cindex @command{gcc}, command
@cindex commands, @command{gcc}
A GNU Fortran installation includes a modified version of the @command{gcc}
command.

In a non-Fortran installation, @command{gcc} recognizes C, C++,
and Objective-C source files.

In a GNU Fortran installation, @command{gcc} also recognizes Fortran source
files and accepts Fortran-specific command-line options, plus some
command-line options that are designed to cater to Fortran users
but apply to other languages as well.

@xref{G++ and GCC,,Compile C; C++; Objective-C; Ada; Fortran;
or Java,gcc,Using the GNU Compiler Collection (GCC)},
for information on the way different languages are handled
by the GNU CC compiler (@command{gcc}).

@cindex @command{g77}, command
@cindex commands, @command{g77}
Also provided as part of GNU Fortran is the @command{g77} command.
The @command{g77} command is designed to make compiling and linking Fortran
programs somewhat easier than when using the @command{gcc} command for
these tasks.
It does this by analyzing the command line somewhat and changing it
appropriately before submitting it to the @command{gcc} command.

@cindex -v option
@cindex @command{g77} options, -v
@cindex options, -v
Use the @option{-v} option with @command{g77}
to see what is going on---the first line of output is the invocation
of the @command{gcc} command.

@include invoke.texi

@include news.texi

@set USERVISONLY
@include news.texi
@clear USERVISONLY

@node Language
@chapter The GNU Fortran Language

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

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

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

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

@xref{Other Dialects}, for information on features @command{g77} supports
that are not part of the GNU Fortran language.

@emph{Note}: This portion of the documentation definitely needs a lot
of work!

@menu
Relationship to the ANSI FORTRAN 77 standard:
* Direction of Language Development::  Where GNU Fortran is headed.
* Standard Support::  Degree of support for the standard.

Extensions to the ANSI FORTRAN 77 standard:
* Conformance::
* Notation Used::
* Terms and Concepts::
* Characters Lines Sequence::
* Data Types and Constants::
* Expressions::
* Specification Statements::
* Control Statements::
* Functions and Subroutines::
* Scope and Classes of Names::
* I/O::
* Fortran 90 Features::
@end menu

@node Direction of Language Development
@section Direction of Language Development
@cindex direction of language development
@cindex features, language
@cindex language, features

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

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

The GNU Fortran @emph{language} is distinct from the
GNU Fortran @emph{compilation system} (@command{g77}).

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

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

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

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

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

@itemize @bullet
@item
Serving as a mostly-upwards-compatible language from the
de facto UNIX Fortran dialect as supported by @command{f77}.

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

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

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

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

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

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

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

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

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

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

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

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

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

@node Standard Support
@section ANSI FORTRAN 77 Standard Support
@cindex ANSI FORTRAN 77 support
@cindex standard, support for
@cindex support, FORTRAN 77
@cindex compatibility, FORTRAN 77
@cindex FORTRAN 77 compatibility

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

@menu
* No Passing External Assumed-length::  CHAR*(*) CFUNC restriction.
* No Passing Dummy Assumed-length::     CHAR*(*) CFUNC restriction.
* No Pathological Implied-DO::          No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
* No Useless Implied-DO::               No @samp{(A, I=1, 1)}.
@end menu

@node No Passing External Assumed-length
@subsection No Passing External Assumed-length

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

@example
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
@end example

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

@node No Passing Dummy Assumed-length
@subsection No Passing Dummy Assumed-length

@command{g77} disallows passing of a dummy procedure
as an actual argument if the procedure's
type is declared @code{CHARACTER*(*)}.

@example
SUBROUTINE BAR(CFUNC)
CHARACTER*(*) CFUNC
EXTERNAL CFUNC
CALL FOO(CFUNC)
END
@end example

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

@node No Pathological Implied-DO
@subsection No Pathological Implied-DO

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

@smallexample
DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
@end smallexample

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

Note that it is @emph{very} unlikely that any production Fortran code
tries to use this unsupported construct.

@node No Useless Implied-DO
@subsection No Useless Implied-DO

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

@smallexample
DATA (A, I= 1, 1) /1./
@end smallexample

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

Note that it is @emph{very} unlikely that any production Fortran code
tries to use this unsupported construct.

@node Conformance
@section Conformance

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

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

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

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

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

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

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

@item
Bugs in the program.

@item
Bug in @command{g77}.

@item
Bugs in the system.
@end itemize

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

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

@node Notation Used
@section Notation Used in This Chapter

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

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

For example:

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

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

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

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

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

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

@itemize @bullet
@item
Keywords defined by the GNU Fortran language are shown
in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
@code{BLOCK DATA}.

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

@item
Portions of actual sample program, input, or output text
look like this: @samp{Actual program text}.

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

For example: @samp{PRINT *, 'My name is Bob'}.

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

``The @code{INTEGER @var{ivar}} statement specifies that
@var{ivar} is a variable or array of type @code{INTEGER}.''

In the above example, any valid text may be substituted for
the metasyntactic variable @var{ivar} to make the statement
apply to a specific instance, as long as the same text is
substituted for @emph{both} occurrences of @var{ivar}.

@item
Ellipses (``@dots{}'') are used to indicate further text that
is either unimportant or expanded upon further, elsewhere.

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

@xref{Kind Notation}, for information on the relationship
between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
and the more traditional, less portably concise nomenclature
(such as @code{INTEGER*4}).
@end itemize

@node Terms and Concepts
@section Fortran Terms and Concepts

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

@menu
* Syntactic Items::
* Statements Comments Lines::
* Scope of Names and Labels::
@end menu

@node Syntactic Items
@subsection Syntactic Items

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

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

Underscores (@samp{_}) are accepted in symbol names after the first
character (which must be a letter).

@node Statements Comments Lines
@subsection Statements, Comments, and Lines

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

@cindex trailing comment
@cindex comment
@cindex characters, comment
@cindex !
@cindex exclamation point
@cindex continuation character
@cindex characters, continuation
Use of an exclamation point (@samp{!}) to begin a
trailing comment (a comment that extends to the end of the same
source line) is permitted under the following conditions:

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

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

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

@cindex ;
@cindex semicolon
@cindex statements, separated by semicolon
Use of a semicolon (@samp{;}) as a statement separator
is permitted under the following conditions:

@itemize @bullet
@item
The semicolon appears outside a character or Hollerith
constant.
Otherwise, the semicolon is considered part of the
constant.

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

@item
Neither a logical @code{IF} statement nor a non-construct
@code{WHERE} statement (a Fortran 90 feature) may be
followed (in the same, possibly continued, line) by
a semicolon used as a statement separator.

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

@smallexample
IF (VALIDP) CALL FOO; CALL BAR
@end smallexample

@noindent
Some readers might think the @samp{CALL BAR} is executed
only if @samp{VALIDP} is @code{.TRUE.}, while others might
assume its execution is unconditional.

(At present, @command{g77} does not diagnose code that
violates this restriction.)
@end itemize

@node Scope of Names and Labels
@subsection Scope of Symbolic Names and Statement Labels
@cindex scope

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

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

@node Characters Lines Sequence
@section Characters, Lines, and Execution Sequence

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

@menu
* Character Set::
* Lines::
* Continuation Line::
* Statements::
* Statement Labels::
* Order::
* INCLUDE::
* Cpp-style directives::
@end menu

@node Character Set
@subsection GNU Fortran Character Set
@cindex characters

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

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

Special characters include:

@itemize @bullet
@item
@cindex ;
@cindex semicolon
Semicolon (@samp{;})

@item
@cindex !
@cindex exclamation point
Exclamation point (@samp{!})

@item
@cindex "
@cindex double quote
Double quote (@samp{"})

@item
@cindex \
@cindex backslash
Backslash (@samp{\})

@item
@cindex ?
@cindex question mark
Question mark (@samp{?})

@item
@cindex #
@cindex hash mark
@cindex pound sign
Hash mark (@samp{#})

@item
@cindex &
@cindex ampersand
Ampersand (@samp{&})

@item
@cindex %
@cindex percent sign
Percent sign (@samp{%})

@item
@cindex _
@cindex underscore
Underscore (@samp{_})

@item
@cindex <
@cindex open angle
@cindex left angle
@cindex open bracket
@cindex left bracket
Open angle (@samp{<})

@item
@cindex >
@cindex close angle
@cindex right angle
@cindex close bracket
@cindex right bracket
Close angle (@samp{>})

@item
The FORTRAN 77 special characters (@key{SPC}, @samp{=},
@samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
@samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
and @samp{:})
@end itemize

@cindex blank
@cindex space
@cindex SPC
Note that this document refers to @key{SPC} as @dfn{space},
while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.

@node Lines
@subsection Lines
@cindex lines
@cindex source file format
@cindex source format
@cindex file, source
@cindex source code
@cindex code, source
@cindex fixed form
@cindex free form

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

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

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

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

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

@itemize @bullet
@item
A newline in the file is the character that represents the end of
a line of text to the underlying system.
For example, on ASCII-based systems, a newline is the @key{NL}
character, which has ASCII value 10 (decimal).

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

@item
The end-of-file marker (@code{EOF}) also serves to end the line
of text that precedes it (and that does not contain a newline).

@item
@cindex blank
@cindex space
@cindex SPC
Any line of text that is shorter than 72 characters is padded to that length
with spaces (called ``blanks'' in the standard).

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

@item
Characters other than newline and the GNU Fortran character set
are invalid.
@end itemize

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

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

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

@node Continuation Line
@subsection Continuation Line
@cindex continuation line, number of
@cindex lines, continuation
@cindex number of continuation lines
@cindex limits, continuation lines

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

A continuation line is any line that both

@itemize @bullet
@item
Contains a continuation character, and

@item
Contains only spaces in columns 1 through 5
@end itemize

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

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

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

@node Statements
@subsection Statements

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

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

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

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

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

@example
      END
     &PROGRAM
@end example

@node Statement Labels
@subsection Statement Labels

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

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

@itemize @bullet
@item
The semicolon is followed by the label for the statement,
which in turn follows the label.

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

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

A statement may have only one label defined for it.

@node Order
@subsection Order of Statements and Lines

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

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

The last line of a program unit may be an @code{END} statement,
or may be:

@itemize @bullet
@item
An @code{END PROGRAM} statement, if the program unit is a main program.

@item
An @code{END SUBROUTINE} statement, if the program unit is a subroutine.

@item
An @code{END FUNCTION} statement, if the program unit is a function.

@item
An @code{END BLOCK DATA} statement, if the program unit is a block data.
@end itemize

@node INCLUDE
@subsection Including Source Text
@cindex INCLUDE directive

Additional source text may be included in the processing of
the source file via the @code{INCLUDE} directive:

@example
INCLUDE @var{filename}
@end example

@noindent
The source text to be included is identified by @var{filename},
which is a literal GNU Fortran character constant.
The meaning and interpretation of @var{filename} depends on the
implementation, but typically is a filename.

(@command{g77} treats it as a filename that it searches for
in the current directory and/or directories specified
via the @option{-I} command-line option.)

The effect of the @code{INCLUDE} directive is as if the
included text directly replaced the directive in the source
file prior to interpretation of the program.
Included text may itself use @code{INCLUDE}.
The depth of nested @code{INCLUDE} references depends on
the implementation, but typically is a positive integer.

This virtual replacement treats the statements and @code{INCLUDE}
directives in the included text as syntactically distinct from
those in the including text.

Therefore, the first non-comment line of the included text
must not be a continuation line.
The included text must therefore have, after the non-comment
lines, either an initial line (statement), an @code{INCLUDE}
directive, or nothing (the end of the included text).

Similarly, the including text may end the @code{INCLUDE}
directive with a semicolon or the end of the line, but it
cannot follow an @code{INCLUDE} directive at the end of its
line with a continuation line.
Thus, the last statement in an included text may not be
continued.

Any statements between two @code{INCLUDE} directives on the
same line are treated as if they appeared in between the
respective included texts.
For example:

@smallexample
INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
@end smallexample

@noindent
If the text included by @samp{INCLUDE 'A'} constitutes
a @samp{PRINT *, 'A'} statement and the text included by
@samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
then the output of the above sample program would be

@example
A
B
C
@end example

@noindent
(with suitable allowances for how an implementation defines
its handling of output).

Included text must not include itself directly or indirectly,
regardless of whether the @var{filename} used to reference
the text is the same.

Note that @code{INCLUDE} is @emph{not} a statement.
As such, it is neither a non-executable or executable
statement.
However, if the text it includes constitutes one or more
executable statements, then the placement of @code{INCLUDE}
is subject to effectively the same restrictions as those
on executable statements.

An @code{INCLUDE} directive may be continued across multiple
lines as if it were a statement.
This permits long names to be used for @var{filename}.

@node Cpp-style directives
@subsection Cpp-style directives
@cindex #
@cindex preprocessor

@code{cpp} output-style @code{#} directives
(@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
are recognized by the compiler even
when the preprocessor isn't run on the input (as it is when compiling
@samp{.F} files).  (Note the distinction between these @command{cpp}
@code{#} @emph{output} directives and @code{#line} @emph{input}
directives.)

@node Data Types and Constants
@section Data Types and Constants

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

To more concisely express the appropriate types for
entities, this document uses the more concise
Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
instead of the more traditional, but less portably concise,
byte-size-based nomenclature such as @code{INTEGER*4},
wherever reasonable.

When referring to generic types---in contexts where the
specific precision and range of a type are not important---this
document uses the generic type names @code{INTEGER}, @code{LOGICAL},
@code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.

In some cases, the context requires specification of a
particular type.
This document uses the @samp{KIND=} notation to accomplish
this throughout, sometimes supplying the more traditional
notation for clarification, though the traditional notation
might not work the same way on all GNU Fortran implementations.

Use of @samp{KIND=} makes this document more concise because
@command{g77} is able to define values for @samp{KIND=} that
have the same meanings on all systems, due to the way the
Fortran 90 standard specifies these values are to be used.

(In particular, that standard permits an implementation to
arbitrarily assign nonnegative values.
There are four distinct sets of assignments: one to the @code{CHARACTER}
type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
and the fourth to both the @code{REAL} and @code{COMPLEX} types.
Implementations are free to assign these values in any order,
leave gaps in the ordering of assignments, and assign more than
one value to a representation.)

This makes @samp{KIND=} values superior to the values used
in non-standard statements such as @samp{INTEGER*4}, because
the meanings of the values in those statements vary from machine
to machine, compiler to compiler, even operating system to
operating system.

However, use of @samp{KIND=} is @emph{not} generally recommended
when writing portable code (unless, for example, the code is
going to be compiled only via @command{g77}, which is a widely
ported compiler).
GNU Fortran does not yet have adequate language constructs to
permit use of @samp{KIND=} in a fashion that would make the
code portable to Fortran 90 implementations; and, this construct
is known to @emph{not} be accepted by many popular FORTRAN 77
implementations, so it cannot be used in code that is to be ported
to those.

The distinction here is that this document is able to use
specific values for @samp{KIND=} to concisely document the
types of various operations and operands.

A Fortran program should use the FORTRAN 77 designations for the
appropriate GNU Fortran types---such as @code{INTEGER} for
@code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
where no such designations exist, make use of appropriate
techniques (preprocessor macros, parameters, and so on)
to specify the types in a fashion that may be easily adjusted
to suit each particular implementation to which the program
is ported.
(These types generally won't need to be adjusted for ports of
@command{g77}.)

Further details regarding GNU Fortran data types and constants
are provided below.

@menu
* Types::
* Constants::
* Integer Type::
* Character Type::
@end menu

@node Types
@subsection Data Types

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

GNU Fortran supports these types:

@enumerate
@item
Integer (generic type @code{INTEGER})

@item
Real (generic type @code{REAL})

@item
Double precision

@item
Complex (generic type @code{COMPLEX})

@item
Logical (generic type @code{LOGICAL})

@item
Character (generic type @code{CHARACTER})

@item
Double Complex
@end enumerate

(The types numbered 1 through 6 above are standard FORTRAN 77 types.)

The generic types shown above are referred to in this document
using only their generic type names.
Such references usually indicate that any specific type (kind)
of that generic type is valid.

For example, a context described in this document as accepting
the @code{COMPLEX} type also is likely to accept the
@code{DOUBLE COMPLEX} type.

The GNU Fortran language supports three ways to specify
a specific kind of a generic type.

@menu
* Double Notation::  As in @code{DOUBLE COMPLEX}.
* Star Notation::    As in @code{INTEGER*4}.
* Kind Notation::    As in @code{INTEGER(KIND=1)}.
@end menu

@node Double Notation
@subsubsection Double Notation

The GNU Fortran language supports two uses of the keyword
@code{DOUBLE} to specify a specific kind of type:

@itemize @bullet
@item
@code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}

@item
@code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
@end itemize

Use one of the above forms where a type name is valid.

While use of this notation is popular, it doesn't scale
well in a language or dialect rich in intrinsic types,
as is the case for the GNU Fortran language (especially
planned future versions of it).

After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
@samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
often are substituted for these, respectively, even though they
do not always have the same meanings on all systems.
(And, the fact that @samp{DOUBLE REAL} does not exist as such
is an inconsistency.)

Therefore, this document uses ``double notation'' only on occasion
for the benefit of those readers who are accustomed to it.

@node Star Notation
@subsubsection Star Notation
@cindex *@var{n} notation

The following notation specifies the storage size for a type:

@smallexample
@var{generic-type}*@var{n}
@end smallexample

@noindent
@var{generic-type} must be a generic type---one of
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
or @code{CHARACTER}.
@var{n} must be one or more digits comprising a decimal
integer number greater than zero.

Use the above form where a type name is valid.

The @samp{*@var{n}} notation specifies that the amount of storage
occupied by variables and array elements of that type is @var{n}
times the storage occupied by a @code{CHARACTER*1} variable.

This notation might indicate a different degree of precision and/or
range for such variables and array elements, and the functions that
return values of types using this notation.
It does not limit the precision or range of values of that type
in any particular way---use explicit code to do that.

Further, the GNU Fortran language requires no particular values
for @var{n} to be supported by an implementation via the @samp{*@var{n}}
notation.
@command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
on all systems, for example,
but not all implementations are required to do so, and @command{g77}
is known to not support @code{REAL*1} on most (or all) systems.

As a result, except for @var{generic-type} of @code{CHARACTER},
uses of this notation should be limited to isolated
portions of a program that are intended to handle system-specific
tasks and are expected to be non-portable.

(Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
only @code{CHARACTER}, where it signifies not only the amount
of storage occupied, but the number of characters in entities
of that type.
However, almost all Fortran compilers have supported this
notation for generic types, though with a variety of meanings
for @var{n}.)

Specifications of types using the @samp{*@var{n}} notation
always are interpreted as specifications of the appropriate
types described in this document using the @samp{KIND=@var{n}}
notation, described below.

While use of this notation is popular, it doesn't serve well
in the context of a widely portable dialect of Fortran, such as
the GNU Fortran language.

For example, even on one particular machine, two or more popular
Fortran compilers might well disagree on the size of a type
declared @code{INTEGER*2} or @code{REAL*16}.
Certainly there
is known to be disagreement over such things among Fortran
compilers on @emph{different} systems.

Further, this notation offers no elegant way to specify sizes
that are not even multiples of the ``byte size'' typically
designated by @code{INTEGER*1}.
Use of ``absurd'' values (such as @code{INTEGER*1000}) would
certainly be possible, but would perhaps be stretching the original
intent of this notation beyond the breaking point in terms
of widespread readability of documentation and code making use
of it.

Therefore, this document uses ``star notation'' only on occasion
for the benefit of those readers who are accustomed to it.

@node Kind Notation
@subsubsection Kind Notation
@cindex KIND= notation

The following notation specifies the kind-type selector of a type:

@smallexample
@var{generic-type}(KIND=@var{n})
@end smallexample

@noindent
Use the above form where a type name is valid.

@var{generic-type} must be a generic type---one of
@code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
or @code{CHARACTER}.
@var{n} must be an integer initialization expression that
is a positive, nonzero value.

Programmers are discouraged from writing these values directly
into their code.
Future versions of the GNU Fortran language will offer
facilities that will make the writing of code portable
to @command{g77} @emph{and} Fortran 90 implementations simpler.

However, writing code that ports to existing FORTRAN 77
implementations depends on avoiding the @samp{KIND=} construct.

The @samp{KIND=} construct is thus useful in the context
of GNU Fortran for two reasons:

@itemize @bullet
@item
It provides a means to specify a type in a fashion that
is portable across all GNU Fortran implementations (though
not other FORTRAN 77 and Fortran 90 implementations).

@item
It provides a sort of Rosetta stone for this document to use
to concisely describe the types of various operations and
operands.
@end itemize

The values of @var{n} in the GNU Fortran language are
assigned using a scheme that:

@itemize @bullet
@item
Attempts to maximize the ability of readers
of this document to quickly familiarize themselves
with assignments for popular types

@item
Provides a unique value for each specific desired
meaning

@item
Provides a means to automatically assign new values so
they have a ``natural'' relationship to existing values,
if appropriate, or, if no such relationship exists, will
not interfere with future values assigned on the basis
of such relationships

@item
Avoids using values that are similar to values used
in the existing, popular @samp{*@var{n}} notation,
to prevent readers from expecting that these implied
correspondences work on all GNU Fortran implementations
@end itemize

The assignment system accomplishes this by assigning
to each ``fundamental meaning'' of a specific type a
unique prime number.
Combinations of fundamental meanings---for example, a type
that is two times the size of some other type---are assigned
values of @var{n} that are the products of the values for
those fundamental meanings.

A prime value of @var{n} is never given more than one fundamental
meaning, to avoid situations where some code or system
cannot reasonably provide those meanings in the form of a
single type.

The values of @var{n} assigned so far are:

@table @code
@item KIND=0
This value is reserved for future use.

The planned future use is for this value to designate,
explicitly, context-sensitive kind-type selection.
For example, the expression @samp{1D0 * 0.1_0} would
be equivalent to @samp{1D0 * 0.1D0}.

@item KIND=1
This corresponds to the default types for
@code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
and @code{CHARACTER}, as appropriate.

These are the ``default'' types described in the Fortran 90 standard,
though that standard does not assign any particular @samp{KIND=}
value to these types.

(Typically, these are @code{REAL*4}, @code{INTEGER*4},
@code{LOGICAL*4}, and @code{COMPLEX*8}.)

@item KIND=2
This corresponds to types that occupy twice as much
storage as the default types.
@code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
@code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),

These are the ``double precision'' types described in the Fortran 90
standard,
though that standard does not assign any particular @samp{KIND=}
value to these types.

@var{n} of 4 thus corresponds to types that occupy four times
as much storage as the default types, @var{n} of 8 to types that
occupy eight times as much storage, and so on.

The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
are not necessarily supported by every GNU Fortran implementation.

@item KIND=3
This corresponds to types that occupy as much
storage as the default @code{CHARACTER} type,
which is the same effective type as @code{CHARACTER(KIND=1)}
(making that type effectively the same as @code{CHARACTER(KIND=3)}).

(Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)

@var{n} of 6 thus corresponds to types that occupy twice as
much storage as the @var{n}=3 types, @var{n} of 12 to types
that occupy four times as much storage, and so on.

These are not necessarily supported by every GNU Fortran
implementation.

@item KIND=5
This corresponds to types that occupy half the
storage as the default (@var{n}=1) types.

(Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)

@var{n} of 25 thus corresponds to types that occupy one-quarter
as much storage as the default types.

These are not necessarily supported by every GNU Fortran
implementation.

@item KIND=7
@cindex pointers
This is valid only as @code{INTEGER(KIND=7)} and
denotes the @code{INTEGER} type that has the smallest
storage size that holds a pointer on the system.

A pointer representable by this type is capable of uniquely
addressing a @code{CHARACTER*1} variable, array, array element,
or substring.

(Typically this is equivalent to @code{INTEGER*4} or,
on 64-bit systems, @code{INTEGER*8}.
In a compatible C implementation, it typically would
be the same size and semantics of the C type @code{void *}.)
@end table

Note that these are @emph{proposed} correspondences and might change
in future versions of @command{g77}---avoid writing code depending
on them while @command{g77}, and therefore the GNU Fortran language
it defines, is in beta testing.

Values not specified in the above list are reserved to
future versions of the GNU Fortran language.

Implementation-dependent meanings will be assigned new,
unique prime numbers so as to not interfere with other
implementation-dependent meanings, and offer the possibility
of increasing the portability of code depending on such
types by offering support for them in other GNU Fortran
implementations.

Other meanings that might be given unique values are:

@itemize @bullet
@item
Types that make use of only half their storage size for
representing precision and range.

For example, some compilers offer options that cause
@code{INTEGER} types to occupy the amount of storage
that would be needed for @code{INTEGER(KIND=2)} types, but the
range remains that of @code{INTEGER(KIND=1)}.

@item
The IEEE single floating-point type.

@item
Types with a specific bit pattern (endianness), such as the
little-endian form of @code{INTEGER(KIND=1)}.
These could permit, conceptually, use of portable code and
implementations on data files written by existing systems.
@end itemize

Future @emph{prime} numbers should be given meanings in as incremental
a fashion as possible, to allow for flexibility and
expressiveness in combining types.

For example, instead of defining a prime number for little-endian
IEEE doubles, one prime number might be assigned the meaning
``little-endian'', another the meaning ``IEEE double'', and the
value of @var{n} for a little-endian IEEE double would thus
naturally be the product of those two respective assigned values.
(It could even be reasonable to have IEEE values result from the
products of prime values denoting exponent and fraction sizes
and meanings, hidden bit usage, availability and representations
of special values such as subnormals, infinities, and Not-A-Numbers
(NaNs), and so on.)

This assignment mechanism, while not inherently required for
future versions of the GNU Fortran language, is worth using
because it could ease management of the ``space'' of supported
types much easier in the long run.

The above approach suggests a mechanism for specifying inheritance
of intrinsic (built-in) types for an entire, widely portable
product line.
It is certainly reasonable that, unlike programmers of other languages
offering inheritance mechanisms that employ verbose names for classes
and subclasses, along with graphical browsers to elucidate the
relationships, Fortran programmers would employ
a mechanism that works by multiplying prime numbers together
and finding the prime factors of such products.

Most of the advantages for the above scheme have been explained
above.
One disadvantage is that it could lead to the defining,
by the GNU Fortran language, of some fairly large prime numbers.
This could lead to the GNU Fortran language being declared
``munitions'' by the United States Department of Defense.

@node Constants
@subsection Constants
@cindex constants
@cindex types, constants

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

A @dfn{typeless constant} has one of the following forms:

@smallexample
'@var{binary-digits}'B
'@var{octal-digits}'O
'@var{hexadecimal-digits}'Z
'@var{hexadecimal-digits}'X
@end smallexample

@noindent
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
and @samp{0123456789ABCDEFabcdef}, respectively.
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
is 11, and so on.)

A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
treated as typeless.  @xref{Fortran Dialect Options,, Options
Controlling Fortran Dialect}, for information on the
@option{-ftypeless-boz} option.

Typeless constants have values that depend on the context in which
they are used.

All other constants, called @dfn{typed constants}, are interpreted---converted
to internal form---according to their inherent type.
Thus, context is @emph{never} a determining factor for the type, and hence
the interpretation, of a typed constant.
(All constants in the ANSI FORTRAN 77 language are typed constants.)

For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
Fortran (called default INTEGER in Fortran 90),
@samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
additional precision specified is lost, and even when used in a
@code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
and @samp{1D0} is always type @code{REAL(KIND=2)}.

@node Integer Type
@subsection Integer Type

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

An integer constant also may have one of the following forms:

@smallexample
B'@var{binary-digits}'
O'@var{octal-digits}'
Z'@var{hexadecimal-digits}'
X'@var{hexadecimal-digits}'
@end smallexample

@noindent
@var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
are nonempty strings of characters in the set @samp{01}, @samp{01234567},
and @samp{0123456789ABCDEFabcdef}, respectively.
(The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
is 11, and so on.)

@node Character Type
@subsection Character Type

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

@cindex double quoted character constants
A character constant may be delimited by a pair of double quotes
(@samp{"}) instead of apostrophes.
In this case, an apostrophe within the constant represents
a single apostrophe, while a double quote is represented in
the source text of the constant by two consecutive double
quotes with no intervening spaces.

@cindex zero-length CHARACTER
@cindex null CHARACTER strings
@cindex empty CHARACTER strings
@cindex strings, empty
@cindex CHARACTER, null
A character constant may be empty (have a length of zero).

A character constant may include a substring specification,
The value of such a constant is the value of the substring---for
example, the value of @samp{'hello'(3:5)} is the same
as the value of @samp{'llo'}.

@node Expressions
@section Expressions

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

@menu
* %LOC()::
@end menu

@node %LOC()
@subsection The @code{%LOC()} Construct
@cindex %LOC() construct

@example
%LOC(@var{arg})
@end example

The @code{%LOC()} construct is an expression
that yields the value of the location of its argument,
@var{arg}, in memory.
The size of the type of the expression depends on the system---typically,
it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
though it is actually type @code{INTEGER(KIND=7)}.

The argument to @code{%LOC()} must be suitable as the
left-hand side of an assignment statement.
That is, it may not be a general expression involving
operators such as addition, subtraction, and so on,
nor may it be a constant.

Use of @code{%LOC()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions that deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%LOC()} returning a pointer that
can be safely used to @emph{define} (change) the argument.
While this might work in some circumstances, it is hard
to predict whether it will continue to work when a program
(that works using this unsafe behavior)
is recompiled using different command-line options or
a different version of @command{g77}.

Generally, @code{%LOC()} is safe when used as an argument
to a procedure that makes use of the value of the corresponding
dummy argument only during its activation, and only when
such use is restricted to referencing (reading) the value
of the argument to @code{%LOC()}.

@emph{Implementation Note:} Currently, @command{g77} passes
arguments (those not passed using a construct such as @code{%VAL()})
by reference or descriptor, depending on the type of
the actual argument.
Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
in fact might compile to identical code.

However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
``pass, by value, the address of @samp{I} in memory''.
While @samp{CALL FOO(I)} might use that same approach in a
particular version of @command{g77}, another version or compiler
might choose a different implementation, such as copy-in/copy-out,
to effect the desired behavior---and which will therefore not
necessarily compile to the same code as would
@samp{CALL FOO(%VAL(%LOC(I)))}
using the same version or compiler.

@xref{Debugging and Interfacing}, for detailed information on
how this particular version of @command{g77} implements various
constructs.

@node Specification Statements
@section Specification Statements

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

@menu
* NAMELIST::
* DOUBLE COMPLEX::
@end menu

@node NAMELIST
@subsection @code{NAMELIST} Statement
@cindex NAMELIST statement
@cindex statements, NAMELIST

The @code{NAMELIST} statement, and related I/O constructs, are
supported by the GNU Fortran language in essentially the same
way as they are by @command{f2c}.

This follows Fortran 90 with the restriction that on @code{NAMELIST}
input, subscripts must have the form
@smallexample
@var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
@end smallexample
i.e.@:
@smallexample
&xx x(1:3,8:10:2)=1,2,3,4,5,6/
@end smallexample
is allowed, but not, say,
@smallexample
&xx x(:3,8::2)=1,2,3,4,5,6/
@end smallexample

As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
@smallexample
$&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
@end smallexample
could be used instead of the example above.

@node DOUBLE COMPLEX
@subsection @code{DOUBLE COMPLEX} Statement
@cindex DOUBLE COMPLEX

@code{DOUBLE COMPLEX} is a type-statement (and type) that
specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.

@node Control Statements
@section Control Statements

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

@menu
* DO WHILE::
* END DO::
* Construct Names::
* CYCLE and EXIT::
@end menu

@node DO WHILE
@subsection DO WHILE
@cindex DO WHILE
@cindex DO
@cindex MIL-STD 1753

The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
Fortran 90 standards, is provided by the GNU Fortran language.
The Fortran 90 ``do forever'' statement comprising just @code{DO} is
also supported.

@node END DO
@subsection END DO
@cindex END DO
@cindex MIL-STD 1753

The @code{END DO} statement is provided by the GNU Fortran language.

This statement is used in one of two ways:

@itemize @bullet
@item
The Fortran 90 meaning, in which it specifies the termination
point of a single @code{DO} loop started with a @code{DO} statement
that specifies no termination label.

@item
The MIL-STD 1753 meaning, in which it specifies the termination
point of one or more @code{DO} loops, all of which start with a
@code{DO} statement that specify the label defined for the
@code{END DO} statement.

This kind of @code{END DO} statement is merely a synonym for
@code{CONTINUE}, except it is permitted only when the statement
is labeled and a target of one or more labeled @code{DO} loops.

It is expected that this use of @code{END DO} will be removed from
the GNU Fortran language in the future, though it is likely that
it will long be supported by @command{g77} as a dialect form.
@end itemize

@node Construct Names
@subsection Construct Names
@cindex construct names

The GNU Fortran language supports construct names as defined
by the Fortran 90 standard.
These names are local to the program unit and are defined
as follows:

@smallexample
@var{construct-name}: @var{block-statement}
@end smallexample

@noindent
Here, @var{construct-name} is the construct name itself;
its definition is connoted by the single colon (@samp{:}); and
@var{block-statement} is an @code{IF}, @code{DO},
or @code{SELECT CASE} statement that begins a block.

A block that is given a construct name must also specify the
same construct name in its termination statement:

@example
END @var{block} @var{construct-name}
@end example

@noindent
Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
as appropriate.

@node CYCLE and EXIT
@subsection The @code{CYCLE} and @code{EXIT} Statements

@cindex CYCLE statement
@cindex EXIT statement
@cindex statements, CYCLE
@cindex statements, EXIT
The @code{CYCLE} and @code{EXIT} statements specify that
the remaining statements in the current iteration of a
particular active (enclosing) @code{DO} loop are to be skipped.

@code{CYCLE} specifies that these statements are skipped,
but the @code{END DO} statement that marks the end of the
@code{DO} loop be executed---that is, the next iteration,
if any, is to be started.
If the statement marking the end of the @code{DO} loop is
not @code{END DO}---in other words, if the loop is not
a block @code{DO}---the @code{CYCLE} statement does not
execute that statement, but does start the next iteration (if any).

@code{EXIT} specifies that the loop specified by the
@code{DO} construct is terminated.

The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
is the innermost enclosing @code{DO} loop when the following
forms are used:

@example
CYCLE
EXIT
@end example

Otherwise, the following forms specify the construct name
of the pertinent @code{DO} loop:

@example
CYCLE @var{construct-name}
EXIT @var{construct-name}
@end example

@code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
statements.
However, they cannot be easily thought of as @code{GO TO} statements
in obscure cases involving FORTRAN 77 loops.
For example:

@smallexample
      DO 10 I = 1, 5
      DO 10 J = 1, 5
         IF (J .EQ. 5) EXIT
      DO 10 K = 1, 5
         IF (K .EQ. 3) CYCLE
10    PRINT *, 'I=', I, ' J=', J, ' K=', K
20    CONTINUE
@end smallexample

@noindent
In particular, neither the @code{EXIT} nor @code{CYCLE} statements
above are equivalent to a @code{GO TO} statement to either label
@samp{10} or @samp{20}.

To understand the effect of @code{CYCLE} and @code{EXIT} in the
above fragment, it is helpful to first translate it to its equivalent
using only block @code{DO} loops:

@smallexample
      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) EXIT
            DO K = 1, 5
               IF (K .EQ. 3) CYCLE
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
            END DO
         END DO
      END DO
20    CONTINUE
@end smallexample

Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
to @code{GO TO} so they may be more easily understood by programmers
accustomed to FORTRAN coding:

@smallexample
      DO I = 1, 5
         DO J = 1, 5
            IF (J .EQ. 5) GOTO 18
            DO K = 1, 5
               IF (K .EQ. 3) GO TO 12
10             PRINT *, 'I=', I, ' J=', J, ' K=', K
12          END DO
         END DO
18    END DO
20    CONTINUE
@end smallexample

@noindent
Thus, the @code{CYCLE} statement in the innermost loop skips over
the @code{PRINT} statement as it begins the next iteration of the
loop, while the @code{EXIT} statement in the middle loop ends that
loop but @emph{not} the outermost loop.

@node Functions and Subroutines
@section Functions and Subroutines

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

@menu
* %VAL()::
* %REF()::
* %DESCR()::
* Generics and Specifics::
* REAL() and AIMAG() of Complex::
* CMPLX() of DOUBLE PRECISION::
* MIL-STD 1753::
* f77/f2c Intrinsics::
* Table of Intrinsic Functions::
@end menu

@node %VAL()
@subsection The @code{%VAL()} Construct
@cindex %VAL() construct

@example
%VAL(@var{arg})
@end example

The @code{%VAL()} construct specifies that an argument,
@var{arg}, is to be passed by value, instead of by reference
or descriptor.

@code{%VAL()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%VAL()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

@emph{Implementation Note:} Currently, @command{g77} passes
all arguments either by reference or by descriptor.

Thus, use of @code{%VAL()} tends to be restricted to cases
where the called procedure is written in a language other
than Fortran that supports call-by-value semantics.
(C is an example of such a language.)

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node %REF()
@subsection The @code{%REF()} Construct
@cindex %REF() construct

@example
%REF(@var{arg})
@end example

The @code{%REF()} construct specifies that an argument,
@var{arg}, is to be passed by reference, instead of by
value or descriptor.

@code{%REF()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%REF()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%REF()} supplying a pointer to the
procedure being invoked.
While that is a likely implementation choice, other
implementation choices are available that preserve Fortran
pass-by-reference semantics without passing a pointer to
the argument, @var{arg}.
(For example, a copy-in/copy-out implementation.)

@emph{Implementation Note:} Currently, @command{g77} passes
all arguments
(other than variables and arrays of type @code{CHARACTER})
by reference.
Future versions of, or dialects supported by, @command{g77} might
not pass @code{CHARACTER} functions by reference.

Thus, use of @code{%REF()} tends to be restricted to cases
where @var{arg} is type @code{CHARACTER} but the called
procedure accesses it via a means other than the method
used for Fortran @code{CHARACTER} arguments.

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node %DESCR()
@subsection The @code{%DESCR()} Construct
@cindex %DESCR() construct

@example
%DESCR(@var{arg})
@end example

The @code{%DESCR()} construct specifies that an argument,
@var{arg}, is to be passed by descriptor, instead of by
value or reference.

@code{%DESCR()} is restricted to actual arguments in
invocations of external procedures.

Use of @code{%DESCR()} is recommended only for code that
is accessing facilities outside of GNU Fortran, such as
operating system or windowing facilities.
It is best to constrain such uses to isolated portions of
a program---portions the deal specifically and exclusively
with low-level, system-dependent facilities.
Such portions might well provide a portable interface for
use by the program as a whole, but are themselves not
portable, and should be thoroughly tested each time they
are rebuilt using a new compiler or version of a compiler.

Do not depend on @code{%DESCR()} supplying a pointer
and/or a length passed by value
to the procedure being invoked.
While that is a likely implementation choice, other
implementation choices are available that preserve the
pass-by-reference semantics without passing a pointer to
the argument, @var{arg}.
(For example, a copy-in/copy-out implementation.)
And, future versions of @command{g77} might change the
way descriptors are implemented, such as passing a
single argument pointing to a record containing the
pointer/length information instead of passing that same
information via two arguments as it currently does.

@emph{Implementation Note:} Currently, @command{g77} passes
all variables and arrays of type @code{CHARACTER}
by descriptor.
Future versions of, or dialects supported by, @command{g77} might
pass @code{CHARACTER} functions by descriptor as well.

Thus, use of @code{%DESCR()} tends to be restricted to cases
where @var{arg} is not type @code{CHARACTER} but the called
procedure accesses it via a means similar to the method
used for Fortran @code{CHARACTER} arguments.

@xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
how this particular version of @command{g77} passes arguments
to procedures.

@node Generics and Specifics
@subsection Generics and Specifics
@cindex generic intrinsics
@cindex intrinsics, generic

The ANSI FORTRAN 77 language defines generic and specific
intrinsics.
In short, the distinctions are:

@itemize @bullet
@item
@emph{Specific} intrinsics have
specific types for their arguments and a specific return
type.

@item
@emph{Generic} intrinsics are treated,
on a case-by-case basis in the program's source code,
as one of several possible specific intrinsics.

Typically, a generic intrinsic has a return type that
is determined by the type of one or more of its arguments.
@end itemize

The GNU Fortran language generalizes these concepts somewhat,
especially by providing intrinsic subroutines and generic
intrinsics that are treated as either a specific intrinsic subroutine
or a specific intrinsic function (e.g. @code{SECOND}).

However, GNU Fortran avoids generalizing this concept to
the point where existing code would be accepted as meaning
something possibly different than what was intended.

For example, @code{ABS} is a generic intrinsic, so all working
code written using @code{ABS} of an @code{INTEGER} argument
expects an @code{INTEGER} return value.
Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
argument returns an @code{INTEGER*2} return value.

Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
an @code{INTEGER(KIND=1)} argument.
Code that passes something other than an @code{INTEGER(KIND=1)}
argument to @code{IABS} is not valid GNU Fortran code, because
it is not clear what the author intended.

For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
is not defined by the GNU Fortran language, because the programmer
might have used that construct to mean any of the following, subtly
different, things:

@itemize @bullet
@item
Convert @samp{J} to @code{INTEGER(KIND=1)} first
(as if @samp{IABS(INT(J))} had been written).

@item
Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
(as if @samp{INT(ABS(J))} had been written).

@item
No conversion (as if @samp{ABS(J)} had been written).
@end itemize

The distinctions matter especially when types and values wider than
@code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
operations performing more ``arithmetic'' than absolute-value, are involved.

The following sample program is not a valid GNU Fortran program, but
might be accepted by other compilers.
If so, the output is likely to be revealing in terms of how a given
compiler treats intrinsics (that normally are specific) when they
are given arguments that do not conform to their stated requirements:

@cindex JCB002 program
@smallexample
      PROGRAM JCB002
C Version 1:
C Modified 1999-02-15 (Burley) to delete my email address.
C Modified 1997-05-21 (Burley) to accommodate compilers that implement
C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
C
C Version 0:
C Written by James Craig Burley 1997-02-20.
C
C Purpose:
C Determine how compilers handle non-standard IDIM
C on INTEGER*2 operands, which presumably can be
C extrapolated into understanding how the compiler
C generally treats specific intrinsics that are passed
C arguments not of the correct types.
C
C If your compiler implements INTEGER*2 and INTEGER
C as the same type, change all INTEGER*2 below to
C INTEGER*1.
C
      INTEGER*2 I0, I4
      INTEGER I1, I2, I3
      INTEGER*2 ISMALL, ILARGE
      INTEGER*2 ITOOLG, ITWO
      INTEGER*2 ITMP
      LOGICAL L2, L3, L4
C
C Find smallest INTEGER*2 number.
C
      ISMALL=0
 10   I0 = ISMALL-1
      IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
      ISMALL = I0
      GOTO 10
 20   CONTINUE
C
C Find largest INTEGER*2 number.
C
      ILARGE=0
 30   I0 = ILARGE+1
      IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
      ILARGE = I0
      GOTO 30
 40   CONTINUE
C
C Multiplying by two adds stress to the situation.
C
      ITWO = 2
C
C Need a number that, added to -2, is too wide to fit in I*2.
C
      ITOOLG = ISMALL
C
C Use IDIM the straightforward way.
C
      I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
C
C Calculate result for first interpretation.
C
      I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
C
C Calculate result for second interpretation.
C
      ITMP = ILARGE - ISMALL
      I3 = (INT (ITMP)) * ITWO + ITOOLG
C
C Calculate result for third interpretation.
C
      I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
C
C Print results.
C
      PRINT *, 'ILARGE=', ILARGE
      PRINT *, 'ITWO=', ITWO
      PRINT *, 'ITOOLG=', ITOOLG
      PRINT *, 'ISMALL=', ISMALL
      PRINT *, 'I1=', I1
      PRINT *, 'I2=', I2
      PRINT *, 'I3=', I3
      PRINT *, 'I4=', I4
      PRINT *
      L2 = (I1 .EQ. I2)
      L3 = (I1 .EQ. I3)
      L4 = (I1 .EQ. I4)
      IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
         STOP
      END IF
      IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
         PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
         STOP
      END IF
      IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
         PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
         STOP
      END IF
      PRINT *, 'Results need careful analysis.'
      END
@end smallexample

No future version of the GNU Fortran language
will likely permit specific intrinsic invocations with wrong-typed
arguments (such as @code{IDIM} in the above example), since
it has been determined that disagreements exist among
many production compilers on the interpretation of
such invocations.
These disagreements strongly suggest that Fortran programmers,
and certainly existing Fortran programs, disagree about the
meaning of such invocations.

The first version of @code{JCB002} didn't accommodate some compilers'
treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
@code{INTEGER*2}.
In such a case, these compilers apparently convert both
operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
instead of doing an @code{INTEGER*2} subtraction on the
original values in @samp{I1} and @samp{I2}.

However, the results of the careful analyses done on the outputs
of programs compiled by these various compilers show that they
all implement either @samp{Interp 1} or @samp{Interp 2} above.

Specifically, it is believed that the new version of @code{JCB002}
above will confirm that:

@itemize @bullet
@item
Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
@command{f77} compilers all implement @samp{Interp 1}.

@item
IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}.

@item
Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}.
@end itemize

If you get different results than the above for the stated
compilers, or have results for other compilers that might be
worth adding to the above list, please let us know the details
(compiler product, version, machine, results, and so on).

@node REAL() and AIMAG() of Complex
@subsection @code{REAL()} and @code{AIMAG()} of Complex
@cindex @code{Real} intrinsic
@cindex intrinsics, @code{Real}
@cindex @code{AImag} intrinsic
@cindex intrinsics, @code{AImag}

The GNU Fortran language disallows @code{REAL(@var{expr})}
and @code{AIMAG(@var{expr})},
where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
except when they are used in the following way:

@example
REAL(REAL(@var{expr}))
REAL(AIMAG(@var{expr}))
@end example

@noindent
The above forms explicitly specify that the desired effect
is to convert the real or imaginary part of @var{expr}, which might
be some @code{REAL} type other than @code{REAL(KIND=1)},
to type @code{REAL(KIND=1)},
and have that serve as the value of the expression.

The GNU Fortran language offers clearly named intrinsics to extract the
real and imaginary parts of a complex entity without any
conversion:

@example
REALPART(@var{expr})
IMAGPART(@var{expr})
@end example

To express the above using typical extended FORTRAN 77,
use the following constructs
(when @var{expr} is @code{COMPLEX(KIND=2)}):

@example
DBLE(@var{expr})
DIMAG(@var{expr})
@end example

The FORTRAN 77 language offers no way
to explicitly specify the real and imaginary parts of a complex expression of
arbitrary type, apparently as a result of requiring support for
only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
The concepts of converting an expression to type @code{REAL(KIND=1)} and
of extracting the real part of a complex expression were
thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
they happened to have the exact same effect in that language
(due to having only one @code{COMPLEX} type).

@emph{Note:} When @option{-ff90} is in effect,
@command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
whereas with @samp{-fugly-complex -fno-f90} in effect, it is
treated as @samp{REAL(REALPART(@var{expr}))}.

@xref{Ugly Complex Part Extraction}, for more information.

@node CMPLX() of DOUBLE PRECISION
@subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
@cindex @code{Cmplx} intrinsic
@cindex intrinsics, @code{Cmplx}

In accordance with Fortran 90 and at least some (perhaps all)
other compilers, the GNU Fortran language defines @code{CMPLX()}
as always returning a result that is type @code{COMPLEX(KIND=1)}.

This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:

@example
CMPLX(SNGL(D1), SNGL(D2))
@end example

(It was necessary for Fortran 90 to specify this behavior
for @code{DOUBLE PRECISION} arguments, since that is
the behavior mandated by FORTRAN 77.)

The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
which is provided by some FORTRAN 77 compilers to construct
a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
operands.
However, this solution does not scale well when more @code{COMPLEX} types
(having various precisions and ranges) are offered by Fortran implementations.

Fortran 90 extends the @code{CMPLX()} intrinsic by adding
an extra argument used to specify the desired kind of complex
result.
However, this solution is somewhat awkward to use, and
@command{g77} currently does not support it.

The GNU Fortran language provides a simple way to build a complex
value out of two numbers, with the precise type of the value
determined by the types of the two numbers (via the usual
type-promotion mechanism):

@example
COMPLEX(@var{real}, @var{imag})
@end example

When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
performs no conversion other than to put them together to form a
complex result of the same (complex version of real) type.

@xref{Complex Intrinsic}, for more information.

@node MIL-STD 1753
@subsection MIL-STD 1753 Support
@cindex MIL-STD 1753

The GNU Fortran language includes the MIL-STD 1753 intrinsics
@code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
@code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
@code{ISHFTC}, @code{MVBITS}, and @code{NOT}.

@node f77/f2c Intrinsics
@subsection @command{f77}/@command{f2c} Intrinsics

The bit-manipulation intrinsics supported by traditional
@command{f77} and by @command{f2c} are available in the GNU Fortran language.
These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
and @code{XOR}.

Also supported are the intrinsics @code{CDABS},
@code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
@code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
@code{DIMAG}, @code{DREAL}, and @code{IMAG},
@code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
and @code{ZSQRT}.

@node Table of Intrinsic Functions
@subsection Table of Intrinsic Functions
@cindex intrinsics, table of
@cindex table of intrinsics

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

The GNU Fortran language adds various functions, subroutines, types,
and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
The complete set of intrinsics supported by the GNU Fortran language
is described below.

Note that a name is not treated as that of an intrinsic if it is
specified in an @code{EXTERNAL} statement in the same program unit;
if a command-line option is used to disable the groups to which
the intrinsic belongs; or if the intrinsic is not named in an
@code{INTRINSIC} statement and a command-line option is used to
hide the groups to which the intrinsic belongs.

So, it is recommended that any reference in a program unit to
an intrinsic procedure that is not a standard FORTRAN 77
intrinsic be accompanied by an appropriate @code{INTRINSIC}
statement in that program unit.
This sort of defensive programming makes it more
likely that an implementation will issue a diagnostic rather
than generate incorrect code for such a reference.

The terminology used below is based on that of the Fortran 90
standard, so that the text may be more concise and accurate:

@itemize @bullet
@item
@code{OPTIONAL} means the argument may be omitted.

@item
@samp{A-1, A-2, @dots{}, A-n} means more than one argument
(generally named @samp{A}) may be specified.

@item
@samp{scalar} means the argument must not be an array (must
be a variable or array element, or perhaps a constant if expressions
are permitted).

@item
@samp{DIMENSION(4)} means the argument must be an array having 4 elements.

@item
@code{INTENT(IN)} means the argument must be an expression
(such as a constant or a variable that is defined upon invocation
of the intrinsic).

@item
@code{INTENT(OUT)} means the argument must be definable by the
invocation of the intrinsic (that is, must not be a constant nor
an expression involving operators other than array reference and
substring reference).

@item
@code{INTENT(INOUT)} means the argument must be defined prior to,
and definable by, invocation of the intrinsic (a combination of
the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.

@item
@xref{Kind Notation}, for an explanation of @code{KIND}.
@end itemize

@ifinfo
(Note that the empty lines appearing in the menu below
are not intentional---they result from a bug in the
GNU @command{makeinfo} program@dots{}a program that, if it
did not exist, would leave this document in far worse shape!)
@end ifinfo

@c The actual documentation for intrinsics comes from
@c intdoc.texi, which in turn is automatically generated
@c from the internal g77 tables in intrin.def _and_ the
@c largely hand-written text in intdoc.h.  So, if you want
@c to change or add to existing documentation on intrinsics,
@c you probably want to edit intdoc.h.
@c
@set familyF77
@set familyGNU
@set familyASC
@set familyMIL
@set familyF90
@clear familyVXT
@clear familyFVZ
@set familyF2C
@set familyF2U
@clear familyBADU77
@include intdoc.texi

@node Scope and Classes of Names
@section Scope and Classes of Symbolic Names
@cindex symbol names, scope and classes
@cindex scope

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

@menu
* Underscores in Symbol Names::
@end menu

@node Underscores in Symbol Names
@subsection Underscores in Symbol Names
@cindex underscore

Underscores (@samp{_}) are accepted in symbol names after the first
character (which must be a letter).

@node I/O
@section I/O

@cindex dollar sign
A dollar sign at the end of an output format specification suppresses
the newline at the end of the output.

@cindex <> edit descriptor
@cindex edit descriptor, <>
Edit descriptors in @code{FORMAT} statements may contain compile-time
@code{INTEGER} constant expressions in angle brackets, such as
@smallexample
10    FORMAT (I<WIDTH>)
@end smallexample

The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.

These Fortran 90 features are supported:
@itemize @bullet
@item
@cindex FORMAT descriptors
@cindex Z edit descriptor
@cindex edit descriptor, Z
@cindex O edit descriptor
@cindex edit descriptor, O
The @code{O} and @code{Z} edit descriptors are supported for I/O of
integers in octal and hexadecimal formats, respectively.
@item
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
@code{STATUS='SCRATCH'} is supplied.  The @code{STATUS='REPLACE'}
specifier is supported.
@end itemize

@node Fortran 90 Features
@section Fortran 90 Features
@cindex Fortran 90
@cindex extensions, from Fortran 90

For convenience this section collects a list (probably incomplete) of
the Fortran 90 features supported by the GNU Fortran language, even if
they are documented elsewhere.
@xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
for information on additional fixed source form lexical issues.
@cindex @option{-ffree-form}
Further, the free source form is supported through the
@option{-ffree-form} option.
@cindex @option{-ff90}
Other Fortran 90 features can be turned on by the @option{-ff90} option;
see @ref{Fortran 90}.
For information on the Fortran 90 intrinsics available,
see @ref{Table of Intrinsic Functions}.

@table @asis
@item Automatic arrays in procedures
@item Character assignments
@cindex character assignments
In character assignments, the variable being assigned may occur on the
right hand side of the assignment.
@item Character strings
@cindex double quoted character constants
Strings may have zero length and substrings of character constants are
permitted.  Character constants may be enclosed in double quotes
(@code{"}) as well as single quotes.  @xref{Character Type}.
@item Construct names
(Symbolic tags on blocks.)  @xref{Construct Names}.
@item @code{CYCLE} and @code{EXIT}
@xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
@item @code{DOUBLE COMPLEX}
@xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
@item @code{DO WHILE}
@xref{DO WHILE}.
@item @code{END} decoration
@xref{Statements}.
@item @code{END DO}
@xref{END DO}.
@item @code{KIND}
@item @code{IMPLICIT NONE}
@item @code{INCLUDE} statements
@xref{INCLUDE}.
@item List-directed and namelist I/O on internal files
@item Binary, octal and hexadecimal constants
These are supported more generally than required by Fortran 90.
@xref{Integer Type}.
@item @samp{O} and @samp{Z} edit descriptors
@item @code{NAMELIST}
@xref{NAMELIST}.
@item @code{OPEN} specifiers
@code{STATUS='REPLACE'} is supported.
The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
@code{STATUS='SCRATCH'} is supplied.
@item @code{FORMAT} edit descriptors
@cindex FORMAT descriptors
@cindex Z edit descriptor
@cindex edit descriptor, Z
The @code{Z} edit descriptor is supported.
@item Relational operators
The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
@code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
@code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
@item @code{SELECT CASE}
Not fully implemented.
@xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
@item Specification statements
A limited subset of the Fortran 90 syntax and semantics for variable
declarations is supported, including @code{KIND}.  @xref{Kind Notation}.
(@code{KIND} is of limited usefulness in the absence of the
@code{KIND}-related intrinsics, since these intrinsics permit writing
more widely portable code.)  An example of supported @code{KIND} usage
is:
@smallexample
INTEGER (KIND=1) :: FOO=1, BAR=2
CHARACTER (LEN=3) FOO
@end smallexample
@code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
@end table

@node Other Dialects
@chapter Other Dialects

GNU Fortran supports a variety of features that are not
considered part of the GNU Fortran language itself, but
are representative of various dialects of Fortran that
@command{g77} supports in whole or in part.

Any of the features listed below might be disallowed by
@command{g77} unless some command-line option is specified.
Currently, some of the features are accepted using the
default invocation of @command{g77}, but that might change
in the future.

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Source Form::       Details of fixed-form and free-form source.
* Trailing Comment::  Use of @samp{/*} to start a comment.
* Debug Line::        Use of @samp{D} in column 1.
* Dollar Signs::      Use of @samp{$} in symbolic names.
* Case Sensitivity::  Uppercase and lowercase in source files.
* VXT Fortran::       @dots{}versus the GNU Fortran language.
* Fortran 90::        @dots{}versus the GNU Fortran language.
* Pedantic Compilation::  Enforcing the standard.
* Distensions::       Misfeatures supported by GNU Fortran.
@end menu

@node Source Form
@section Source Form
@cindex source file format
@cindex source format
@cindex file, source
@cindex source code
@cindex code, source
@cindex fixed form
@cindex free form

GNU Fortran accepts programs written in either fixed form or
free form.

Fixed form
corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
allowing tabs) and Fortran 90's fixed form.

Free form corresponds to
Fortran 90's free form (though possibly not entirely up-to-date, and
without complaining about some things that for which Fortran 90 requires
diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).

The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler, since those choices
are explicitly left to the implementation by the published Fortran
standards.
GNU Fortran currently tries to be somewhat like a few popular compilers
(@command{f2c}, Digital (``DEC'') Fortran, and so on).

This section describes how @command{g77} interprets source lines.

@menu
* Carriage Returns::  Carriage returns ignored.
* Tabs::              Tabs converted to spaces.
* Short Lines::       Short lines padded with spaces (fixed-form only).
* Long Lines::        Long lines truncated.
* Ampersands::        Special Continuation Lines.
@end menu

@node Carriage Returns
@subsection Carriage Returns
@cindex carriage returns

Carriage returns (@samp{\r}) in source lines are ignored.
This is somewhat different from @command{f2c}, which seems to treat them as
spaces outside character/Hollerith constants, and encodes them as @samp{\r}
inside such constants.

@node Tabs
@subsection Tabs
@cindex tab character
@cindex horizontal tab

A source line with a @key{TAB} character anywhere in it is treated as
entirely significant---however long it is---instead of ending in
column 72 (for fixed-form source) or 132 (for free-form source).
This also is different from @command{f2c}, which encodes tabs as
@samp{\t} (the ASCII @key{TAB} character) inside character
and Hollerith constants, but nevertheless seems to treat the column
position as if it had been affected by the canonical tab positioning.

@command{g77} effectively
translates tabs to the appropriate number of spaces (a la the default
for the UNIX @command{expand} command) before doing any other processing, other
than (currently) noting whether a tab was found on a line and using this
information to decide how to interpret the length of the line and continued
constants.

@node Short Lines
@subsection Short Lines
@cindex short source lines
@cindex space, padding with
@cindex source lines, short
@cindex lines, short

Source lines shorter than the applicable fixed-form length are treated as
if they were padded with spaces to that length.
(None of this is relevant to source files written in free form.)

This affects only
continued character and Hollerith constants, and is a different
interpretation than provided by some other popular compilers
(although a bit more consistent with the traditional punched-card
basis of Fortran and the way the Fortran standard expressed fixed
source form).

@command{g77} might someday offer an option to warn about cases where differences
might be seen as a result of this treatment, and perhaps an option to
specify the alternate behavior as well.

Note that this padding cannot apply to lines that are effectively of
infinite length---such lines are specified using command-line options
like @option{-ffixed-line-length-none}, for example.

@node Long Lines
@subsection Long Lines
@cindex long source lines
@cindex truncation, of long lines
@cindex lines, long
@cindex source lines, long

Source lines longer than the applicable length are truncated to that
length.
Currently, @command{g77} does not warn if the truncated characters are
not spaces, to accommodate existing code written for systems that
treated truncated text as commentary (especially in columns 73 through 80).

@xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
for information on the @option{-ffixed-line-length-@var{n}} option,
which can be used to set the line length applicable to fixed-form
source files.

@node Ampersands
@subsection Ampersand Continuation Line
@cindex ampersand continuation line
@cindex continuation line, ampersand

A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
continuation line, imitating the behavior of @command{f2c}.

@node Trailing Comment
@section Trailing Comment

@cindex trailing comment
@cindex comment
@cindex characters, comment
@cindex /*
@cindex !
@cindex exclamation point
@command{g77} supports use of @samp{/*} to start a trailing
comment.
In the GNU Fortran language, @samp{!} is used for this purpose.

@samp{/*} is not in the GNU Fortran language
because the use of @samp{/*} in a program might
suggest to some readers that a block, not trailing, comment is
started (and thus ended by @samp{*/}, not end of line),
since that is the meaning of @samp{/*} in C.

Also, such readers might think they can use @samp{//} to start
a trailing comment as an alternative to @samp{/*}, but
@samp{//} already denotes concatenation, and such a ``comment''
might actually result in a program that compiles without
error (though it would likely behave incorrectly).

@node Debug Line
@section Debug Line
@cindex debug line
@cindex comment line, debug

Use of @samp{D} or @samp{d} as the first character (column 1) of
a source line denotes a debug line.

In turn, a debug line is treated as either a comment line
or a normal line, depending on whether debug lines are enabled.

When treated as a comment line, a line beginning with @samp{D} or
@samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
When treated as a normal line, such a line is treated as if
the first character was @key{SPC} (space).

(Currently, @command{g77} provides no means for treating debug
lines as normal lines.)

@node Dollar Signs
@section Dollar Signs in Symbol Names
@cindex dollar sign
@cindex $

Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
when the @option{-fdollar-ok} option is specified.

@node Case Sensitivity
@section Case Sensitivity
@cindex case sensitivity
@cindex source file format
@cindex code, source
@cindex source code
@cindex uppercase letters
@cindex lowercase letters
@cindex letters, uppercase
@cindex letters, lowercase

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

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

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

@itemize @w{}
@item A
Source Case Conversion:

@itemize @w{}
@item 0
Preserve (see Note 1)
@item 1
Convert to Upper Case
@item 2
Convert to Lower Case
@end itemize

@item B
Built-in Keyword Matching:

@itemize @w{}
@item 0
Match Any Case (per-character basis)
@item 1
Match Upper Case Only
@item 2
Match Lower Case Only
@item 3
Match InitialCaps Only (see tables for spellings)
@end itemize

@item C
Built-in Intrinsic Matching:

@itemize @w{}
@item 0
Match Any Case (per-character basis)
@item 1
Match Upper Case Only
@item 2
Match Lower Case Only
@item 3
Match InitialCaps Only (see tables for spellings)
@end itemize

@item D
User-defined Symbol Possibilities (warnings only):

@itemize @w{}
@item 0
Allow Any Case (per-character basis)
@item 1
Allow Upper Case Only
@item 2
Allow Lower Case Only
@item 3
Allow InitialCaps Only (see Note 2)
@end itemize
@end itemize

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

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

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

Note 2: Rules for InitialCaps names are:

@itemize @minus
@item
Must be a single uppercase letter, @strong{or}
@item
Must start with an uppercase letter and contain at least one
lowercase letter.
@end itemize

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

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

@smallexample
A0: -fsource-case-preserve
A1: -fsource-case-upper
A2: -fsource-case-lower

B0: -fmatch-case-any
B1: -fmatch-case-upper
B2: -fmatch-case-lower
B3: -fmatch-case-initcap

C0: -fintrin-case-any
C1: -fintrin-case-upper
C2: -fintrin-case-lower
C3: -fintrin-case-initcap

D0: -fsymbol-case-any
D1: -fsymbol-case-upper
D2: -fsymbol-case-lower
D3: -fsymbol-case-initcap
@end smallexample

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

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

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

Number 43 is like Number 22 except all input must be lowercase.  Use
@option{-fcase-strict-lower} to specify this combination.

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

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

There are a few nearly useless combinations:

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

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

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

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

@node VXT Fortran
@section VXT Fortran

@cindex VXT extensions
@cindex extensions, VXT
@command{g77} supports certain constructs that
have different meanings in VXT Fortran than they
do in the GNU Fortran language.

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

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

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

@menu
* Double Quote Meaning::  @samp{"2000} as octal constant.
* Exclamation Point::     @samp{!} in column 6.
@end menu

@node Double Quote Meaning
@subsection Meaning of Double Quote
@cindex double quotes
@cindex character constants
@cindex constants, character
@cindex octal constants
@cindex constants, octal

@command{g77} treats double-quote (@samp{"})
as beginning an octal constant of @code{INTEGER(KIND=1)} type
when the @option{-fvxt} option is specified.
The form of this octal constant is

@example
"@var{octal-digits}
@end example

@noindent
where @var{octal-digits} is a nonempty string of characters in
the set @samp{01234567}.

For example, the @option{-fvxt} option permits this:

@example
PRINT *, "20
END
@end example

@noindent
The above program would print the value @samp{16}.

@xref{Integer Type}, for information on the preferred construct
for integer constants specified using GNU Fortran's octal notation.

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

@node Exclamation Point
@subsection Meaning of Exclamation Point in Column 6
@cindex !
@cindex exclamation point
@cindex continuation character
@cindex characters, continuation
@cindex comment character
@cindex characters, comment

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

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

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

(In the GNU Fortran and Fortran 90 languages, exclamation point is
a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
marks a line as a continuation line when it appears in column 6.)

@node Fortran 90
@section Fortran 90
@cindex compatibility, Fortran 90
@cindex Fortran 90, compatibility

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

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

When @option{-ff90} is specified:

@itemize @bullet
@item
The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
where @var{expr} is @code{COMPLEX} type,
is the same type as the real part of @var{expr}.

For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
@samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified.
@end itemize

@node Pedantic Compilation
@section Pedantic Compilation
@cindex pedantic compilation
@cindex compilation, pedantic

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

With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
for conforming code.
With @option{-ff90} in force, Fortran 90 is used.

The constructs for which @command{g77} issues diagnostics when @option{-fpedantic}
and @option{-fno-f90} are in force are:

@itemize @bullet
@item
Automatic arrays, as in

@example
SUBROUTINE X(N)
REAL A(N)
@dots{}
@end example

@noindent
where @samp{A} is not listed in any @code{ENTRY} statement,
and thus is not a dummy argument.

@item
The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.

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

@item
@code{DOUBLE COMPLEX}, either explicitly or implicitly.

An explicit use of this type is via a @code{DOUBLE COMPLEX} or
@code{IMPLICIT DOUBLE COMPLEX} statement, for examples.

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

@item
Automatic conversion of numeric
expressions to @code{INTEGER(KIND=1)} in contexts such as:

@itemize @minus
@item
Array-reference indexes.
@item
Alternate-return values.
@item
Computed @code{GOTO}.
@item
@code{FORMAT} run-time expressions (not yet supported).
@item
Dimension lists in specification statements.
@item
Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
@item
Sizes of @code{CHARACTER} entities in specification statements.
@item
Kind types in specification entities (a Fortran 90 feature).
@item
Initial, terminal, and incrementation parameters for implied-@code{DO}
constructs in @code{DATA} statements.
@end itemize

@item
Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
expressions are disallowed anyway).

@item
Zero-size array dimensions, as in:

@example
INTEGER I(10,20,4:2)
@end example

@item
Zero-length @code{CHARACTER} entities, as in:

@example
PRINT *, ''
@end example

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

@example
PRINT *, 'hello'(3:5)
@end example

@item
Null arguments passed to statement function, as in:

@example
PRINT *, FOO(,3)
@end example

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

@item
Disagreement among program units regarding the size of a
named @code{COMMON} block.

@item
Specification statements following first @code{DATA} statement.

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

@item
Semicolon as statement separator, as in:

@example
CALL FOO; CALL BAR
@end example
@c
@c @item
@c Comma before list of I/O items in @code{WRITE}
@c  @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
@c statements, as with @code{READ} (as explained above).

@item
Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).

@item
Use of @code{CHARACTER} constants to initialize numeric entities, and vice
versa.

@item
Expressions having two arithmetic operators in a row, such
as @samp{X*-Y}.
@end itemize

If @option{-fpedantic} is specified along with @option{-ff90}, the
following constructs result in diagnostics:

@itemize @bullet
@item
Use of semicolon as a statement separator on a line
that has an @code{INCLUDE} directive.
@end itemize

@node Distensions
@section Distensions
@cindex distensions
@cindex ugly features
@cindex features, ugly

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

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

@node Ugly Implicit Argument Conversion
@subsection Implicit Argument Conversion
@cindex Hollerith constants
@cindex constants, Hollerith

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

@example
CALL FOO(4HABCD)
CALL BAR('123'O)
@end example

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

@node Ugly Assumed-Size Arrays
@subsection Ugly Assumed-Size Arrays
@cindex arrays, assumed-size
@cindex assumed-size arrays
@cindex DIMENSION X(1)

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

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

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

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

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

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

@emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
treated if @samp{X} is listed as a dummy argument only
@emph{after} the @code{DIMENSION} statement (presumably in
an @code{ENTRY} statement).
For example, @option{-fugly-assumed} has no effect on the
following program unit:

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

@node Ugly Complex Part Extraction
@subsection Ugly Complex Part Extraction
@cindex complex values
@cindex real part
@cindex imaginary part

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

With @option{-ff90} in effect, these intrinsics return
the unconverted real and imaginary parts (respectively)
of their argument.

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

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

@example
REAL(REAL(Z))
@end example

@noindent
is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
and @option{-fno-ugly-complex} is in effect, because the
meaning is clear.

@command{g77} enforces this restriction, unless @option{-fugly-complex}
is specified, in which case the appropriate interpretation is
chosen and no diagnostic is issued.

@xref{CMPAMBIG}, for information on how to cope with existing
code with unclear expectations of @code{REAL()} and @code{AIMAG()}
with @code{COMPLEX(KIND=2)} arguments.

@xref{RealPart Intrinsic}, for information on the @code{REALPART()}
intrinsic, used to extract the real part of a complex expression
without conversion.
@xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
intrinsic, used to extract the imaginary part of a complex expression
without conversion.

@node Ugly Null Arguments
@subsection Ugly Null Arguments
@cindex trailing comma
@cindex comma, trailing
@cindex characters, comma
@cindex null arguments
@cindex arguments, null

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

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

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

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

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

@emph{Note:} Many systems gracefully allow the case
where a procedure call passes one extra argument that the
called procedure does not expect.

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

@node Ugly Conversion of Initializers
@subsection Ugly Conversion of Initializers

The constructs disabled by @option{-fno-ugly-init} are:

@itemize @bullet
@cindex Hollerith constants
@cindex constants, Hollerith
@item
Use of Hollerith and typeless constants in contexts where they set
initial (compile-time) values for variables, arrays, and named
constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
type-declaration statements specifying initial values.

Here are some sample initializations that are disabled by the
@option{-fno-ugly-init} option:

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

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

Here are more sample initializations that are disabled by the
@option{-fno-ugly-init} option:

@example
INTEGER IA
CHARACTER BELL
PARAMETER (IA = 'A')
PARAMETER (BELL = 7)
@end example

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

Here are sample statements that are disabled by the
@option{-fno-ugly-init} option:

@example
IVAR = 4HABCD
PRINT *, IMAX0(2HAB, 2HBA)
@end example
@end itemize

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

@node Ugly Integer Conversions
@subsection Ugly Integer Conversions

The constructs enabled via @option{-fugly-logint} are:

@itemize @bullet
@item
Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
dictated by
context (typically implies nonportable dependencies on how a
particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).

@item
Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
statements.
@end itemize

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

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

@xref{Equivalence Versus Equality}, for more information.

@node Ugly Assigned Labels
@subsection Ugly Assigned Labels
@cindex ASSIGN statement
@cindex statements, ASSIGN
@cindex assigned labels
@cindex pointers

The @option{-fugly-assign} option forces @command{g77} to use the
same storage for assigned labels as it would for a normal
assignment to the same variable.

For example, consider the following code fragment:

@example
I = 3
ASSIGN 10 TO I
@end example

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

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

@example
ASSIGN 10 TO I
ISTATE(5) = I
@dots{}
J = ISTATE(ICUR)
GOTO J
@end example

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

@emph{Note:} To avoid subtle program bugs,
when @option{-fugly-assign} is specified,
@command{g77} requires the type of variables
specified in assigned-label contexts
@emph{must} be the same type returned by @code{%LOC()}.
On many systems, this type is effectively the same
as @code{INTEGER(KIND=1)}, while, on others, it is
effectively the same as @code{INTEGER(KIND=2)}.

Do @emph{not} depend on @command{g77} actually writing valid pointers
to these variables, however.
While @command{g77} currently chooses that implementation, it might
be changed in the future.

@xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
for implementation details on assigned-statement labels.

@node Compiler
@chapter The GNU Fortran Compiler

The GNU Fortran compiler, @command{g77}, supports programs written
in the GNU Fortran language and in some other dialects of Fortran.

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

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Compiler Limits::
* Run-time Environment Limits::
* Compiler Types::
* Compiler Constants::
* Compiler Intrinsics::
@end menu

@node Compiler Limits
@section Compiler Limits
@cindex limits, compiler
@cindex compiler limits

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

@cindex options, -Nl
@cindex -Nl option
@cindex options, -Nx
@cindex -Nx option
@cindex limits, continuation lines
@cindex limits, lengths of names
For example, some other Fortran compiler have an option
(such as @option{-Nl@var{x}}) to increase the limit on the
number of continuation lines.
Also, some Fortran compilation systems have an option
(such as @option{-Nx@var{x}}) to increase the limit on the
number of external symbols.

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

@cindex rank, maximum
@cindex maximum rank
@cindex number of dimensions, maximum
@cindex maximum number of dimensions
@cindex limits, rank
@cindex limits, array dimensions
@command{g77} does currently limit the number of dimensions in an array
to the same degree as do the Fortran standards---seven (7).
This restriction might be lifted in a future version.

@node Run-time Environment Limits
@section Run-time Environment Limits
@cindex limits, run-time library
@cindex wraparound

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

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

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

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

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

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

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

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

@node Timer Wraparounds
@subsection Timer Wraparounds

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

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

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

@node Year 2000 (Y2K) Problems
@subsection Year 2000 (Y2K) Problems
@cindex Y2K compliance
@cindex Year 2000 compliance

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

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

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

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

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

@cindex y2kbuggy
@cindex date_y2kbuggy_0
@cindex vxtidate_y2kbuggy_0
@cindex G77_date_y2kbuggy_0
@cindex G77_vxtidate_y2kbuggy_0
The @code{libg2c} library
shipped with any @command{g77} that warns
about invocation of a non-Y2K-compliant intrinsic
has renamed the @code{EXTERNAL} procedure names
of those intrinsics.
This is done so that
the @code{libg2c} implementations of these intrinsics
cannot be directly linked to
as @code{EXTERNAL} names
(which normally would avoid the non-Y2K-intrinsic warning).

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

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

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

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

Generally, we recommend that the @code{EXTERNAL} method
of invoking procedures in @code{libg2c}
@emph{not} be used.
When used, some of the correctness checking
normally performed by @command{g77}
is skipped.

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

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

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

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

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

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

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

@node Array Size
@subsection Array Size
@cindex limits, array size
@cindex array size

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

@c ??? Investigate this, to offer a more clear statement
@c than the following paragraphs do.  -- burley 1999-02-17
It is not yet clear whether this limitation
never, sometimes, or always applies to the
sizes of multiple-dimension arrays as a whole.

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

@cindex limits, multi-dimension arrays
@cindex multi-dimension arrays
@cindex arrays, dimensioning
Whether large multiple-dimension arrays are reliably supported
depends mostly on the @command{gcc} back end (code generator)
used by @command{g77}, and has not yet been fully investigated.

@node Character-variable Length
@subsection Character-variable Length
@cindex limits, on character-variable length
@cindex character-variable length

Currently, @command{g77} uses the default @code{INTEGER} type
for the lengths of @code{CHARACTER} variables
and array elements.

This means that, for example,
a system with a 64-bit address space
and a 32-bit default @code{INTEGER} type
does not, under @command{g77},
support a @code{CHARACTER*@var{n}} declaration
where @var{n} is greater than 2147483647.

@node Year 10000 (Y10K) Problems
@subsection Year 10000 (Y10K) Problems
@cindex Y10K compliance
@cindex Year 10000 compliance

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

See the following for examples:
@ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
@ref{IDate Intrinsic (UNIX)},
@ref{Time Intrinsic (VXT)},
@ref{Date_and_Time Intrinsic}.

@node Compiler Types
@section Compiler Types
@cindex types, of data
@cindex data types

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

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

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

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

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

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

@table @code
@cindex REAL(KIND=1) type
@cindex types, REAL(KIND=1)
@item REAL(KIND=1)
Same as @code{float} type.

@cindex REAL(KIND=2) type
@cindex types, REAL(KIND=2)
@item REAL(KIND=2)
Same as whatever floating-point type that is twice the size
of a @code{float}---usually, this is a @code{double}.

@cindex INTEGER(KIND=1) type
@cindex types, INTEGER(KIND=1)
@item INTEGER(KIND=1)
Same as an integral type that is occupies the same amount
of memory storage as @code{float}---usually, this is either
an @code{int} or a @code{long int}.

@cindex LOGICAL(KIND=1) type
@cindex types, LOGICAL(KIND=1)
@item LOGICAL(KIND=1)
Same @command{gcc} type as @code{INTEGER(KIND=1)}.

@cindex INTEGER(KIND=2) type
@cindex types, INTEGER(KIND=2)
@item INTEGER(KIND=2)
Twice the size, and usually nearly twice the range,
as @code{INTEGER(KIND=1)}---usually, this is either
a @code{long int} or a @code{long long int}.

@cindex LOGICAL(KIND=2) type
@cindex types, LOGICAL(KIND=2)
@item LOGICAL(KIND=2)
Same @command{gcc} type as @code{INTEGER(KIND=2)}.

@cindex INTEGER(KIND=3) type
@cindex types, INTEGER(KIND=3)
@item INTEGER(KIND=3)
Same @command{gcc} type as signed @code{char}.

@cindex LOGICAL(KIND=3) type
@cindex types, LOGICAL(KIND=3)
@item LOGICAL(KIND=3)
Same @command{gcc} type as @code{INTEGER(KIND=3)}.

@cindex INTEGER(KIND=6) type
@cindex types, INTEGER(KIND=6)
@item INTEGER(KIND=6)
Twice the size, and usually nearly twice the range,
as @code{INTEGER(KIND=3)}---usually, this is
a @code{short}.

@cindex LOGICAL(KIND=6) type
@cindex types, LOGICAL(KIND=6)
@item LOGICAL(KIND=6)
Same @command{gcc} type as @code{INTEGER(KIND=6)}.

@cindex COMPLEX(KIND=1) type
@cindex types, COMPLEX(KIND=1)
@item COMPLEX(KIND=1)
Two @code{REAL(KIND=1)} scalars (one for the real part followed by
one for the imaginary part).

@cindex COMPLEX(KIND=2) type
@cindex types, COMPLEX(KIND=2)
@item COMPLEX(KIND=2)
Two @code{REAL(KIND=2)} scalars.

@cindex *@var{n} notation
@item @var{numeric-type}*@var{n}
(Where @var{numeric-type} is any type other than @code{CHARACTER}.)
Same as whatever @command{gcc} type occupies @var{n} times the storage
space of a @command{gcc} @code{char} item.

@cindex DOUBLE PRECISION type
@cindex types, DOUBLE PRECISION
@item DOUBLE PRECISION
Same as @code{REAL(KIND=2)}.

@cindex DOUBLE COMPLEX type
@cindex types, DOUBLE COMPLEX
@item DOUBLE COMPLEX
Same as @code{COMPLEX(KIND=2)}.
@end table

Note that the above are proposed correspondences and might change
in future versions of @command{g77}---avoid writing code depending
on them.

Other types supported by @command{g77}
are derived from gcc types such as @code{char}, @code{short},
@code{int}, @code{long int}, @code{long long int}, @code{long double},
and so on.
That is, whatever types @command{gcc} already supports, @command{g77} supports
now or probably will support in a future version.
The rules for the @samp{@var{numeric-type}*@var{n}} notation
apply to these types,
and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
assigned in a way that encourages clarity, consistency, and portability.

@node Compiler Constants
@section Compiler Constants
@cindex constants
@cindex types, constants

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

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

@xref{Context-Sensitive Constants}, for more information on this issue.

@node Compiler Intrinsics
@section Compiler Intrinsics

@command{g77} offers an ever-widening set of intrinsics.
Currently these all are procedures (functions and subroutines).

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

To manage these distinctions, @command{g77} provides intrinsic @emph{groups},
a facility that is simply an extension of the intrinsic groups provided
by the GNU Fortran language.

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

@node Intrinsic Groups
@subsection Intrinsic Groups
@cindex groups of intrinsics
@cindex intrinsics, groups

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

@table @b
@cindex deleted intrinsics
@cindex intrinsics, deleted
@item Deleted
No intrinsics are recognized as belonging to that group.

@cindex disabled intrinsics
@cindex intrinsics, disabled
@item Disabled
Intrinsics are recognized as belonging to the group, but
references to them (other than via the @code{INTRINSIC} statement)
are disallowed through that group.

@cindex hidden intrinsics
@cindex intrinsics, hidden
@item Hidden
Intrinsics in that group are recognized and enabled (if implemented)
@emph{only} if the first mention of the actual name of an intrinsic
in a program unit is in an @code{INTRINSIC} statement.

@cindex enabled intrinsics
@cindex intrinsics, enabled
@item Enabled
Intrinsics in that group are recognized and enabled (if implemented).
@end table

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

@example
PRINT *, FOO()
END
@end example

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

@example
EXTERNAL FOO
@end example

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

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

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

The groups are:

@cindex intrinsics, groups of
@cindex groups of intrinsics
@table @code
@cindex @code{badu77} intrinsics group
@item badu77
UNIX intrinsics having inappropriate forms (usually functions that
have intended side effects).

@cindex @code{gnu} intrinsics group
@item gnu
Intrinsics the GNU Fortran language supports that are extensions to
the Fortran standards (77 and 90).

@cindex @command{f2c} intrinsics group
@item f2c
Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}.

@cindex @code{f90} intrinsics group
@item f90
Fortran 90 intrinsics.

@cindex @code{mil} intrinsics group
@item mil
MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).

@cindex @code{mil} intrinsics group
@item unix
UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).

@cindex @code{mil} intrinsics group
@item vxt
VAX/VMS FORTRAN (current as of v4) intrinsics.
@end table

@node Other Intrinsics
@subsection Other Intrinsics
@cindex intrinsics, others
@cindex other intrinsics

@command{g77} supports intrinsics other than those in the GNU Fortran
language proper.
This set of intrinsics is described below.

@ifinfo
(Note that the empty lines appearing in the menu below
are not intentional---they result from a bug in the
@code{makeinfo} program.)
@end ifinfo

@c The actual documentation for intrinsics comes from
@c intdoc.texi, which in turn is automatically generated
@c from the internal g77 tables in intrin.def _and_ the
@c largely hand-written text in intdoc.h.  So, if you want
@c to change or add to existing documentation on intrinsics,
@c you probably want to edit intdoc.h.
@c
@clear familyF77
@clear familyGNU
@clear familyASC
@clear familyMIL
@clear familyF90
@set familyVXT
@set familyFVZ
@clear familyF2C
@clear familyF2U
@set familyBADU77
@include intdoc.texi

@node Other Compilers
@chapter Other Compilers

An individual Fortran source file can be compiled to
an object (@file{*.o}) file instead of to the final
program executable.
This allows several portions of a program to be compiled
at different times and linked together whenever a new
version of the program is needed.
However, it introduces the issue of @dfn{object compatibility}
across the various object files (and libraries, or @file{*.a}
files) that are linked together to produce any particular
executable file.

Object compatibility is an issue when combining, in one
program, Fortran code compiled by more than one compiler
(or more than one configuration of a compiler).
If the compilers
disagree on how to transform the names of procedures, there
will normally be errors when linking such programs.
Worse, if the compilers agree on naming, but disagree on issues
like how to pass parameters, return arguments, and lay out
@code{COMMON} areas, the earliest detected errors might be the
incorrect results produced by the program (and that assumes
these errors are detected, which is not always the case).

Normally, @command{g77} generates code that is
object-compatible with code generated by a version of
@command{f2c} configured (with, for example, @file{f2c.h} definitions)
to be generally compatible with @command{g77} as built by @command{gcc}.
(Normally, @command{f2c} will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of @command{f2c}, or versions having certain configuration changes
to @command{f2c} internals, will produce object files that are
incompatible with @command{g77}.)

For example, a Fortran string subroutine
argument will become two arguments on the C side: a @code{char *}
and an @code{int} length.

Much of this compatibility results from the fact that
@command{g77} uses the same run-time library,
@code{libf2c}, used by @command{f2c},
though @command{g77} gives its version the name @code{libg2c}
so as to avoid conflicts when linking,
installing them in the same directories,
and so on.

Other compilers might or might not generate code that
is object-compatible with @code{libg2c} and current @command{g77},
and some might offer such compatibility only when explicitly
selected via a command-line option to the compiler.

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Dropping f2c Compatibility::  When speed is more important.
* Compilers Other Than f2c::    Interoperation with code from other compilers.
@end menu

@node Dropping f2c Compatibility
@section Dropping @command{f2c} Compatibility

Specifying @option{-fno-f2c} allows @command{g77} to generate, in
some cases, faster code, by not needing to allow to the possibility
of linking with code compiled by @command{f2c}.

For example, this affects how @code{REAL(KIND=1)},
@code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
With @option{-fno-f2c}, they are
compiled as returning the appropriate @command{gcc} type
(@code{float}, @code{__complex__ float}, @code{__complex__ double},
in many configurations).

With @option{-ff2c} in force, they
are compiled differently (with perhaps slower run-time performance)
to accommodate the restrictions inherent in @command{f2c}'s use of K&R
C as an intermediate language---@code{REAL(KIND=1)} functions
return C's @code{double} type, while @code{COMPLEX} functions return
@code{void} and use an extra argument pointing to a place for the functions to
return their values.

It is possible that, in some cases, leaving @option{-ff2c} in force
might produce faster code than using @option{-fno-f2c}.
Feel free to experiment, but remember to experiment with changing the way
@emph{entire programs and their Fortran libraries are compiled} at
a time, since this sort of experimentation affects the interface
of code generated for a Fortran source file---that is, it affects
object compatibility.

Note that @command{f2c} compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like @command{g77}, it is
still being improved.
However, specifying @option{-fno-f2c} causes @command{g77}
to generate code that will probably be incompatible with code
generated by future versions of @command{g77} when the same option
is in force.
You should make sure you are always able to recompile complete
programs from source code when upgrading to new versions of @command{g77}
or @command{f2c}, especially when using options such as @option{-fno-f2c}.

Therefore, if you are using @command{g77} to compile libraries and other
object files for possible future use and you don't want to require
recompilation for future use with subsequent versions of @command{g77},
you might want to stick with @command{f2c} compatibility for now, and
carefully watch for any announcements about changes to the
@command{f2c}/@code{libf2c} interface that might affect existing programs
(thus requiring recompilation).

It is probable that a future version of @command{g77} will not,
by default, generate object files compatible with @command{f2c},
and that version probably would no longer use @code{libf2c}.
If you expect to depend on this compatibility in the
long term, use the options @samp{-ff2c -ff2c-library} when compiling
all of the applicable code.
This should cause future versions of @command{g77} either to produce
compatible code (at the expense of the availability of some features and
performance), or at the very least, to produce diagnostics.

(The library @command{g77} produces will no longer be named @file{libg2c}
when it is no longer generally compatible with @file{libf2c}.
It will likely be referred to, and, if installed as a distinct
library, named @code{libg77}, or some other as-yet-unused name.)

@node Compilers Other Than f2c
@section Compilers Other Than @command{f2c}

On systems with Fortran compilers other than @command{f2c} and @command{g77},
code compiled by @command{g77} is not expected to work
well with code compiled by the native compiler.
(This is true for @command{f2c}-compiled objects as well.)
Libraries compiled with the native compiler probably will have
to be recompiled with @command{g77} to be used with @command{g77}-compiled code.

Reasons for such incompatibilities include:

@itemize @bullet
@item
There might be differences in the way names of Fortran procedures
are translated for use in the system's object-file format.
For example, the statement @samp{CALL FOO} might be compiled
by @command{g77} to call a procedure the linker @command{ld} sees
given the name @samp{_foo_}, while the apparently corresponding
statement @samp{SUBROUTINE FOO} might be compiled by the
native compiler to define the linker-visible name @samp{_foo},
or @samp{_FOO_}, and so on.

@item
There might be subtle type mismatches which cause subroutine arguments
and function return values to get corrupted.

This is why simply getting @command{g77} to
transform procedure names the same way a native
compiler does is not usually a good idea---unless
some effort has been made to ensure that, aside
from the way the two compilers transform procedure
names, everything else about the way they generate
code for procedure interfaces is identical.

@item
Native compilers
use libraries of private I/O routines which will not be available
at link time unless you have the native compiler---and you would
have to explicitly ask for them.

For example, on the Sun you
would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
command.
@end itemize

@node Other Languages
@chapter Other Languages

@emph{Note: This portion of the documentation definitely needs a lot
of work!}

@menu
* Interoperating with C and C++::
@end menu

@node Interoperating with C and C++
@section Tools and advice for interoperating with C and C++

@cindex C, linking with
@cindex C++, linking with
@cindex linking with C
The following discussion assumes that you are running @command{g77} in @command{f2c}
compatibility mode, i.e.@: not using @option{-fno-f2c}.
It provides some
advice about quick and simple techniques for linking Fortran and C (or
C++), the most common requirement.
For the full story consult the
description of code generation.
@xref{Debugging and Interfacing}.

When linking Fortran and C, it's usually best to use @command{g77} to do
the linking so that the correct libraries are included (including the
maths one).
If you're linking with C++ you will want to add
@option{-lstdc++}, @option{-lg++} or whatever.
If you need to use another
driver program (or @command{ld} directly),
you can find out what linkage
options @command{g77} passes by running @samp{g77 -v}.

@menu
* C Interfacing Tools::
* C Access to Type Information::
* f2c Skeletons and Prototypes::
* C++ Considerations::
* Startup Code::
@end menu

@node C Interfacing Tools
@subsection C Interfacing Tools
@pindex f2c
@cindex cfortran.h
@cindex Netlib
Even if you don't actually use it as a compiler, @command{f2c} from
@uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
interfacing (linking) Fortran and C@.
@xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}.

To use @command{f2c} for this purpose you only need retrieve and
build the @file{src} directory from the distribution, consult the
@file{README} instructions there for machine-specifics, and install the
@command{f2c} program on your path.

Something else that might be useful is @samp{cfortran.h} from
@uref{ftp://zebra.desy.de/cfortran}.
This is a fairly general tool which
can be used to generate interfaces for calling in both directions
between Fortran and C@.
It can be used in @command{f2c} mode with
@command{g77}---consult its documentation for details.

@node C Access to Type Information
@subsection Accessing Type Information in C

@cindex types, Fortran/C
Generally, C code written to link with
@command{g77} code---calling and/or being
called from Fortran---should @samp{#include <g2c.h>} to define the C
versions of the Fortran types.
Don't assume Fortran @code{INTEGER} types
correspond to C @code{int}s, for instance; instead, declare them as
@code{integer}, a type defined by @file{g2c.h}.
@file{g2c.h} is installed where @command{gcc} will find it by
default, assuming you use a copy of @command{gcc} compatible with
@command{g77}, probably built at the same time as @command{g77}.

@node f2c Skeletons and Prototypes
@subsection Generating Skeletons and Prototypes with @command{f2c}

@pindex f2c
@cindex -fno-second-underscore
A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to
interface with an existing library---is to write a file (named, for
example, @file{fred.f}) of dummy Fortran
skeletons comprising just the declaration of the routine(s) and dummy
arguments plus @code{END} statements.
Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c}
into which you can edit
useful code, confident the calling sequence is correct, at least.
(There are some errors otherwise commonly made in generating C
interfaces with @command{f2c} conventions,
such as not using @code{doublereal}
as the return type of a @code{REAL} @code{FUNCTION}.)

@pindex ftnchek
@command{f2c} also can help with calling Fortran from C, using its
@option{-P} option to generate C prototypes appropriate for calling the
Fortran.@footnote{The files generated like this can also be used for
inter-unit consistency checking of dummy and actual arguments, although
the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
or @uref{ftp://ftp.dsm.fordham.edu} is
probably better for this purpose.}
If the Fortran code containing any
routines to be called from C is in file @file{joe.f}, use the command
@kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
prototype information.
@code{#include} this in the C which has to call
the Fortran routines to make sure you get it right.

@xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
between the way Fortran (including compilers like @command{g77}) and
C handle arrays.

@node C++ Considerations
@subsection C++ Considerations

@cindex C++
@command{f2c} can be used to generate suitable code for compilation with a
C++ system using the @option{-C++} option.
The important thing about linking @command{g77}-compiled
code with C++ is that the prototypes for the @command{g77}
routines must specify C linkage to avoid name mangling.
So, use an @samp{extern "C"} declaration.
@command{f2c}'s @option{-C++} option will take care
of this when generating skeletons or prototype files as above, and also
avoid clashes with C++ reserved words in addition to those in C@.

@node Startup Code
@subsection Startup Code

@cindex startup code
@cindex run-time, initialization
@cindex initialization, run-time
Unlike with some runtime systems,
it shouldn't be necessary
(unless there are bugs)
to use a Fortran main program unit to ensure the
runtime---specifically the I/O system---is initialized.

However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC},
either the @code{main} routine from the @file{libg2c} library must be used,
or the @code{f_setarg} routine
(new as of @code{egcs} version 1.1 and @command{g77} version 0.5.23)
must be called with the appropriate @code{argc} and @code{argv} arguments
prior to the program calling @code{GETARG} or @code{IARGC}.

To provide more flexibility for mixed-language programming
involving @command{g77} while allowing for shared libraries,
as of @code{egcs} version 1.1 and @command{g77} version 0.5.23,
@command{g77}'s @code{main} routine in @code{libg2c}
does the following, in order:

@enumerate
@item
Calls @code{f_setarg}
with the incoming @code{argc} and @code{argv} arguments,
in the same order as for @code{main} itself.

This sets up the command-line environment
for @code{GETARG} and @code{IARGC}.

@item
Calls @code{f_setsig} (with no arguments).

This sets up the signaling and exception environment.

@item
Calls @code{f_init} (with no arguments).

This initializes the I/O environment,
though that should not be necessary,
as all I/O functions in @code{libf2c}
are believed to call @code{f_init} automatically,
if necessary.

(A future version of @command{g77} might skip this explicit step,
to speed up normal exit of a program.)

@item
Arranges for @code{f_exit} to be called (with no arguments)
when the program exits.

This ensures that the I/O environment is properly shut down
before the program exits normally.
Otherwise, output buffers might not be fully flushed,
scratch files might not be deleted, and so on.

The simple way @code{main} does this is
to call @code{f_exit} itself after calling
@code{MAIN__} (in the next step).

However, this does not catch the cases where the program
might call @code{exit} directly,
instead of using the @code{EXIT} intrinsic
(implemented as @code{exit_} in @code{libf2c}).

So, @code{main} attempts to use
the operating environment's @code{onexit} or @code{atexit}
facility, if available,
to cause @code{f_exit} to be called automatically
upon any invocation of @code{exit}.

@item
Calls @code{MAIN__} (with no arguments).

This starts executing the Fortran main program unit for
the application.
(Both @command{g77} and @command{f2c} currently compile a main
program unit so that its global name is @code{MAIN__}.)

@item
If no @code{onexit} or @code{atexit} is provided by the system,
calls @code{f_exit}.

@item
Calls @code{exit} with a zero argument,
to signal a successful program termination.

@item
Returns a zero value to the caller,
to signal a successful program termination,
in case @code{exit} doesn't exit on the system.
@end enumerate

All of the above names are C @code{extern} names,
i.e.@: not mangled.

When using the @code{main} procedure provided by @command{g77}
without a Fortran main program unit,
you need to provide @code{MAIN__}
as the entry point for your C code.
(Make sure you link the object file that defines that
entry point with the rest of your program.)

To provide your own @code{main} procedure
in place of @command{g77}'s,
make sure you specify the object file defining that procedure
@emph{before} @option{-lg2c} on the @command{g77} command line.
Since the @option{-lg2c} option is implicitly provided,
this is usually straightforward.
(Use the @option{--verbose} option to see how and where
@command{g77} implicitly adds @option{-lg2c} in a command line
that will link the program.
Feel free to specify @option{-lg2c} explicitly,
as appropriate.)

However, when providing your own @code{main},
make sure you perform the appropriate tasks in the
appropriate order.
For example, if your @code{main} does not call @code{f_setarg},
make sure the rest of your application does not call
@code{GETARG} or @code{IARGC}.

And, if your @code{main} fails to ensure that @code{f_exit}
is called upon program exit,
some files might end up incompletely written,
some scratch files might be left lying around,
and some existing files being written might be left
with old data not properly truncated at the end.

Note that, generally, the @command{g77} operating environment
does not depend on a procedure named @code{MAIN__} actually
being called prior to any other @command{g77}-compiled code.
That is, @code{MAIN__} does not, itself,
set up any important operating-environment characteristics
upon which other code might depend.
This might change in future versions of @command{g77},
with appropriate notification in the release notes.

For more information, consult the source code for the above routines.
These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
@file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.

Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77}
uses to open-code (inline) references to @code{IARGC}.

@node Debugging and Interfacing
@chapter Debugging and Interfacing
@cindex debugging
@cindex interfacing
@cindex calling C routines
@cindex C routines calling Fortran
@cindex f2c compatibility

GNU Fortran currently generates code that is object-compatible with
the @command{f2c} converter.
Also, it avoids limitations in the current GBE, such as the
inability to generate a procedure with
multiple entry points, by generating code that is structured
differently (in terms of procedure names, scopes, arguments, and
so on) than might be expected.

As a result, writing code in other languages that calls on, is
called by, or shares in-memory data with @command{g77}-compiled code generally
requires some understanding of the way @command{g77} compiles code for
various constructs.

Similarly, using a debugger to debug @command{g77}-compiled
code, even if that debugger supports native Fortran debugging, generally
requires this sort of information.

This section describes some of the basic information on how
@command{g77} compiles code for constructs involving interfaces to other
languages and to debuggers.

@emph{Caution:} Much or all of this information pertains to only the current
release of @command{g77}, sometimes even to using certain compiler options
with @command{g77} (such as @option{-fno-f2c}).
Do not write code that depends on this
information without clearly marking said code as nonportable and
subject to review for every new release of @command{g77}.
This information
is provided primarily to make debugging of code generated by this
particular release of @command{g77} easier for the user, and partly to make
writing (generally nonportable) interface code easier.
Both of these
activities require tracking changes in new version of @command{g77} as they
are installed, because new versions can change the behaviors
described in this section.

@menu
* Main Program Unit::  How @command{g77} compiles a main program unit.
* Procedures::         How @command{g77} constructs parameter lists
                       for procedures.
* Functions::          Functions returning floating-point or character data.
* Names::              Naming of user-defined variables, procedures, etc.
* Common Blocks::      Accessing common variables while debugging.
* Local Equivalence Areas::  Accessing @code{EQUIVALENCE} while debugging.
* Complex Variables::  How @command{g77} performs complex arithmetic.
* Arrays::             Dealing with (possibly multi-dimensional) arrays.
* Adjustable Arrays::  Special consideration for adjustable arrays.
* Alternate Entry Points::  How @command{g77} implements alternate @code{ENTRY}.
* Alternate Returns::  How @command{g77} handles alternate returns.
* Assigned Statement Labels::  How @command{g77} handles @code{ASSIGN}.
* Run-time Library Errors::  Meanings of some @code{IOSTAT=} values.
@end menu

@node Main Program Unit
@section Main Program Unit (PROGRAM)
@cindex PROGRAM statement
@cindex statements, PROGRAM

When @command{g77} compiles a main program unit, it gives it the public
procedure name @code{MAIN__}.
The @code{libg2c} library has the actual @code{main()} procedure
as is typical of C-based environments, and
it is this procedure that performs some initial start-up
activity and then calls @code{MAIN__}.

Generally, @command{g77} and @code{libg2c} are designed so that you need not
include a main program unit written in Fortran in your program---it
can be written in C or some other language.
Especially for I/O handling, this is the case, although @command{g77} version 0.5.16
includes a bug fix for @code{libg2c} that solved a problem with using the
@code{OPEN} statement as the first Fortran I/O activity in a program
without a Fortran main program unit.

However, if you don't intend to use @command{g77} (or @command{f2c}) to compile
your main program unit---that is, if you intend to compile a @code{main()}
procedure using some other language---you should carefully
examine the code for @code{main()} in @code{libg2c}, found in the source
file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
might need to be done by your @code{main()} in order to provide the
Fortran environment your Fortran code is expecting.

@cindex @code{IArgC} intrinsic
@cindex intrinsics, @code{IArgC}
@cindex @code{GetArg} intrinsic
@cindex intrinsics, @code{GetArg}
For example, @code{libg2c}'s @code{main()} sets up the information used by
the @code{IARGC} and @code{GETARG} intrinsics.
Bypassing @code{libg2c}'s @code{main()}
without providing a substitute for this activity would mean
that invoking @code{IARGC} and @code{GETARG} would produce undefined
results.

@cindex debugging
@cindex main program unit, debugging
@cindex main()
@cindex MAIN__()
@cindex .gdbinit
When debugging, one implication of the fact that @code{main()}, which
is the place where the debugged program ``starts'' from the
debugger's point of view, is in @code{libg2c} is that you won't be
starting your Fortran program at a point you recognize as your
Fortran code.

The standard way to get around this problem is to set a break
point (a one-time, or temporary, break point will do) at
the entrance to @code{MAIN__}, and then run the program.
A convenient way to do so is to add the @command{gdb} command

@example
tbreak MAIN__
@end example

@noindent
to the file @file{.gdbinit} in the directory in which you're debugging
(using @command{gdb}).

After doing this, the debugger will see the current execution
point of the program as at the beginning of the main program
unit of your program.

Of course, if you really want to set a break point at some
other place in your program and just start the program
running, without first breaking at @code{MAIN__},
that should work fine.

@node Procedures
@section Procedures (SUBROUTINE and FUNCTION)
@cindex procedures
@cindex SUBROUTINE statement
@cindex statements, SUBROUTINE
@cindex FUNCTION statement
@cindex statements, FUNCTION
@cindex signature of procedures

Currently, @command{g77} passes arguments via reference---specifically,
by passing a pointer to the location in memory of a variable, array,
array element, a temporary location that holds the result of evaluating an
expression, or a temporary or permanent location that holds the value
of a constant.

Procedures that accept @code{CHARACTER} arguments are implemented by
@command{g77} so that each @code{CHARACTER} argument has two actual arguments.

The first argument occupies the expected position in the
argument list and has the user-specified name.
This argument
is a pointer to an array of characters, passed by the caller.

The second argument is appended to the end of the user-specified
calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
is the user-specified name.
This argument is of the C type @code{ftnlen}
(see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
is the number of characters the caller has allocated in the
array pointed to by the first argument.

A procedure will ignore the length argument if @samp{X} is not declared
@code{CHARACTER*(*)}, because for other declarations, it knows the
length.
Not all callers necessarily ``know'' this, however, which
is why they all pass the extra argument.

The contents of the @code{CHARACTER} argument are specified by the
address passed in the first argument (named after it).
The procedure can read or write these contents as appropriate.

When more than one @code{CHARACTER} argument is present in the argument
list, the length arguments are appended in the order
the original arguments appear.
So @samp{CALL FOO('HI','THERE')} is implemented in
C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77}
does not provide the trailing null bytes on the constant
strings (@command{f2c} does provide them, but they are unnecessary in
a Fortran environment, and you should not expect them to be
there).

Note that the above information applies to @code{CHARACTER} variables and
arrays @strong{only}.
It does @strong{not} apply to external @code{CHARACTER}
functions or to intrinsic @code{CHARACTER} functions.
That is, no second length argument is passed to @samp{FOO} in this case:

@example
CHARACTER X
EXTERNAL X
CALL FOO(X)
@end example

@noindent
Nor does @samp{FOO} expect such an argument in this case:

@example
SUBROUTINE FOO(X)
CHARACTER X
EXTERNAL X
@end example

Because of this implementation detail, if a program has a bug
such that there is disagreement as to whether an argument is
a procedure, and the type of the argument is @code{CHARACTER}, subtle
symptoms might appear.

@node Functions
@section Functions (FUNCTION and RETURN)
@cindex functions
@cindex FUNCTION statement
@cindex statements, FUNCTION
@cindex RETURN statement
@cindex statements, RETURN
@cindex return type of functions

@command{g77} handles in a special way functions that return the following
types:

@itemize @bullet
@item
@code{CHARACTER}
@item
@code{COMPLEX}
@item
@code{REAL(KIND=1)}
@end itemize

For @code{CHARACTER}, @command{g77} implements a subroutine (a C function
returning @code{void})
with two arguments prepended: @samp{__g77_result}, which the caller passes
as a pointer to a @code{char} array expected to hold the return value,
and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
specifying the length of the return value as declared in the calling
program.
For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
to determine the size of the array that @samp{__g77_result} points to;
otherwise, it ignores that argument.

For @code{COMPLEX}, when @option{-ff2c} is in
force, @command{g77} implements
a subroutine with one argument prepended: @samp{__g77_result}, which the
caller passes as a pointer to a variable of the type of the function.
The called function writes the return value into this variable instead
of returning it as a function value.
When @option{-fno-f2c} is in force,
@command{g77} implements a @code{COMPLEX} function as @command{gcc}'s
@samp{__complex__ float} or @samp{__complex__ double} function
(or an emulation thereof, when @option{-femulate-complex} is in effect),
returning the result of the function in the same way as @command{gcc} would.

For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements
a function that actually returns @code{REAL(KIND=2)} (typically
C's @code{double} type).
When @option{-fno-f2c} is in force, @code{REAL(KIND=1)}
functions return @code{float}.

@node Names
@section Names
@cindex symbol names
@cindex transforming symbol names

Fortran permits each implementation to decide how to represent
names as far as how they're seen in other contexts, such as debuggers
and when interfacing to other languages, and especially as far
as how casing is handled.

External names---names of entities that are public, or ``accessible'',
to all modules in a program---normally have an underscore (@samp{_})
appended by @command{g77},
to generate code that is compatible with @command{f2c}.
External names include names of Fortran things like common blocks,
external procedures (subroutines and functions, but not including
statement functions, which are internal procedures), and entry point
names.

However, use of the @option{-fno-underscoring} option
disables this kind of transformation of external names (though inhibiting
the transformation certainly improves the chances of colliding with
incompatible externals written in other languages---but that
might be intentional.

@cindex -fno-underscoring option
@cindex options, -fno-underscoring
@cindex -fno-second-underscore option
@cindex options, -fno-underscoring
When @option{-funderscoring} is in force, any name (external or local)
that already has at least one underscore in it is
implemented by @command{g77} by appending two underscores.
(This second underscore can be disabled via the
@option{-fno-second-underscore} option.)
External names are changed this way for @command{f2c} compatibility.
Local names are changed this way to avoid collisions with external names
that are different in the source code---@command{f2c} does the same thing, but
there's no compatibility issue there except for user expectations while
debugging.

For example:

@example
Max_Cost = 0
@end example

@cindex debugging
@noindent
Here, a user would, in the debugger, refer to this variable using the
name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
as described below).
(We hope to improve @command{g77} in this regard in the future---don't
write scripts depending on this behavior!
Also, consider experimenting with the @option{-fno-underscoring}
option to try out debugging without having to massage names by
hand like this.)

@command{g77} provides a number of command-line options that allow the user
to control how case mapping is handled for source files.
The default is the traditional UNIX model for Fortran compilers---names
are mapped to lower case.
Other command-line options can be specified to map names to upper
case, or to leave them exactly as written in the source file.

For example:

@example
Foo = 9.436
@end example

@noindent
Here, it is normally the case that the variable assigned will be named
@samp{foo}.
This would be the name to enter when using a debugger to
access the variable.

However, depending on the command-line options specified, the
name implemented by @command{g77} might instead be @samp{FOO} or even
@samp{Foo}, thus affecting how debugging is done.

Also:

@example
Call Foo
@end example

@noindent
This would normally call a procedure that, if it were in a separate C program,
be defined starting with the line:

@example
void foo_()
@end example

@noindent
However, @command{g77} command-line options could be used to change the casing
of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option
could be used to inhibit the appending of the underscore to the name.

@node Common Blocks
@section Common Blocks (COMMON)
@cindex common blocks
@cindex @code{COMMON} statement
@cindex statements, @code{COMMON}

@command{g77} names and lays out @code{COMMON} areas
the same way @command{f2c} does,
for compatibility with @command{f2c}.

@node Local Equivalence Areas
@section Local Equivalence Areas (EQUIVALENCE)
@cindex equivalence areas
@cindex local equivalence areas
@cindex EQUIVALENCE statement
@cindex statements, EQUIVALENCE

@command{g77} treats storage-associated areas involving a @code{COMMON}
block as explained in the section on common blocks.

A local @code{EQUIVALENCE} area is a collection of variables and arrays
connected to each other in any way via @code{EQUIVALENCE}, none of which are
listed in a @code{COMMON} statement.

(@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name
for @var{x} using a different method when more than one name was
in the list of names of entities placed at the beginning of the
array.
Though the documentation specified that the first name listed in
the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77}
in fact chose the name using a method that was so complicated,
it seemed easier to change it to an alphabetical sort than to describe the
previous method in the documentation.)

@node Complex Variables
@section Complex Variables (COMPLEX)
@cindex complex variables
@cindex imaginary part
@cindex COMPLEX statement
@cindex statements, COMPLEX

As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types
(and related intrinsics, constants, functions, and so on)
in a manner that
makes direct debugging involving these types in Fortran
language mode difficult.

Essentially, @command{g77} implements these types using an
internal construct similar to C's @code{struct}, at least
as seen by the @command{gcc} back end.

Currently, the back end, when outputting debugging info with
the compiled code for the assembler to digest, does not detect
these @code{struct} types as being substitutes for Fortran
complex.
As a result, the Fortran language modes of debuggers such as
@command{gdb} see these types as C @code{struct} types, which
they might or might not support.

Until this is fixed, switch to C language mode to work with
entities of @code{COMPLEX} type and then switch back to Fortran language
mode afterward.
(In @command{gdb}, this is accomplished via @samp{set lang c} and
either @samp{set lang fortran} or @samp{set lang auto}.)

@node Arrays
@section Arrays (DIMENSION)
@cindex DIMENSION statement
@cindex statements, DIMENSION
@cindex array ordering
@cindex ordering, array
@cindex column-major ordering
@cindex row-major ordering
@cindex arrays

Fortran uses ``column-major ordering'' in its arrays.
This differs from other languages, such as C, which use ``row-major ordering''.
The difference is that, with Fortran, array elements adjacent to
each other in memory differ in the @emph{first} subscript instead of
the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
whereas with row-major ordering it would follow @samp{A(5,10,19)}.

This consideration
affects not only interfacing with and debugging Fortran code,
it can greatly affect how code is designed and written, especially
when code speed and size is a concern.

Fortran also differs from C, a popular language for interfacing and
to support directly in debuggers, in the way arrays are treated.
In C, arrays are single-dimensional and have interesting relationships
to pointers, neither of which is true for Fortran.
As a result, dealing with Fortran arrays from within
an environment limited to C concepts can be challenging.

For example, accessing the array element @samp{A(5,10,20)} is easy enough
in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
are needed.
First, C would treat the A array as a single-dimension array.
Second, C does not understand low bounds for arrays as does Fortran.
Third, C assumes a low bound of zero (0), while Fortran defaults to a
low bound of one (1) and can supports an arbitrary low bound.
Therefore, calculations must be done
to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
calculations require knowing the dimensions of @samp{A}.

For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
@samp{A(5,10,20)} would be:

@example
  (5-2)
+ (10-1)*(11-2+1)
+ (20-0)*(11-2+1)*(21-1+1)
= 4293
@end example

@noindent
So the C equivalent in this case would be @samp{a[4293]}.

When using a debugger directly on Fortran code, the C equivalent
might not work, because some debuggers cannot understand the notion
of low bounds other than zero.  However, unlike @command{f2c}, @command{g77}
does inform the GBE that a multi-dimensional array (like @samp{A}
in the above example) is really multi-dimensional, rather than a
single-dimensional array, so at least the dimensionality of the array
is preserved.

Debuggers that understand Fortran should have no trouble with
nonzero low bounds, but for non-Fortran debuggers, especially
C debuggers, the above example might have a C equivalent of
@samp{a[4305]}.
This calculation is arrived at by eliminating the subtraction
of the lower bound in the first parenthesized expression on each
line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
Actually, the implication of
this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
but that @samp{a[20][10][5]} produces the equivalent of
@samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.

Come to think of it, perhaps
the behavior is due to the debugger internally compensating for
the lower bounds by offsetting the base address of @samp{a}, leaving
@samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
its first element as identified by subscripts equal to the
corresponding lower bounds).

You know, maybe nobody really needs to use arrays.

@node Adjustable Arrays
@section Adjustable Arrays (DIMENSION)
@cindex arrays, adjustable
@cindex adjustable arrays
@cindex arrays, automatic
@cindex automatic arrays
@cindex DIMENSION statement
@cindex statements, DIMENSION
@cindex dimensioning arrays
@cindex arrays, dimensioning

Adjustable and automatic arrays in Fortran require the implementation
(in this
case, the @command{g77} compiler) to ``memorize'' the expressions that
dimension the arrays each time the procedure is invoked.
This is so that subsequent changes to variables used in those
expressions, made during execution of the procedure, do not
have any effect on the dimensions of those arrays.

For example:

@example
REAL ARRAY(5)
DATA ARRAY/5*2/
CALL X(ARRAY, 5)
END
SUBROUTINE X(A, N)
DIMENSION A(N)
N = 20
PRINT *, N, A
END
@end example

@noindent
Here, the implementation should, when running the program, print something
like:

@example
20   2.  2.  2.  2.  2.
@end example

@noindent
Note that this shows that while the value of @samp{N} was successfully
changed, the size of the @samp{A} array remained at 5 elements.

To support this, @command{g77} generates code that executes before any user
code (and before the internally generated computed @code{GOTO} to handle
alternate entry points, as described below) that evaluates each
(nonconstant) expression in the list of subscripts for an
array, and saves the result of each such evaluation to be used when
determining the size of the array (instead of re-evaluating the
expressions).

So, in the above example, when @samp{X} is first invoked, code is
executed that copies the value of @samp{N} to a temporary.
And that same temporary serves as the actual high bound for the single
dimension of the @samp{A} array (the low bound being the constant 1).
Since the user program cannot (legitimately) change the value
of the temporary during execution of the procedure, the size
of the array remains constant during each invocation.

For alternate entry points, the code @command{g77} generates takes into
account the possibility that a dummy adjustable array is not actually
passed to the actual entry point being invoked at that time.
In that case, the public procedure implementing the entry point
passes to the master private procedure implementing all the
code for the entry points a @code{NULL} pointer where a pointer to that
adjustable array would be expected.
The @command{g77}-generated code
doesn't attempt to evaluate any of the expressions in the subscripts
for an array if the pointer to that array is @code{NULL} at run time in
such cases.
(Don't depend on this particular implementation
by writing code that purposely passes @code{NULL} pointers where the
callee expects adjustable arrays, even if you know the callee
won't reference the arrays---nor should you pass @code{NULL} pointers
for any dummy arguments used in calculating the bounds of such
arrays or leave undefined any values used for that purpose in
COMMON---because the way @command{g77} implements these things might
change in the future!)

@node Alternate Entry Points
@section Alternate Entry Points (ENTRY)
@cindex alternate entry points
@cindex entry points
@cindex ENTRY statement
@cindex statements, ENTRY

The GBE does not understand the general concept of
alternate entry points as Fortran provides via the ENTRY statement.
@command{g77} gets around this by using an approach to compiling procedures
having at least one @code{ENTRY} statement that is almost identical to the
approach used by @command{f2c}.
(An alternate approach could be used that
would probably generate faster, but larger, code that would also
be a bit easier to debug.)

Information on how @command{g77} implements @code{ENTRY} is provided for those
trying to debug such code.
The choice of implementation seems
unlikely to affect code (compiled in other languages) that interfaces
to such code.

@command{g77} compiles exactly one public procedure for the primary entry
point of a procedure plus each @code{ENTRY} point it specifies, as usual.
That is, in terms of the public interface, there is no difference
between

@example
SUBROUTINE X
END
SUBROUTINE Y
END
@end example

@noindent
and:

@example
SUBROUTINE X
ENTRY Y
END
@end example

The difference between the above two cases lies in the code compiled
for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
for the second case, an extra internal procedure is compiled.

For every Fortran procedure with at least one @code{ENTRY}
statement, @command{g77} compiles an extra procedure
named @samp{__g77_masterfun_@var{x}}, where @var{x} is
the name of the primary entry point (which, in the above case,
using the standard compiler options, would be @samp{x_} in C).

This extra procedure is compiled as a private procedure---that is,
a procedure not accessible by name to separately compiled modules.
It contains all the code in the program unit, including the code
for the primary entry point plus for every entry point.
(The code for each public procedure is quite short, and explained later.)

The extra procedure has some other interesting characteristics.

The argument list for this procedure is invented by @command{g77}.
It contains
a single integer argument named @samp{__g77_which_entrypoint},
passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
entry point index---0 for the primary entry point, 1 for the
first entry point (the first @code{ENTRY} statement encountered), 2 for
the second entry point, and so on.

It also contains, for functions returning @code{CHARACTER} and
(when @option{-ff2c} is in effect) @code{COMPLEX} functions,
and for functions returning different types among the
@code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
is expected at run time to contain a pointer to where to store
the result of the entry point.
For @code{CHARACTER} functions, this
storage area is an array of the appropriate number of characters;
for @code{COMPLEX} functions, it is the appropriate area for the return
type; for multiple-return-type functions, it is a union of all the supported return
types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
is not supported by @command{g77}).

For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
by yet another argument named @samp{__g77_length} that, at run time,
specifies the caller's expected length of the returned value.
Note that only @code{CHARACTER*(*)} functions and entry points actually
make use of this argument, even though it is always passed by
all callers of public @code{CHARACTER} functions (since the caller does not
generally know whether such a function is @code{CHARACTER*(*)} or whether
there are any other callers that don't have that information).

The rest of the argument list is the union of all the arguments
specified for all the entry points (in their usual forms, e.g.
@code{CHARACTER} arguments have extra length arguments, all appended at
the end of this list).
This is considered the ``master list'' of
arguments.

The code for this procedure has, before the code for the first
executable statement, code much like that for the following Fortran
statement:

@smallexample
       GOTO (100000,100001,100002), __g77_which_entrypoint
100000 @dots{}code for primary entry point@dots{}
100001 @dots{}code immediately following first ENTRY statement@dots{}
100002 @dots{}code immediately following second ENTRY statement@dots{}
@end smallexample

@noindent
(Note that invalid Fortran statement labels and variable names
are used in the above example to highlight the fact that it
represents code generated by the @command{g77} internals, not code to be
written by the user.)

It is this code that, when the procedure is called, picks which
entry point to start executing.

Getting back to the public procedures (@samp{x} and @samp{Y} in the original
example), those procedures are fairly simple.
Their interfaces
are just like they would be if they were self-contained procedures
(without @code{ENTRY}), of course, since that is what the callers
expect.
Their code consists of simply calling the private
procedure, described above, with the appropriate extra arguments
(the entry point index, and perhaps a pointer to a multiple-type-
return variable, local to the public procedure, that contains
all the supported returnable non-character types).
For arguments
that are not listed for a given entry point that are listed for
other entry points, and therefore that are in the ``master list''
for the private procedure, null pointers (in C, the @code{NULL} macro)
are passed.
Also, for entry points that are part of a multiple-type-
returning function, code is compiled after the call of the private
procedure to extract from the multi-type union the appropriate result,
depending on the type of the entry point in question, returning
that result to the original caller.

When debugging a procedure containing alternate entry points, you
can either set a break point on the public procedure itself (e.g.
a break point on @samp{X} or @samp{Y}) or on the private procedure that
contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
If you do the former, you should use the debugger's command to
``step into'' the called procedure to get to the actual code; with
the latter approach, the break point leaves you right at the
actual code, skipping over the public entry point and its call
to the private procedure (unless you have set a break point there
as well, of course).

Further, the list of dummy arguments that is visible when the
private procedure is active is going to be the expanded version
of the list for whichever particular entry point is active,
as explained above, and the way in which return values are
handled might well be different from how they would be handled
for an equivalent single-entry function.

@node Alternate Returns
@section Alternate Returns (SUBROUTINE and RETURN)
@cindex subroutines
@cindex alternate returns
@cindex SUBROUTINE statement
@cindex statements, SUBROUTINE
@cindex RETURN statement
@cindex statements, RETURN

Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
@samp{CALL X(*50)}) are implemented by @command{g77} as functions returning
the C @code{int} type.
The actual alternate-return arguments are omitted from the calling sequence.
Instead, the caller uses
the return value to do a rough equivalent of the Fortran
computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
function), and the callee just returns whatever integer
is specified in the @code{RETURN} statement for the subroutine
For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
by @samp{RETURN}
in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).

@node Assigned Statement Labels
@section Assigned Statement Labels (ASSIGN and GOTO)
@cindex assigned statement labels
@cindex statement labels, assigned
@cindex ASSIGN statement
@cindex statements, ASSIGN
@cindex GOTO statement
@cindex statements, GOTO

For portability to machines where a pointer (such as to a label,
which is how @command{g77} implements @code{ASSIGN} and its relatives,
the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77}
uses a different memory location to hold the @code{ASSIGN}ed value of a variable
than it does the numerical value in that variable, unless the
variable is wide enough (can hold enough bits).

In particular, while @command{g77} implements

@example
I = 10
@end example

@noindent
as, in C notation, @samp{i = 10;}, it implements

@example
ASSIGN 10 TO I
@end example

@noindent
as, in GNU's extended C notation (for the label syntax),
@samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't
actually generate the name @samp{L10} or any other name like that,
since debuggers cannot access labels anyway).

While this currently means that an @code{ASSIGN} statement does not
overwrite the numeric contents of its target variable, @emph{do not}
write any code depending on this feature.
@command{g77} has already changed this implementation across
versions and might do so in the future.
This information is provided only to make debugging Fortran programs
compiled with the current version of @command{g77} somewhat easier.
If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
in a program unit that does @samp{ASSIGN 10 TO I}, that probably
means @command{g77} has decided it can store the pointer to the label directly
into @samp{I} itself.

@xref{Ugly Assigned Labels}, for information on a command-line option
to force @command{g77} to use the same storage for both normal and
assigned-label uses of a variable.

@node Run-time Library Errors
@section Run-time Library Errors
@cindex IOSTAT=
@cindex error values
@cindex error messages
@cindex messages, run-time
@cindex I/O, errors

The @code{libg2c} library currently has the following table to relate
error code numbers, returned in @code{IOSTAT=} variables, to messages.
This information should, in future versions of this document, be
expanded upon to include detailed descriptions of each message.

In line with good coding practices, any of the numbers in the
list below should @emph{not} be directly written into Fortran
code you write.
Instead, make a separate @code{INCLUDE} file that defines
@code{PARAMETER} names for them, and use those in your code,
so you can more easily change the actual numbers in the future.

The information below is culled from the definition
of @code{F_err} in @file{f/runtime/libI77/err.c} in the
@command{g77} source tree.

@smallexample
100: "error in format"
101: "illegal unit number"
102: "formatted io not allowed"
103: "unformatted io not allowed"
104: "direct io not allowed"
105: "sequential io not allowed"
106: "can't backspace file"
107: "null file name"
108: "can't stat file"
109: "unit not connected"
110: "off end of record"
111: "truncation failed in endfile"
112: "incomprehensible list input"
113: "out of free space"
114: "unit not connected"
115: "read unexpected character"
116: "bad logical input field"
117: "bad variable type"
118: "bad namelist name"
119: "variable not in namelist"
120: "no end record"
121: "variable count incorrect"
122: "subscript for scalar variable"
123: "invalid array section"
124: "substring out of bounds"
125: "subscript out of bounds"
126: "can't read file"
127: "can't write file"
128: "'new' file exists"
129: "can't append to file"
130: "non-positive record number"
131: "I/O started while already doing I/O"
@end smallexample

@node Collected Fortran Wisdom
@chapter Collected Fortran Wisdom
@cindex wisdom
@cindex legacy code
@cindex code, legacy
@cindex writing code
@cindex code, writing

Most users of @command{g77} can be divided into two camps:

@itemize @bullet
@item
Those writing new Fortran code to be compiled by @command{g77}.

@item
Those using @command{g77} to compile existing, ``legacy'' code.
@end itemize

Users writing new code generally understand most of the necessary
aspects of Fortran to write ``mainstream'' code, but often need
help deciding how to handle problems, such as the construction
of libraries containing @code{BLOCK DATA}.

Users dealing with ``legacy'' code sometimes don't have much
experience with Fortran, but believe that the code they're compiling
already works when compiled by other compilers (and might
not understand why, as is sometimes the case, it doesn't work
when compiled by @command{g77}).

The following information is designed to help users do a better job
coping with existing, ``legacy'' Fortran code, and with writing
new code as well.

@menu
* Advantages Over f2c::        If @command{f2c} is so great, why @command{g77}?
* Block Data and Libraries::   How @command{g77} solves a common problem.
* Loops::                      Fortran @code{DO} loops surprise many people.
* Working Programs::           Getting programs to work should be done first.
* Overly Convenient Options::  Temptations to avoid, habits to not form.
* Faster Programs::            Everybody wants these, but at what cost?
@end menu

@node Advantages Over f2c
@section Advantages Over f2c

Without @command{f2c}, @command{g77} would have taken much longer to
do and probably not been as good for quite a while.
Sometimes people who notice how much @command{g77} depends on, and
documents encouragement to use, @command{f2c} ask why @command{g77}
was created if @command{f2c} already existed.

This section gives some basic answers to these questions, though it
is not intended to be comprehensive.

@menu
* Language Extensions::  Features used by Fortran code.
* Diagnostic Abilities:: Abilities to spot problems early.
* Compiler Options::     Features helpful to accommodate legacy code, etc.
* Compiler Speed::       Speed of the compilation process.
* Program Speed::        Speed of the generated, optimized code.
* Ease of Debugging::    Debugging ease-of-use at the source level.
* Character and Hollerith Constants::  A byte saved is a byte earned.
@end menu

@node Language Extensions
@subsection Language Extensions

@command{g77} offers several extensions to FORTRAN 77 language that @command{f2c}
doesn't:

@itemize @bullet
@item
Automatic arrays

@item
@code{CYCLE} and @code{EXIT}

@item
Construct names

@item
@code{SELECT CASE}

@item
@code{KIND=} and @code{LEN=} notation

@item
Semicolon as statement separator

@item
Constant expressions in @code{FORMAT} statements
(such as @samp{FORMAT(I<J>)},
where @samp{J} is a @code{PARAMETER} named constant)

@item
@code{MvBits} intrinsic

@item
@code{libU77} (Unix-compatibility) library,
with routines known to compiler as intrinsics
(so they work even when compiler options are used
to change the interfaces used by Fortran routines)
@end itemize

@command{g77} also implements iterative @code{DO} loops
so that they work even in the presence of certain ``extreme'' inputs,
unlike @command{f2c}.
@xref{Loops}.

However, @command{f2c} offers a few that @command{g77} doesn't, such as:

@itemize @bullet
@item
Intrinsics in @code{PARAMETER} statements

@item
Array bounds expressions (such as @samp{REAL M(N(2))})

@item
@code{AUTOMATIC} statement
@end itemize

It is expected that @command{g77} will offer some or all of these missing
features at some time in the future.

@node Diagnostic Abilities
@subsection Diagnostic Abilities

@command{g77} offers better diagnosis of problems in @code{FORMAT} statements.
@command{f2c} doesn't, for example, emit any diagnostic for
@samp{FORMAT(XZFAJG10324)},
leaving that to be diagnosed, at run time, by
the @code{libf2c} run-time library.

@node Compiler Options
@subsection Compiler Options

@command{g77} offers compiler options that @command{f2c} doesn't,
most of which are designed to more easily accommodate
legacy code:

@itemize @bullet
@item
Two that control the automatic appending of extra
underscores to external names

@item
One that allows dollar signs (@samp{$}) in symbol names

@item
A variety that control acceptance of various
``ugly'' constructs

@item
Several that specify acceptable use of upper and lower case
in the source code

@item
Many that enable, disable, delete, or hide
groups of intrinsics

@item
One to specify the length of fixed-form source lines
(normally 72)

@item
One to specify the the source code is written in
Fortran-90-style free-form
@end itemize

However, @command{f2c} offers a few that @command{g77} doesn't,
like an option to have @code{REAL} default to @code{REAL*8}.
It is expected that @command{g77} will offer all of the
missing options pertinent to being a Fortran compiler
at some time in the future.

@node Compiler Speed
@subsection Compiler Speed

Saving the steps of writing and then rereading C code is a big reason
why @command{g77} should be able to compile code much faster than using
@command{f2c} in conjunction with the equivalent invocation of @command{gcc}.

However, due to @command{g77}'s youth, lots of self-checking is still being
performed.
As a result, this improvement is as yet unrealized
(though the potential seems to be there for quite a big speedup
in the future).
It is possible that, as of version 0.5.18, @command{g77}
is noticeably faster compiling many Fortran source files than using
@command{f2c} in conjunction with @command{gcc}.

@node Program Speed
@subsection Program Speed

@command{g77} has the potential to better optimize code than @command{f2c},
even when @command{gcc} is used to compile the output of @command{f2c},
because @command{f2c} must necessarily
translate Fortran into a somewhat lower-level language (C) that cannot
preserve all the information that is potentially useful for optimization,
while @command{g77} can gather, preserve, and transmit that information directly
to the GBE.

For example, @command{g77} implements @code{ASSIGN} and assigned
@code{GOTO} using direct assignment of pointers to labels and direct
jumps to labels, whereas @command{f2c} maps the assigned labels to
integer values and then uses a C @code{switch} statement to encode
the assigned @code{GOTO} statements.

However, as is typical, theory and reality don't quite match, at least
not in all cases, so it is still the case that @command{f2c} plus @command{gcc}
can generate code that is faster than @command{g77}.

Version 0.5.18 of @command{g77} offered default
settings and options, via patches to the @command{gcc}
back end, that allow for better program speed, though
some of these improvements also affected the performance
of programs translated by @command{f2c} and then compiled
by @command{g77}'s version of @command{gcc}.

Version 0.5.20 of @command{g77} offers further performance
improvements, at least one of which (alias analysis) is
not generally applicable to @command{f2c} (though @command{f2c}
could presumably be changed to also take advantage of
this new capability of the @command{gcc} back end, assuming
this is made available in an upcoming release of @command{gcc}).

@node Ease of Debugging
@subsection Ease of Debugging

Because @command{g77} compiles directly to assembler code like @command{gcc},
instead of translating to an intermediate language (C) as does @command{f2c},
support for debugging can be better for @command{g77} than @command{f2c}.

However, although @command{g77} might be somewhat more ``native'' in terms of
debugging support than @command{f2c} plus @command{gcc}, there still are a lot
of things ``not quite right''.
Many of the important ones should be resolved in the near future.

For example, @command{g77} doesn't have to worry about reserved names
like @command{f2c} does.
Given @samp{FOR = WHILE}, @command{f2c} must necessarily
translate this to something @emph{other} than
@samp{for = while;}, because C reserves those words.

However, @command{g77} does still uses things like an extra level of indirection
for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
yet support multiple entry points.

Another example is that, given

@smallexample
COMMON A, B
EQUIVALENCE (B, C)
@end smallexample

@noindent
the @command{g77} user should be able to access the variables directly, by name,
without having to traverse C-like structures and unions, while @command{f2c}
is unlikely to ever offer this ability (due to limitations in the
C language).

However, due to apparent bugs in the back end, @command{g77} currently doesn't
take advantage of this facility at all---it doesn't emit any debugging
information for @code{COMMON} and @code{EQUIVALENCE} areas,
other than information
on the array of @code{char} it creates (and, in the case
of local @code{EQUIVALENCE}, names) for each such area.

Yet another example is arrays.
@command{g77} represents them to the debugger
using the same ``dimensionality'' as in the source code, while @command{f2c}
must necessarily convert them all to one-dimensional arrays to fit
into the confines of the C language.
However, the level of support
offered by debuggers for interactive Fortran-style access to arrays
as compiled by @command{g77} can vary widely.
In some cases, it can actually
be an advantage that @command{f2c} converts everything to widely supported
C semantics.

In fairness, @command{g77} could do many of the things @command{f2c} does
to get things working at least as well as @command{f2c}---for now,
the developers prefer making @command{g77} work the
way they think it is supposed to, and finding help improving the
other products (the back end of @command{gcc}; @command{gdb}; and so on)
to get things working properly.

@node Character and Hollerith Constants
@subsection Character and Hollerith Constants
@cindex character constants
@cindex constants, character
@cindex Hollerith constants
@cindex constants, Hollerith
@cindex trailing null byte
@cindex null byte, trailing
@cindex zero byte, trailing

To avoid the extensive hassle that would be needed to avoid this,
@command{f2c} uses C character constants to encode character and Hollerith
constants.
That means a constant like @samp{'HELLO'} is translated to
@samp{"hello"} in C, which further means that an extra null byte is
present at the end of the constant.
This null byte is superfluous.

@command{g77} does not generate such null bytes.
This represents significant
savings of resources, such as on systems where @file{/dev/null} or
@file{/dev/zero} represent bottlenecks in the systems' performance,
because @command{g77} simply asks for fewer zeros from the operating
system than @command{f2c}.
(Avoiding spurious use of zero bytes, each byte typically have
eight zero bits, also reduces the liabilities in case
Microsoft's rumored patent on the digits 0 and 1 is upheld.)

@node Block Data and Libraries
@section Block Data and Libraries
@cindex block data and libraries
@cindex BLOCK DATA statement
@cindex statements, BLOCK DATA
@cindex libraries, containing BLOCK DATA
@cindex f2c compatibility
@cindex compatibility, f2c

To ensure that block data program units are linked, especially a concern
when they are put into libraries, give each one a name (as in
@samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
statement in every program unit that uses any common block
initialized by the corresponding @code{BLOCK DATA}.
@command{g77} currently compiles a @code{BLOCK DATA} as if it were a
@code{SUBROUTINE},
that is, it generates an actual procedure having the appropriate name.
The procedure does nothing but return immediately if it happens to be
called.
For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO}
in the program and ensures that by generating a
reference to it so the linker will make sure it is present.
(Specifically, @command{g77} outputs in the data section a static pointer to the
external name @samp{FOO}.)

The implementation @command{g77} currently uses to make this work is
one of the few things not compatible with @command{f2c} as currently
shipped.
@command{f2c} currently does nothing with @samp{EXTERNAL FOO} except
issue a warning that @samp{FOO} is not otherwise referenced,
and, for @samp{BLOCK DATA FOO},
@command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
The upshot is that you shouldn't mix @command{f2c} and @command{g77} in
this particular case.
If you use @command{f2c} to compile @samp{BLOCK DATA FOO},
then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO}
will result in an unresolved reference when linked.
If you do the
opposite, then @samp{FOO} might not be linked in under various
circumstances (such as when @samp{FOO} is in a library, or you're
using a ``clever'' linker---so clever, it produces a broken program
with little or no warning by omitting initializations of global data
because they are contained in unreferenced procedures).

The changes you make to your code to make @command{g77} handle this situation,
however, appear to be a widely portable way to handle it.
That is, many systems permit it (as they should, since the
FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
is a block data program unit), and of the ones
that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
program units.

Here is the recommended approach to modifying a program containing
a program unit such as the following:

@smallexample
BLOCK DATA FOO
COMMON /VARS/ X, Y, Z
DATA X, Y, Z / 3., 4., 5. /
END
@end smallexample

@noindent
If the above program unit might be placed in a library module, then
ensure that every program unit in every program that references that
particular @code{COMMON} area uses the @code{EXTERNAL} statement
to force the area to be initialized.

For example, change a program unit that starts with

@smallexample
INTEGER FUNCTION CURX()
COMMON /VARS/ X, Y, Z
CURX = X
END
@end smallexample

@noindent
so that it uses the @code{EXTERNAL} statement, as in:

@smallexample
INTEGER FUNCTION CURX()
COMMON /VARS/ X, Y, Z
EXTERNAL FOO
CURX = X
END
@end smallexample

@noindent
That way, @samp{CURX} is compiled by @command{g77} (and many other
compilers) so that the linker knows it must include @samp{FOO},
the @code{BLOCK DATA} program unit that sets the initial values
for the variables in @samp{VAR}, in the executable program.

@node Loops
@section Loops
@cindex DO statement
@cindex statements, DO
@cindex trips, number of
@cindex number of trips

The meaning of a @code{DO} loop in Fortran is precisely specified
in the Fortran standard@dots{}and is quite different from what
many programmers might expect.

In particular, Fortran iterative @code{DO} loops are implemented as if
the number of trips through the loop is calculated @emph{before}
the loop is entered.

The number of trips for a loop is calculated from the @var{start},
@var{end}, and @var{increment} values specified in a statement such as:

@smallexample
DO @var{iter} = @var{start}, @var{end}, @var{increment}
@end smallexample

@noindent
The trip count is evaluated using a fairly simple formula
based on the three values following the @samp{=} in the
statement, and it is that trip count that is effectively
decremented during each iteration of the loop.
If, at the beginning of an iteration of the loop, the
trip count is zero or negative, the loop terminates.
The per-loop-iteration modifications to @var{iter} are not
related to determining whether to terminate the loop.

There are two important things to remember about the trip
count:

@itemize @bullet
@item
It can be @emph{negative}, in which case it is
treated as if it was zero---meaning the loop is
not executed at all.

@item
The type used to @emph{calculate} the trip count
is the same type as @var{iter}, but the final
calculation, and thus the type of the trip
count itself, always is @code{INTEGER(KIND=1)}.
@end itemize

These two items mean that there are loops that cannot
be written in straightforward fashion using the Fortran @code{DO}.

For example, on a system with the canonical 32-bit two's-complement
implementation of @code{INTEGER(KIND=1)}, the following loop will not work:

@smallexample
DO I = -2000000000, 2000000000
@end smallexample

@noindent
Although the @var{start} and @var{end} values are well within
the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
The expected trip count is 40000000001, which is outside
the range of @code{INTEGER(KIND=1)} on many systems.

Instead, the above loop should be constructed this way:

@smallexample
I = -2000000000
DO
  IF (I .GT. 2000000000) EXIT
  @dots{}
  I = I + 1
END DO
@end smallexample

@noindent
The simple @code{DO} construct and the @code{EXIT} statement
(used to leave the innermost loop)
are F90 features that @command{g77} supports.

Some Fortran compilers have buggy implementations of @code{DO},
in that they don't follow the standard.
They implement @code{DO} as a straightforward translation
to what, in C, would be a @code{for} statement.
Instead of creating a temporary variable to hold the trip count
as calculated at run time, these compilers
use the iteration variable @var{iter} to control
whether the loop continues at each iteration.

The bug in such an implementation shows up when the
trip count is within the range of the type of @var{iter},
but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
exceeds that range.  For example:

@smallexample
DO I = 2147483600, 2147483647
@end smallexample

@noindent
A loop started by the above statement will work as implemented
by @command{g77}, but the use, by some compilers, of a
more C-like implementation akin to

@smallexample
for (i = 2147483600; i <= 2147483647; ++i)
@end smallexample

@noindent
produces a loop that does not terminate, because @samp{i}
can never be greater than 2147483647, since incrementing it
beyond that value overflows @samp{i}, setting it to -2147483648.
This is a large, negative number that still is less than 2147483647.

Another example of unexpected behavior of @code{DO} involves
using a nonintegral iteration variable @var{iter}, that is,
a @code{REAL} variable.
Consider the following program:

@smallexample
      DATA BEGIN, END, STEP /.1, .31, .007/
      DO 10 R = BEGIN, END, STEP
         IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
         PRINT *,R
10    CONTINUE
      PRINT *,'LAST = ',R
      IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
      END
@end smallexample

@noindent
A C-like view of @code{DO} would hold that the two ``exclamatory''
@code{PRINT} statements are never executed.
However, this is the output of running the above program
as compiled by @command{g77} on a GNU/Linux ix86 system:

@smallexample
 .100000001
 .107000001
 .114
 .120999999
 @dots{}
 .289000005
 .296000004
 .303000003
LAST =   .310000002
 .310000002 .LE.   .310000002!!
@end smallexample

Note that one of the two checks in the program turned up
an apparent violation of the programmer's expectation---yet,
the loop is correctly implemented by @command{g77}, in that
it has 30 iterations.
This trip count of 30 is correct when evaluated using
the floating-point representations for the @var{begin},
@var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
ix86 are used.
On other systems, an apparently more accurate trip count
of 31 might result, but, nevertheless, @command{g77} is
faithfully following the Fortran standard, and the result
is not what the author of the sample program above
apparently expected.
(Such other systems might, for different values in the @code{DATA}
statement, violate the other programmer's expectation,
for example.)

Due to this combination of imprecise representation
of floating-point values and the often-misunderstood
interpretation of @code{DO} by standard-conforming
compilers such as @command{g77}, use of @code{DO} loops
with @code{REAL} iteration
variables is not recommended.
Such use can be caught by specifying @option{-Wsurprising}.
@xref{Warning Options}, for more information on this
option.

@node Working Programs
@section Working Programs

Getting Fortran programs to work in the first place can be
quite a challenge---even when the programs already work on
other systems, or when using other compilers.

@command{g77} offers some facilities that might be useful for
tracking down bugs in such programs.

@menu
* Not My Type::
* Variables Assumed To Be Zero::
* Variables Assumed To Be Saved::
* Unwanted Variables::
* Unused Arguments::
* Surprising Interpretations of Code::
* Aliasing Assumed To Work::
* Output Assumed To Flush::
* Large File Unit Numbers::
* Floating-point precision::
* Inconsistent Calling Sequences::
@end menu

@node Not My Type
@subsection Not My Type
@cindex mistyped variables
@cindex variables, mistyped
@cindex mistyped functions
@cindex functions, mistyped
@cindex implicit typing

A fruitful source of bugs in Fortran source code is use, or
mis-use, of Fortran's implicit-typing feature, whereby the
type of a variable, array, or function is determined by the
first character of its name.

Simple cases of this include statements like @samp{LOGX=9.227},
without a statement such as @samp{REAL LOGX}.
In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
type, with the result of the assignment being that it is given
the value @samp{9}.

More involved cases include a function that is defined starting
with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
Any caller of this function that does not also declare @samp{IPS}
as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
is likely to assume it returns
@code{INTEGER}, or some other type, leading to invalid results
or even program crashes.

The @option{-Wimplicit} option might catch failures to
properly specify the types of
variables, arrays, and functions in the code.

However, in code that makes heavy use of Fortran's
implicit-typing facility, this option might produce so
many warnings about cases that are working, it would be
hard to find the one or two that represent bugs.
This is why so many experienced Fortran programmers strongly
recommend widespread use of the @code{IMPLICIT NONE} statement,
despite it not being standard FORTRAN 77, to completely turn
off implicit typing.
(@command{g77} supports @code{IMPLICIT NONE}, as do almost all
FORTRAN 77 compilers.)

Note that @option{-Wimplicit} catches only implicit typing of
@emph{names}.
It does not catch implicit typing of expressions such
as @samp{X**(2/3)}.
Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
is equivalent to @samp{X**0}, due to the way Fortran expressions
are given types and then evaluated.
(In this particular case, the programmer probably wanted
@samp{X**(2./3.)}.)

@node Variables Assumed To Be Zero
@subsection Variables Assumed To Be Zero
@cindex zero-initialized variables
@cindex variables, assumed to be zero
@cindex uninitialized variables

Many Fortran programs were developed on systems that provided
automatic initialization of all, or some, variables and arrays
to zero.
As a result, many of these programs depend, sometimes
inadvertently, on this behavior, though to do so violates
the Fortran standards.

You can ask @command{g77} for this behavior by specifying the
@option{-finit-local-zero} option when compiling Fortran code.
(You might want to specify @option{-fno-automatic} as well,
to avoid code-size inflation for non-optimized compilations.)

Note that a program that works better when compiled with the
@option{-finit-local-zero} option
is almost certainly depending on a particular system's,
or compiler's, tendency to initialize some variables to zero.
It might be worthwhile finding such cases and fixing them,
using techniques such as compiling with the @option{-O -Wuninitialized}
options using @command{g77}.

@node Variables Assumed To Be Saved
@subsection Variables Assumed To Be Saved
@cindex variables, retaining values across calls
@cindex saved variables
@cindex static variables

Many Fortran programs were developed on systems that
saved the values of all, or some, variables and arrays
across procedure calls.
As a result, many of these programs depend, sometimes
inadvertently, on being able to assign a value to a
variable, perform a @code{RETURN} to a calling procedure,
and, upon subsequent invocation, reference the previously
assigned variable to obtain the value.

They expect this despite not using the @code{SAVE} statement
to specify that the value in a variable is expected to survive
procedure returns and calls.
Depending on variables and arrays to retain values across
procedure calls without using @code{SAVE} to require it violates
the Fortran standards.

You can ask @command{g77} to assume @code{SAVE} is specified for all
relevant (local) variables and arrays by using the
@option{-fno-automatic} option.

Note that a program that works better when compiled with the
@option{-fno-automatic} option
is almost certainly depending on not having to use
the @code{SAVE} statement as required by the Fortran standard.
It might be worthwhile finding such cases and fixing them,
using techniques such as compiling with the @samp{-O -Wuninitialized}
options using @command{g77}.

@node Unwanted Variables
@subsection Unwanted Variables

The @option{-Wunused} option can find bugs involving
implicit typing, sometimes
more easily than using @option{-Wimplicit} in code that makes
heavy use of implicit typing.
An unused variable or array might indicate that the
spelling for its declaration is different from that of
its intended uses.

Other than cases involving typos, unused variables rarely
indicate actual bugs in a program.
However, investigating such cases thoroughly has, on occasion,
led to the discovery of code that had not been completely
written---where the programmer wrote declarations as needed
for the whole algorithm, wrote some or even most of the code
for that algorithm, then got distracted and forgot that the
job was not complete.

@node Unused Arguments
@subsection Unused Arguments
@cindex unused arguments
@cindex arguments, unused

As with unused variables, It is possible that unused arguments
to a procedure might indicate a bug.
Compile with @samp{-W -Wunused} option to catch cases of
unused arguments.

Note that @option{-W} also enables warnings regarding overflow
of floating-point constants under certain circumstances.

@node Surprising Interpretations of Code
@subsection Surprising Interpretations of Code

The @option{-Wsurprising} option can help find bugs involving
expression evaluation or in
the way @code{DO} loops with non-integral iteration variables
are handled.
Cases found by this option might indicate a difference of
interpretation between the author of the code involved, and
a standard-conforming compiler such as @command{g77}.
Such a difference might produce actual bugs.

In any case, changing the code to explicitly do what the
programmer might have expected it to do, so @command{g77} and
other compilers are more likely to follow the programmer's
expectations, might be worthwhile, especially if such changes
make the program work better.

@node Aliasing Assumed To Work
@subsection Aliasing Assumed To Work
@cindex -falias-check option
@cindex options, -falias-check
@cindex -fargument-alias option
@cindex options, -fargument-alias
@cindex -fargument-noalias option
@cindex options, -fargument-noalias
@cindex -fno-argument-noalias-global option
@cindex options, -fno-argument-noalias-global
@cindex aliasing
@cindex anti-aliasing
@cindex overlapping arguments
@cindex overlays
@cindex association, storage
@cindex storage association
@cindex scheduling of reads and writes
@cindex reads and writes, scheduling

The @option{-falias-check}, @option{-fargument-alias},
@option{-fargument-noalias},
and @option{-fno-argument-noalias-global} options,
introduced in version 0.5.20 and
@command{g77}'s version 2.7.2.2.f.2 of @command{gcc},
were withdrawn as of @command{g77} version 0.5.23
due to their not being supported by @command{gcc} version 2.8.

These options control the assumptions regarding aliasing
(overlapping) of writes and reads to main memory (core) made
by the @command{gcc} back end.

The information below still is useful, but applies to
only those versions of @command{g77} that support the
alias analysis implied by support for these options.

These options are effective only when compiling with @option{-O}
(specifying any level other than @option{-O0})
or with @option{-falias-check}.

The default for Fortran code is @option{-fargument-noalias-global}.
(The default for C code and code written in other C-based languages
is @option{-fargument-alias}.
These defaults apply regardless of whether you use @command{g77} or
@command{gcc} to compile your code.)

Note that, on some systems, compiling with @option{-fforce-addr} in
effect can produce more optimal code when the default aliasing
options are in effect (and when optimization is enabled).

If your program is not working when compiled with optimization,
it is possible it is violating the Fortran standards (77 and 90)
by relying on the ability to ``safely'' modify variables and
arrays that are aliased, via procedure calls, to other variables
and arrays, without using @code{EQUIVALENCE} to explicitly
set up this kind of aliasing.

(The FORTRAN 77 standard's prohibition of this sort of
overlap, generally referred to therein as ``storage
assocation'', appears in Sections 15.9.3.6.
This prohibition allows implementations, such as @command{g77},
to, for example, implement the passing of procedures and
even values in @code{COMMON} via copy operations into local,
perhaps more efficiently accessed temporaries at entry to a
procedure, and, where appropriate, via copy operations back
out to their original locations in memory at exit from that
procedure, without having to take into consideration the
order in which the local copies are updated by the code,
among other things.)

To test this hypothesis, try compiling your program with
the @option{-fargument-alias} option, which causes the
compiler to revert to assumptions essentially the same as
made by versions of @command{g77} prior to 0.5.20.

If the program works using this option, that strongly suggests
that the bug is in your program.
Finding and fixing the bug(s) should result in a program that
is more standard-conforming and that can be compiled by @command{g77}
in a way that results in a faster executable.

(You might want to try compiling with @option{-fargument-noalias},
a kind of half-way point, to see if the problem is limited to
aliasing between dummy arguments and @code{COMMON} variables---this
option assumes that such aliasing is not done, while still allowing
aliasing among dummy arguments.)

An example of aliasing that is invalid according to the standards
is shown in the following program, which might @emph{not} produce
the expected results when executed:

@smallexample
I = 1
CALL FOO(I, I)
PRINT *, I
END

SUBROUTINE FOO(J, K)
J = J + K
K = J * K
PRINT *, J, K
END
@end smallexample

The above program attempts to use the temporary aliasing of the
@samp{J} and @samp{K} arguments in @samp{FOO} to effect a
pathological behavior---the simultaneous changing of the values
of @emph{both} @samp{J} and @samp{K} when either one of them
is written.

The programmer likely expects the program to print these values:

@example
2  4
4
@end example

However, since the program is not standard-conforming, an
implementation's behavior when running it is undefined, because
subroutine @samp{FOO} modifies at least one of the arguments,
and they are aliased with each other.
(Even if one of the assignment statements was deleted, the
program would still violate these rules.
This kind of on-the-fly aliasing is permitted by the standard
only when none of the aliased items are defined, or written,
while the aliasing is in effect.)

As a practical example, an optimizing compiler might schedule
the @samp{J =} part of the second line of @samp{FOO} @emph{after}
the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
resulting in the following output:

@example
2  2
2
@end example

Essentially, compilers are promised (by the standard and, therefore,
by programmers who write code they claim to be standard-conforming)
that if they cannot detect aliasing via static analysis of a single
program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
such aliasing exists.
In such cases, compilers are free to assume that an assignment to
one variable will not change the value of another variable, allowing
it to avoid generating code to re-read the value of the other
variable, to re-schedule reads and writes, and so on, to produce
a faster executable.

The same promise holds true for arrays (as seen by the called
procedure)---an element of one dummy array cannot be aliased
with, or overlap, any element of another dummy array or be
in a @code{COMMON} area known to the procedure.

(These restrictions apply only when the procedure defines, or
writes to, one of the aliased variables or arrays.)

Unfortunately, there is no way to find @emph{all} possible cases of
violations of the prohibitions against aliasing in Fortran code.
Static analysis is certainly imperfect, as is run-time analysis,
since neither can catch all violations.
(Static analysis can catch all likely violations, and some that
might never actually happen, while run-time analysis can catch
only those violations that actually happen during a particular run.
Neither approach can cope with programs mixing Fortran code with
routines written in other languages, however.)

Currently, @command{g77} provides neither static nor run-time facilities
to detect any cases of this problem, although other products might.
Run-time facilities are more likely to be offered by future
versions of @command{g77}, though patches improving @command{g77} so that
it provides either form of detection are welcome.

@node Output Assumed To Flush
@subsection Output Assumed To Flush
@cindex ALWAYS_FLUSH
@cindex synchronous write errors
@cindex disk full
@cindex flushing output
@cindex fflush()
@cindex I/O, flushing
@cindex output, flushing
@cindex writes, flushing
@cindex NFS
@cindex network file system

For several versions prior to 0.5.20, @command{g77} configured its
version of the @code{libf2c} run-time library so that one of
its configuration macros, @code{ALWAYS_FLUSH}, was defined.

This was done as a result of a belief that many programs expected
output to be flushed to the operating system (under UNIX, via
the @code{fflush()} library call) with the result that errors,
such as disk full, would be immediately flagged via the
relevant @code{ERR=} and @code{IOSTAT=} mechanism.

Because of the adverse effects this approach had on the performance
of many programs, @command{g77} no longer configures @code{libf2c}
(now named @code{libg2c} in its @command{g77} incarnation)
to always flush output.

If your program depends on this behavior, either insert the
appropriate @samp{CALL FLUSH} statements, or modify the sources
to the @code{libg2c}, rebuild and reinstall @command{g77}, and
relink your programs with the modified library.

(Ideally, @code{libg2c} would offer the choice at run-time, so
that a compile-time option to @command{g77} or @command{f2c} could
result in generating the appropriate calls to flushing or
non-flushing library routines.)

Some Fortran programs require output
(writes) to be flushed to the operating system (under UNIX,
via the @code{fflush()} library call) so that errors,
such as disk full, are immediately flagged via the relevant
@code{ERR=} and @code{IOSTAT=} mechanism, instead of such
errors being flagged later as subsequent writes occur, forcing
the previously written data to disk, or when the file is
closed.

Essentially, the difference can be viewed as synchronous error
reporting (immediate flagging of errors during writes) versus
asynchronous, or, more precisely, buffered error reporting
(detection of errors might be delayed).

@code{libg2c} supports flagging write errors immediately when
it is built with the @code{ALWAYS_FLUSH} macro defined.
This results in a @code{libg2c} that runs slower, sometimes
quite a bit slower, under certain circumstances---for example,
accessing files via the networked file system NFS---but the
effect can be more reliable, robust file I/O.

If you know that Fortran programs requiring this level of precision
of error reporting are to be compiled using the
version of @command{g77} you are building, you might wish to
modify the @command{g77} source tree so that the version of
@code{libg2c} is built with the @code{ALWAYS_FLUSH} macro
defined, enabling this behavior.

To do this, find this line in @file{@value{path-libf2c}/f2c.h} in
your @command{g77} source tree:

@example
/* #define ALWAYS_FLUSH */
@end example

Remove the leading @samp{/*@w{ }},
so the line begins with @samp{#define},
and the trailing @samp{@w{ }*/}.

Then build or rebuild @command{g77} as appropriate.

@node Large File Unit Numbers
@subsection Large File Unit Numbers
@cindex MXUNIT
@cindex unit numbers
@cindex maximum unit number
@cindex illegal unit number
@cindex increasing maximum unit number

If your program crashes at run time with a message including
the text @samp{illegal unit number}, that probably is
a message from the run-time library, @code{libg2c}.

The message means that your program has attempted to use a
file unit number that is out of the range accepted by
@code{libg2c}.
Normally, this range is 0 through 99, and the high end
of the range is controlled by a @code{libg2c} source-file
macro named @code{MXUNIT}.

If you can easily change your program to use unit numbers
in the range 0 through 99, you should do so.

As distributed, whether as part of @command{f2c} or @command{g77},
@code{libf2c} accepts file unit numbers only in the range
0 through 99.
For example, a statement such as @samp{WRITE (UNIT=100)} causes
a run-time crash in @code{libf2c}, because the unit number,
100, is out of range.

If you know that Fortran programs at your installation require
the use of unit numbers higher than 99, you can change the
value of the @code{MXUNIT} macro, which represents the maximum unit
number, to an appropriately higher value.

To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your
@command{g77} source tree, changing the following line:

@example
#define MXUNIT 100
@end example

Change the line so that the value of @code{MXUNIT} is defined to be
at least one @emph{greater} than the maximum unit number used by
the Fortran programs on your system.

(For example, a program that does @samp{WRITE (UNIT=255)} would require
@code{MXUNIT} set to at least 256 to avoid crashing.)

Then build or rebuild @command{g77} as appropriate.

@emph{Note:} Changing this macro has @emph{no} effect on other limits
your system might place on the number of files open at the same time.
That is, the macro might allow a program to do @samp{WRITE (UNIT=100)},
but the library and operating system underlying @code{libf2c} might
disallow it if many other files have already been opened (via @code{OPEN} or
implicitly via @code{READ}, @code{WRITE}, and so on).
Information on how to increase these other limits should be found
in your system's documentation.

@node Floating-point precision
@subsection Floating-point precision

@cindex IEEE 754 conformance
@cindex conformance, IEEE 754
@cindex floating-point, precision
@cindex ix86 floating-point
@cindex x86 floating-point
If your program depends on exact IEEE 754 floating-point handling it may
help on some systems---specifically x86 or m68k hardware---to use
the @option{-ffloat-store} option or to reset the precision flag on the
floating-point unit.
@xref{Optimize Options}.

However, it might be better simply to put the FPU into double precision
mode and not take the performance hit of @option{-ffloat-store}.  On x86
and m68k GNU systems you can do this with a technique similar to that
for turning on floating-point exceptions
(@pxref{Floating-point Exception Handling}).
The control word could be set to double precision by some code like this
one:
@smallexample
#include <fpu_control.h>
@{
  fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
  _FPU_SETCW(cw);
@}
@end smallexample
(It is not clear whether this has any effect on the operation of the GNU
maths library, but we have no evidence of it causing trouble.)

Some targets (such as the Alpha) may need special options for full IEEE
conformance.
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using
the GNU Compiler Collection (GCC)}.

@node Inconsistent Calling Sequences
@subsection Inconsistent Calling Sequences

@pindex ftnchek
@cindex floating-point, errors
@cindex ix86 FPU stack
@cindex x86 FPU stack
Code containing inconsistent calling sequences in the same file is
normally rejected---see @ref{GLOBALS}.
(Use, say, @command{ftnchek} to ensure
consistency across source files.
@xref{f2c Skeletons and Prototypes,,
Generating Skeletons and Prototypes with @command{f2c}}.)

Mysterious errors, which may appear to be code generation problems, can
appear specifically on the x86 architecture with some such
inconsistencies.  On x86 hardware, floating-point return values of
functions are placed on the floating-point unit's register stack, not
the normal stack.  Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
@code{FUNCTION} as some other sort of procedure, or vice versa,
scrambles the floating-point stack.  This may break unrelated code
executed later.  Similarly if, say, external C routines are written
incorrectly.

@node Overly Convenient Options
@section Overly Convenient Command-line Options
@cindex overly convenient options
@cindex options, overly convenient

These options should be used only as a quick-and-dirty way to determine
how well your program will run under different compilation models
without having to change the source.
Some are more problematic
than others, depending on how portable and maintainable you want the
program to be (and, of course, whether you are allowed to change it
at all is crucial).

You should not continue to use these command-line options to compile
a given program, but rather should make changes to the source code:

@table @code
@cindex -finit-local-zero option
@cindex options, -finit-local-zero
@item -finit-local-zero
(This option specifies that any uninitialized local variables
and arrays have default initialization to binary zeros.)

Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.

It is safer (and probably
would produce a faster program) to find the variables and arrays that
need such initialization and provide it explicitly via @code{DATA}, so that
@option{-finit-local-zero} is not needed.

Consider using @option{-Wuninitialized} (which requires @option{-O}) to
find likely candidates, but
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
or this technique won't work.

@cindex -fno-automatic option
@cindex options, -fno-automatic
@item -fno-automatic
(This option specifies that all local variables and arrays
are to be treated as if they were named in @code{SAVE} statements.)

Many other compilers do this automatically, which means lots of
Fortran code developed with those compilers depends on it.

The effect of this is that all non-automatic variables and arrays
are made static, that is, not placed on the stack or in heap storage.
This might cause a buggy program to appear to work better.
If so, rather than relying on this command-line option (and hoping all
compilers provide the equivalent one), add @code{SAVE}
statements to some or all program unit sources, as appropriate.
Consider using @option{-Wuninitialized} (which requires @option{-O})
to find likely candidates, but
do not specify @option{-finit-local-zero} or @option{-fno-automatic},
or this technique won't work.

The default is @option{-fautomatic}, which tells @command{g77} to try
and put variables and arrays on the stack (or in fast registers)
where possible and reasonable.
This tends to make programs faster.

@cindex automatic arrays
@cindex arrays, automatic
@emph{Note:} Automatic variables and arrays are not affected
by this option.
These are variables and arrays that are @emph{necessarily} automatic,
either due to explicit statements, or due to the way they are
declared.
Examples include local variables and arrays not given the
@code{SAVE} attribute in procedures declared @code{RECURSIVE},
and local arrays declared with non-constant bounds (automatic
arrays).
Currently, @command{g77} supports only automatic arrays, not
@code{RECURSIVE} procedures or other means of explicitly
specifying that variables or arrays are automatic.

@cindex -f@var{group}-intrinsics-hide option
@cindex options, -f@var{group}-intrinsics-hide
@item -f@var{group}-intrinsics-hide
Change the source code to use @code{EXTERNAL} for any external procedure
that might be the name of an intrinsic.
It is easy to find these using @option{-f@var{group}-intrinsics-disable}.
@end table

@node Faster Programs
@section Faster Programs
@cindex speed, of programs
@cindex programs, speeding up

Aside from the usual @command{gcc} options, such as @option{-O},
@option{-ffast-math}, and so on, consider trying some of the
following approaches to speed up your program (once you get
it working).

@menu
* Aligned Data::
* Prefer Automatic Uninitialized Variables::
* Avoid f2c Compatibility::
* Use Submodel Options::
@end menu

@node Aligned Data
@subsection Aligned Data
@cindex alignment
@cindex data, aligned
@cindex stack, aligned
@cindex aligned data
@cindex aligned stack
@cindex Pentium optimizations
@cindex optimization, for Pentium

On some systems, such as those with Pentium Pro CPUs, programs
that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
might run much slower
than possible due to the compiler not aligning these 64-bit
values to 64-bit boundaries in memory.
(The effect also is present, though
to a lesser extent, on the 586 (Pentium) architecture.)

The Intel x86 architecture generally ensures that these programs will
work on all its implementations,
but particular implementations (such as Pentium Pro)
perform better with more strict alignment.
(Such behavior isn't unique to the Intel x86 architecture.)
Other architectures might @emph{demand} 64-bit alignment
of 64-bit data.

There are a variety of approaches to use to address this problem:

@itemize @bullet
@item
@cindex @code{COMMON} layout
@cindex layout of @code{COMMON} blocks
Order your @code{COMMON} and @code{EQUIVALENCE} areas such
that the variables and arrays with the widest alignment
guidelines come first.

For example, on most systems, this would mean placing
@code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
@code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
@code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
@code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
and @code{INTEGER(KIND=3)} entities.

The reason to use such placement is it makes it more likely
that your data will be aligned properly, without requiring
you to do detailed analysis of each aggregate (@code{COMMON}
and @code{EQUIVALENCE}) area.

Specifically, on systems where the above guidelines are
appropriate, placing @code{CHARACTER} entities before
@code{REAL(KIND=2)} entities can work just as well,
but only if the number of bytes occupied by the @code{CHARACTER}
entities is divisible by the recommended alignment for
@code{REAL(KIND=2)}.

By ordering the placement of entities in aggregate
areas according to the simple guidelines above, you
avoid having to carefully count the number of bytes
occupied by each entity to determine whether the
actual alignment of each subsequent entity meets the
alignment guidelines for the type of that entity.

If you don't ensure correct alignment of @code{COMMON} elements, the
compiler may be forced by some systems to violate the Fortran semantics by
adding padding to get @code{DOUBLE PRECISION} data properly aligned.
If the unfortunate practice is employed of overlaying different types of
data in the @code{COMMON} block, the different variants
of this block may become misaligned with respect to each other.
Even if your platform doesn't require strict alignment,
@code{COMMON} should be laid out as above for portability.
(Unfortunately the FORTRAN 77 standard didn't anticipate this
possible requirement, which is compiler-independent on a given platform.)

@item
@cindex -malign-double option
@cindex options, -malign-double
Use the (x86-specific) @option{-malign-double} option when compiling
programs for the Pentium and Pentium Pro architectures (called 586
and 686 in the @command{gcc} configuration subsystem).
The warning about this in the @command{gcc} manual isn't
generally relevant to Fortran,
but using it will force @code{COMMON} to be padded if necessary to align
@code{DOUBLE PRECISION} data.

When @code{DOUBLE PRECISION} data is forcibly aligned
in @code{COMMON} by @command{g77} due to specifying @option{-malign-double},
@command{g77} issues a warning about the need to
insert padding.

In this case, each and every program unit that uses
the same @code{COMMON} area
must specify the same layout of variables and their types
for that area
and be compiled with @option{-malign-double} as well.
@command{g77} will issue warnings in each case,
but as long as every program unit using that area
is compiled with the same warnings,
the resulting object files should work when linked together
unless the program makes additional assumptions about
@code{COMMON} area layouts that are outside the scope
of the FORTRAN 77 standard,
or uses @code{EQUIVALENCE} or different layouts
in ways that assume no padding is ever inserted by the compiler.

@item
Ensure that @file{crt0.o} or @file{crt1.o}
on your system guarantees a 64-bit
aligned stack for @code{main()}.
The recent one from GNU (@code{glibc2}) will do this on x86 systems,
but we don't know of any other x86 setups where it will be right.
Read your system's documentation to determine if
it is appropriate to upgrade to a more recent version
to obtain the optimal alignment.
@end itemize

Progress is being made on making this work
``out of the box'' on future versions of @command{g77},
@command{gcc}, and some of the relevant operating systems
(such as GNU/Linux).

@cindex alignment testing
@cindex testing alignment
A package that tests the degree to which a Fortran compiler
(such as @command{g77})
aligns 64-bit floating-point variables and arrays
is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.

@node Prefer Automatic Uninitialized Variables
@subsection Prefer Automatic Uninitialized Variables

If you're using @option{-fno-automatic} already, you probably
should change your code to allow compilation with @option{-fautomatic}
(the default), to allow the program to run faster.

Similarly, you should be able to use @option{-fno-init-local-zero}
(the default) instead of @option{-finit-local-zero}.
This is because it is rare that every variable affected by these
options in a given program actually needs to
be so affected.

For example, @option{-fno-automatic}, which effectively @code{SAVE}s
every local non-automatic variable and array, affects even things like
@code{DO} iteration
variables, which rarely need to be @code{SAVE}d, and this often reduces
run-time performances.
Similarly, @option{-fno-init-local-zero} forces such
variables to be initialized to zero---when @code{SAVE}d (such as when
@option{-fno-automatic}), this by itself generally affects only
startup time for a program, but when not @code{SAVE}d,
it can slow down the procedure every time it is called.

@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
for information on the @option{-fno-automatic} and
@option{-finit-local-zero} options and how to convert
their use into selective changes in your own code.

@node Avoid f2c Compatibility
@subsection Avoid f2c Compatibility
@cindex -fno-f2c option
@cindex options, -fno-f2c
@cindex @command{f2c} compatibility
@cindex compatibility, @command{f2c}

If you aren't linking with any code compiled using
@command{f2c}, try using the @option{-fno-f2c} option when
compiling @emph{all} the code in your program.
(Note that @code{libf2c} is @emph{not} an example of code
that is compiled using @command{f2c}---it is compiled by a C
compiler, typically @command{gcc}.)

@node Use Submodel Options
@subsection Use Submodel Options
@cindex submodels

Using an appropriate @option{-m} option to generate specific code for your
CPU may be worthwhile, though it may mean the executable won't run on
other versions of the CPU that don't support the same instruction set.
@xref{Submodel Options,,Hardware Models and Configurations,gcc,Using the
GNU Compiler Collection (GCC)}.  For instance on an x86 system the
compiler might have
been built---as shown by @samp{g77 -v}---for the target
@samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@.  In that case to
generate code best optimized for a Pentium you could use the option
@option{-march=pentium}.

For recent CPUs that don't have explicit support in the released version
of @command{gcc}, it @emph{might} still be possible to get improvements
with certain @option{-m} options.

@option{-fomit-frame-pointer} can help performance on x86 systems and
others.  It will, however, inhibit debugging on the systems on which it
is not turned on anyway by @option{-O}.

@node Trouble
@chapter Known Causes of Trouble with GNU Fortran
@cindex bugs, known
@cindex installation trouble
@cindex known causes of trouble

This section describes known problems that affect users of GNU Fortran.
Most of these are not GNU Fortran bugs per se---if they were, we would
fix them.
But the result for a user might be like the result of a bug.

Some of these problems are due to bugs in other software, some are
missing features that are too much work to add, and some are places
where people's opinions differ as to what is best.

To find out about major bugs discovered in the current release and
possible workarounds for them, see
@uref{ftp://alpha.gnu.org/g77.plan}.

(Note that some of this portion of the manual is lifted
directly from the @command{gcc} manual, with minor modifications
to tailor it to users of @command{g77}.
Anytime a bug seems to have more to do with the @command{gcc}
portion of @command{g77}, see
@ref{Trouble,,Known Causes of Trouble with GCC,
gcc,Using the GNU Compiler Collection (GCC)}.)

@menu
* But-bugs::         Bugs really in other programs or elsewhere.
* Known Bugs::       Bugs known to be in this version of @command{g77}.
* Missing Features:: Features we already know we want to add later.
* Disappointments::  Regrettable things we can't change.
* Non-bugs::         Things we think are right, but some others disagree.
* Warnings and Errors::  Which problems in your code get warnings,
                        and which get errors.
@end menu

@node But-bugs
@section Bugs Not In GNU Fortran
@cindex but-bugs

These are bugs to which the maintainers often have to reply,
``but that isn't a bug in @command{g77}@dots{}''.
Some of these already are fixed in new versions of other
software; some still need to be fixed; some are problems
with how @command{g77} is installed or is being used;
some are the result of bad hardware that causes software
to misbehave in sometimes bizarre ways;
some just cannot be addressed at this time until more
is known about the problem.

Please don't re-report these bugs to the @command{g77} maintainers---if
you must remind someone how important it is to you that the problem
be fixed, talk to the people responsible for the other products
identified below, but preferably only after you've tried the
latest versions of those products.
The @command{g77} maintainers have their hands full working on
just fixing and improving @command{g77}, without serving as a
clearinghouse for all bugs that happen to affect @command{g77}
users.

@xref{Collected Fortran Wisdom}, for information on behavior
of Fortran programs, and the programs that compile them, that
might be @emph{thought} to indicate bugs.

@menu
* Signal 11 and Friends::  Strange behavior by any software.
* Cannot Link Fortran Programs::  Unresolved references.
* Large Common Blocks::    Problems on older GNU/Linux systems.
* Debugger Problems::      When the debugger crashes.
* NeXTStep Problems::      Misbehaving executables.
* Stack Overflow::         More misbehaving executables.
* Nothing Happens::        Less behaving executables.
* Strange Behavior at Run Time::  Executables misbehaving due to
                            bugs in your program.
* Floating-point Errors::  The results look wrong, but@dots{}.
@end menu

@node Signal 11 and Friends
@subsection Signal 11 and Friends
@cindex signal 11
@cindex hardware errors

A whole variety of strange behaviors can occur when the
software, or the way you are using the software,
stresses the hardware in a way that triggers hardware bugs.
This might seem hard to believe, but it happens frequently
enough that there exist documents explaining in detail
what the various causes of the problems are, what
typical symptoms look like, and so on.

Generally these problems are referred to in this document
as ``signal 11'' crashes, because the Linux kernel, running
on the most popular hardware (the Intel x86 line), often
stresses the hardware more than other popular operating
systems.
When hardware problems do occur under GNU/Linux on x86
systems, these often manifest themselves as ``signal 11''
problems, as illustrated by the following diagnostic:

@smallexample
sh# @kbd{g77 myprog.f}
gcc: Internal compiler error: program f771 got fatal signal 11
sh#
@end smallexample

It is @emph{very} important to remember that the above
message is @emph{not} the only one that indicates a
hardware problem, nor does it always indicate a hardware
problem.

In particular, on systems other than those running the Linux
kernel, the message might appear somewhat or very different,
as it will if the error manifests itself while running a
program other than the @command{g77} compiler.
For example,
it will appear somewhat different when running your program,
when running Emacs, and so on.

How to cope with such problems is well beyond the scope
of this manual.

However, users of Linux-based systems (such as GNU/Linux)
should review @uref{http://www.bitwizard.nl/sig11/}, a source
of detailed information on diagnosing hardware problems,
by recognizing their common symptoms.

Users of other operating systems and hardware might
find this reference useful as well.
If you know of similar material for another hardware/software
combination, please let us know so we can consider including
a reference to it in future versions of this manual.

@node Cannot Link Fortran Programs
@subsection Cannot Link Fortran Programs
@cindex unresolved reference (various)
@cindex linking error for user code
@cindex code, user
@cindex @command{ld}, error linking user code
@cindex @command{ld}, can't find strange names
On some systems, perhaps just those with out-of-date (shared?)
libraries, unresolved-reference errors happen when linking @command{g77}-compiled
programs (which should be done using @command{g77}).

If this happens to you, try appending @option{-lc} to the command you
use to link the program, e.g. @samp{g77 foo.f -lc}.
@command{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
but it cannot also specify @option{-lc} because not all systems have a
file named @file{libc.a}.

It is unclear at this point whether there are legitimately installed
systems where @samp{-lg2c -lm} is insufficient to resolve code produced
by @command{g77}.

@cindex undefined reference (_main)
@cindex linking error, user code
@cindex @command{ld}, error linking user code
@cindex code, user
@cindex @command{ld}, can't find @samp{_main}
If your program doesn't link due to unresolved references to names
like @samp{_main}, make sure you're using the @command{g77} command to do the
link, since this command ensures that the necessary libraries are
loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc}
command to do the actual link.
(Use the @option{-v} option to discover
more about what actually happens when you use the @command{g77} and @command{gcc}
commands.)

Also, try specifying @option{-lc} as the last item on the @command{g77}
command line, in case that helps.

@node Large Common Blocks
@subsection Large Common Blocks
@cindex common blocks, large
@cindex large common blocks
@cindex linking, errors
@cindex @command{ld}, errors
@cindex errors, linker
On some older GNU/Linux systems, programs with common blocks larger
than 16MB cannot be linked without some kind of error
message being produced.

This is a bug in older versions of @command{ld}, fixed in
more recent versions of @code{binutils}, such as version 2.6.

@node Debugger Problems
@subsection Debugger Problems
@cindex @command{gdb}, support
@cindex support, @command{gdb}
There are some known problems when using @command{gdb} on code
compiled by @command{g77}.
Inadequate investigation as of the release of 0.5.16 results in not
knowing which products are the culprit, but @file{gdb-4.14} definitely
crashes when, for example, an attempt is made to print the contents
of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
machines, plus some others.
Attempts to access assumed-size arrays are
also known to crash recent versions of @command{gdb}.
(@command{gdb}'s Fortran support was done for a different compiler
and isn't properly compatible with @command{g77}.)

@node NeXTStep Problems
@subsection NeXTStep Problems
@cindex NeXTStep problems
@cindex bus error
@cindex segmentation violation
Developers of Fortran code on NeXTStep (all architectures) have to
watch out for the following problem when writing programs with
large, statically allocated (i.e. non-stack based) data structures
(common blocks, saved arrays).

Due to the way the native loader (@file{/bin/ld}) lays out
data structures in virtual memory, it is very easy to create an
executable wherein the @samp{__DATA} segment overlaps (has addresses in
common) with the @samp{UNIX STACK} segment.

This leads to all sorts of trouble, from the executable simply not
executing, to bus errors.
The NeXTStep command line tool @command{ebadexec} points to
the problem as follows:

@smallexample
% @kbd{/bin/ebadexec a.out}
/bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
STACK segment (truncated address = 0x400000 rounded size =
0x3c00000) of executable file: a.out
@end smallexample

(In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
stack segment.)

This can be cured by assigning the @samp{__DATA} segment
(virtual) addresses beyond the stack segment.
A conservative
estimate for this is from address 6000000 (hexadecimal) onwards---this
has always worked for me [Toon Moene]:

@smallexample
% @kbd{g77 -segaddr __DATA 6000000 test.f}
% @kbd{ebadexec a.out}
ebadexec: file: a.out appears to be executable
%
@end smallexample

Browsing through @file{@value{path-g77}/Makefile.in},
you will find that the @code{f771} program itself also has to be
linked with these flags---it has large statically allocated
data structures.
(Version 0.5.18 reduces this somewhat, but probably
not enough.)

(The above item was contributed by Toon Moene
(@email{toon@@moene.indiv.nluug.nl}).)

@node Stack Overflow
@subsection Stack Overflow
@cindex stack, overflow
@cindex segmentation violation
@command{g77} code might fail at runtime (probably with a ``segmentation
violation'') due to overflowing the stack.
This happens most often on systems with an environment
that provides substantially more heap space (for use
when arbitrarily allocating and freeing memory) than stack
space.

Often this can be cured by
increasing or removing your shell's limit on stack usage, typically
using @kbd{limit stacksize} (in @command{csh} and derivatives) or
@kbd{ulimit -s} (in @command{sh} and derivatives).

Increasing the allowed stack size might, however, require
changing some operating system or system configuration parameters.

You might be able to work around the problem by compiling with the
@option{-fno-automatic} option to reduce stack usage, probably at the
expense of speed.

@command{g77}, on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
@code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force
smaller-sized entities into static storage (saving
on stack space) or permit larger-sized entities to be put on the
stack (which can improve run-time performance, as it presents
more opportunities for the GBE to optimize the generated code).

@emph{Note:} Putting more variables and arrays on the stack
might cause problems due to system-dependent limits on stack size.
Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no
effect on automatic variables and arrays.
@xref{But-bugs}, for more information.
@emph{Note:} While @code{libg2c} places a limit on the range
of Fortran file-unit numbers, the underlying library and operating
system might impose different kinds of limits.
For example, some systems limit the number of files simultaneously
open by a running program.
Information on how to increase these limits should be found
in your system's documentation.

@cindex automatic arrays
@cindex arrays, automatic
However, if your program uses large automatic arrays
(for example, has declarations like @samp{REAL A(N)} where
@samp{A} is a local array and @samp{N} is a dummy or
@code{COMMON} variable that can have a large value),
neither use of @option{-fno-automatic},
nor changing the cut-off point for @command{g77} for using the stack,
will solve the problem by changing the placement of these
large arrays, as they are @emph{necessarily} automatic.

@command{g77} currently provides no means to specify that
automatic arrays are to be allocated on the heap instead
of the stack.
So, other than increasing the stack size, your best bet is to
change your source code to avoid large automatic arrays.
Methods for doing this currently are outside the scope of
this document.

(@emph{Note:} If your system puts stack and heap space in the
same memory area, such that they are effectively combined, then
a stack overflow probably indicates a program that is either
simply too large for the system, or buggy.)

@node Nothing Happens
@subsection Nothing Happens
@cindex nothing happens
@cindex naming programs
@cindex @command{test} programs
@cindex programs, @command{test}
It is occasionally reported that a ``simple'' program,
such as a ``Hello, World!'' program, does nothing when
it is run, even though the compiler reported no errors,
despite the program containing nothing other than a
simple @code{PRINT} statement.

This most often happens because the program has been
compiled and linked on a UNIX system and named @command{test},
though other names can lead to similarly unexpected
run-time behavior on various systems.

Essentially this problem boils down to giving
your program a name that is already known to
the shell you are using to identify some other program,
which the shell continues to execute instead of your
program when you invoke it via, for example:

@smallexample
sh# @kbd{test}
sh#
@end smallexample

Under UNIX and many other system, a simple command name
invokes a searching mechanism that might well not choose
the program located in the current working directory if
there is another alternative (such as the @command{test}
command commonly installed on UNIX systems).

The reliable way to invoke a program you just linked in
the current directory under UNIX is to specify it using
an explicit pathname, as in:

@smallexample
sh# @kbd{./test}
 Hello, World!
sh#
@end smallexample

Users who encounter this problem should take the time to
read up on how their shell searches for commands, how to
set their search path, and so on.
The relevant UNIX commands to learn about include
@command{man}, @command{info} (on GNU systems), @command{setenv} (or
@command{set} and @command{env}), @command{which}, and @command{find}.

@node Strange Behavior at Run Time
@subsection Strange Behavior at Run Time
@cindex segmentation violation
@cindex bus error
@cindex overwritten data
@cindex data, overwritten
@command{g77} code might fail at runtime with ``segmentation violation'',
``bus error'', or even something as subtle as a procedure call
overwriting a variable or array element that it is not supposed
to touch.

These can be symptoms of a wide variety of actual bugs that
occurred earlier during the program's run, but manifested
themselves as @emph{visible} problems some time later.

Overflowing the bounds of an array---usually by writing beyond
the end of it---is one of two kinds of bug that often occurs
in Fortran code.
(Compile your code with the @option{-fbounds-check} option
to catch many of these kinds of errors at program run time.)

The other kind of bug is a mismatch between the actual arguments
passed to a procedure and the dummy arguments as declared by that
procedure.

Both of these kinds of bugs, and some others as well, can be
difficult to track down, because the bug can change its behavior,
or even appear to not occur, when using a debugger.

That is, these bugs can be quite sensitive to data, including
data representing the placement of other data in memory (that is,
pointers, such as the placement of stack frames in memory).

@command{g77} now offers the
ability to catch and report some of these problems at compile, link, or
run time, such as by generating code to detect references to
beyond the bounds of most arrays (except assumed-size arrays),
and checking for agreement between calling and called procedures.
Future improvements are likely to be made in the procedure-mismatch area,
at least.

In the meantime, finding and fixing the programming
bugs that lead to these behaviors is, ultimately, the user's
responsibility, as difficult as that task can sometimes be.

@cindex infinite spaces printed
@cindex space, endless printing of
@cindex libc, non-ANSI or non-default
@cindex C library
@cindex linking against non-standard library
@cindex Solaris
One runtime problem that has been observed might have a simple solution.
If a formatted @code{WRITE} produces an endless stream of spaces, check
that your program is linked against the correct version of the C library.
The configuration process takes care to account for your
system's normal @file{libc} not being ANSI-standard, which will
otherwise cause this behavior.
If your system's default library is
ANSI-standard and you subsequently link against a non-ANSI one, there
might be problems such as this one.

Specifically, on Solaris2 systems,
avoid picking up the @code{BSD} library from @file{/usr/ucblib}.

@node Floating-point Errors
@subsection Floating-point Errors
@cindex floating-point errors
@cindex rounding errors
@cindex inconsistent floating-point results
@cindex results, inconsistent
Some programs appear to produce inconsistent floating-point
results compiled by @command{g77} versus by other compilers.

Often the reason for this behavior is the fact that floating-point
values are represented on almost all Fortran systems by
@emph{approximations}, and these approximations are inexact
even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
0.7, 0.8, 0.9, 1.1, and so on.
Most Fortran systems, including all current ports of @command{g77},
use binary arithmetic to represent these approximations.

Therefore, the exact value of any floating-point approximation
as manipulated by @command{g77}-compiled code is representable by
adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
so on (just keep dividing by two) through the precision of the
fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
@code{REAL(KIND=2)}), then multiplying the sum by a integral
power of two (in Fortran, by @samp{2**N}) that typically is between
-127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
@code{REAL(KIND=2)}, then multiplying by -1 if the number
is negative.

So, a value like 0.2 is exactly represented in decimal---since
it is a fraction, @samp{2/10}, with a denominator that is compatible
with the base of the number system (base 10).
However, @samp{2/10} cannot be represented by any finite number
of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
be exactly represented in binary notation.

(On the other hand, decimal notation can represent any binary
number in a finite number of digits.
Decimal notation cannot do so with ternary, or base-3,
notation, which would represent floating-point numbers as
sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
After all, no finite number of decimal digits can exactly
represent @samp{1/3}.
Fortunately, few systems use ternary notation.)

Moreover, differences in the way run-time I/O libraries convert
between these approximations and the decimal representation often
used by programmers and the programs they write can result in
apparent differences between results that do not actually exist,
or exist to such a small degree that they usually are not worth
worrying about.

For example, consider the following program:

@smallexample
PRINT *, 0.2
END
@end smallexample

When compiled by @command{g77}, the above program might output
@samp{0.20000003}, while another compiler might produce a
executable that outputs @samp{0.2}.

This particular difference is due to the fact that, currently,
conversion of floating-point values by the @code{libg2c} library,
used by @command{g77}, handles only double-precision values.

Since @samp{0.2} in the program is a single-precision value, it
is converted to double precision (still in binary notation)
before being converted back to decimal.
The conversion to binary appends @emph{binary} zero digits to the
original value---which, again, is an inexact approximation of
0.2---resulting in an approximation that is much less exact
than is connoted by the use of double precision.

(The appending of binary zero digits has essentially the same
effect as taking a particular decimal approximation of
@samp{1/3}, such as @samp{0.3333333}, and appending decimal
zeros to it, producing @samp{0.33333330000000000}.
Treating the resulting decimal approximation as if it really
had 18 or so digits of valid precision would make it seem
a very poor approximation of @samp{1/3}.)

As a result of converting the single-precision approximation
to double precision by appending binary zeros, the conversion
of the resulting double-precision
value to decimal produces what looks like an incorrect
result, when in fact the result is @emph{inexact}, and
is probably no less inaccurate or imprecise an approximation
of 0.2 than is produced by other compilers that happen to output
the converted value as ``exactly'' @samp{0.2}.
(Some compilers behave in a way that can make them appear
to retain more accuracy across a conversion of a single-precision
constant to double precision.
@xref{Context-Sensitive Constants}, to see why
this practice is illusory and even dangerous.)

Note that a more exact approximation of the constant is
computed when the program is changed to specify a
double-precision constant:

@smallexample
PRINT *, 0.2D0
END
@end smallexample

Future versions of @command{g77} and/or @code{libg2c} might convert
single-precision values directly to decimal,
instead of converting them to double precision first.
This would tend to result in output that is more consistent
with that produced by some other Fortran implementations.

A useful source of information on floating-point computation is David
Goldberg, `What Every Computer Scientist Should Know About
Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
5-48.
An online version is available at
@uref{http://docs.sun.com/},
and there is a supplemented version, in PostScript form, at
@uref{http://www.validgh.com/goldberg/paper.ps}.

Information related to the IEEE 754
floating-point standard by a leading light can be found at
@uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
see also slides from the short course referenced from
@uref{http://http.cs.berkeley.edu/%7Efateman/}.
@uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
and library code for GNU/Linux x86 systems.

The supplement to the PostScript-formatted Goldberg document,
referenced above, is available in HTML format.
See `Differences Among IEEE 754 Implementations' by Doug Priest,
available online at
@uref{http://www.validgh.com/goldberg/addendum.html}.
This document explores some of the issues surrounding computing
of extended (80-bit) results on processors such as the x86,
especially when those results are arbitrarily truncated
to 32-bit or 64-bit values by the compiler
as ``spills''.

@cindex spills of floating-point results
@cindex 80-bit spills
@cindex truncation, of floating-point values
(@emph{Note:} @command{g77} specifically, and @command{gcc} generally,
does arbitrarily truncate 80-bit results during spills
as of this writing.
It is not yet clear whether a future version of
the GNU compiler suite will offer 80-bit spills
as an option, or perhaps even as the default behavior.)

@c xref would be different between editions:
The GNU C library provides routines for controlling the FPU, and other
documentation about this.

@xref{Floating-point precision}, regarding IEEE 754 conformance.

@include bugs.texi

@node Missing Features
@section Missing Features

This section lists features we know are missing from @command{g77},
and which we want to add someday.
(There is no priority implied in the ordering below.)

@menu
GNU Fortran language:
* Better Source Model::
* Fortran 90 Support::
* Intrinsics in PARAMETER Statements::
* Arbitrary Concatenation::
* SELECT CASE on CHARACTER Type::
* RECURSIVE Keyword::
* Popular Non-standard Types::
* Full Support for Compiler Types::
* Array Bounds Expressions::
* POINTER Statements::
* Sensible Non-standard Constructs::
* READONLY Keyword::
* FLUSH Statement::
* Expressions in FORMAT Statements::
* Explicit Assembler Code::
* Q Edit Descriptor::

GNU Fortran dialects:
* Old-style PARAMETER Statements::
* TYPE and ACCEPT I/O Statements::
* STRUCTURE UNION RECORD MAP::
* OPEN CLOSE and INQUIRE Keywords::
* ENCODE and DECODE::
* AUTOMATIC Statement::
* Suppressing Space Padding::
* Fortran Preprocessor::
* Bit Operations on Floating-point Data::
* Really Ugly Character Assignments::

New facilities:
* POSIX Standard::
* Floating-point Exception Handling::
* Nonportable Conversions::
* Large Automatic Arrays::
* Support for Threads::
* Increasing Precision/Range::
* Enabling Debug Lines::

Better diagnostics:
* Better Warnings::
* Gracefully Handle Sensible Bad Code::
* Non-standard Conversions::
* Non-standard Intrinsics::
* Modifying DO Variable::
* Better Pedantic Compilation::
* Warn About Implicit Conversions::
* Invalid Use of Hollerith Constant::
* Dummy Array Without Dimensioning Dummy::
* Invalid FORMAT Specifiers::
* Ambiguous Dialects::
* Unused Labels::
* Informational Messages::

Run-time facilities:
* Uninitialized Variables at Run Time::
* Portable Unformatted Files::
* Better List-directed I/O::
* Default to Console I/O::

Debugging:
* Labels Visible to Debugger::
@end menu

@node Better Source Model
@subsection Better Source Model

@command{g77} needs to provide, as the default source-line model,
a ``pure visual'' mode, where
the interpretation of a source program in this mode can be accurately
determined by a user looking at a traditionally displayed rendition
of the program (assuming the user knows whether the program is fixed
or free form).

The design should assume the user cannot tell tabs from spaces
and cannot see trailing spaces on lines, but has canonical tab stops
and, for fixed-form source, has the ability to always know exactly
where column 72 is (since the Fortran standard itself requires
this for fixed-form source).

This would change the default treatment of fixed-form source
to not treat lines with tabs as if they were infinitely long---instead,
they would end at column 72 just as if the tabs were replaced
by spaces in the canonical way.

As part of this, provide common alternate models (Digital, @command{f2c},
and so on) via command-line options.
This includes allowing arbitrarily long
lines for free-form source as well as fixed-form source and providing
various limits and diagnostics as appropriate.

@cindex sequence numbers
@cindex columns 73 through 80
Also, @command{g77} should offer, perhaps even default to, warnings
when characters beyond the last valid column are anything other
than spaces.
This would mean code with ``sequence numbers'' in columns 73 through 80
would be rejected, and there's a lot of that kind of code around,
but one of the most frequent bugs encountered by new users is
accidentally writing fixed-form source code into and beyond
column 73.
So, maybe the users of old code would be able to more easily handle
having to specify, say, a @option{-Wno-col73to80} option.

@node Fortran 90 Support
@subsection Fortran 90 Support
@cindex Fortran 90, support
@cindex support, Fortran 90

@command{g77} does not support many of the features that
distinguish Fortran 90 (and, now, Fortran 95) from
ANSI FORTRAN 77.

Some Fortran 90 features are supported, because they
make sense to offer even to die-hard users of F77.
For example, many of them codify various ways F77 has
been extended to meet users' needs during its tenure,
so @command{g77} might as well offer them as the primary
way to meet those same needs, even if it offers compatibility
with one or more of the ways those needs were met
by other F77 compilers in the industry.

Still, many important F90 features are not supported,
because no attempt has been made to research each and
every feature and assess its viability in @command{g77}.
In the meantime, users who need those features must
use Fortran 90 compilers anyway, and the best approach
to adding some F90 features to GNU Fortran might well be
to fund a comprehensive project to create GNU Fortran 95.

@node Intrinsics in PARAMETER Statements
@subsection Intrinsics in @code{PARAMETER} Statements
@cindex PARAMETER statement
@cindex statements, PARAMETER

@command{g77} doesn't allow intrinsics in @code{PARAMETER} statements.

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

@node Arbitrary Concatenation
@subsection Arbitrary Concatenation
@cindex concatenation
@cindex CHARACTER*(*)
@cindex run-time, dynamic allocation

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

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

@node SELECT CASE on CHARACTER Type
@subsection @code{SELECT CASE} on @code{CHARACTER} Type

Character-type selector/cases for @code{SELECT CASE} currently
are not supported.

@node RECURSIVE Keyword
@subsection @code{RECURSIVE} Keyword
@cindex RECURSIVE keyword
@cindex keywords, RECURSIVE
@cindex recursion, lack of
@cindex lack of recursion

@command{g77} doesn't support the @code{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.

@node Increasing Precision/Range
@subsection Increasing Precision/Range
@cindex -r8
@cindex -qrealsize=8
@cindex -i8
@cindex f2c
@cindex increasing precision
@cindex precision, increasing
@cindex increasing range
@cindex range, increasing
@cindex Toolpack
@cindex Netlib

Some compilers, such as @command{f2c}, have an option (@option{-r8},
@option{-qrealsize=8} or
similar) that provides automatic treatment of @code{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 @code{REAL(KIND=1)} (default @code{REAL}) type.
(This affects @code{COMPLEX} the same way.)

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

(There are potential pitfalls in using these options.)

@command{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 @command{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 @file{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).

@node Popular Non-standard Types
@subsection Popular Non-standard Types
@cindex @code{INTEGER*2} support
@cindex types, @code{INTEGER*2}
@cindex @code{LOGICAL*1} support
@cindex types, @code{LOGICAL*1}

@command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
and similar.
In the meantime, version 0.5.18 provides rudimentary support
for them.

@node Full Support for Compiler Types
@subsection Full Support for Compiler Types

@cindex @code{REAL*16} support
@cindex types, @code{REAL*16}
@cindex @code{INTEGER*8} support
@cindex types, @code{INTEGER*8}
@command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
@code{int}, @code{long int}, @code{long long int}, and @code{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 @code{INTEGER*1},
@code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
and so on.

@node Array Bounds Expressions
@subsection Array Bounds Expressions
@cindex array elements, in adjustable array bounds
@cindex function references, in adjustable array bounds
@cindex array bounds, adjustable
@cindex @code{DIMENSION} statement
@cindex statements, @code{DIMENSION}

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

For example, @command{g77} currently does not accept the following:

@smallexample
SUBROUTINE X(M, N)
INTEGER N(10), M(N(2), N(1))
@end smallexample

@node POINTER Statements
@subsection POINTER Statements
@cindex POINTER statement
@cindex statements, POINTER
@cindex Cray pointers

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

In the meantime, consider using the @code{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 @command{g77} is used.

@xref{Functions and Subroutines}, for information on
@code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
constructs, which are useful for passing pointers to
procedures written in languages other than Fortran.

@node Sensible Non-standard Constructs
@subsection Sensible Non-standard Constructs

@command{g77} rejects things other compilers accept,
like @samp{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 @command{g77} (though @option{-fpedantic} should
trigger warnings about such non-standard constructs).

Until @command{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 @code{INCLUDE} file that
defines a common block, it might be appropriate to
include a @code{SAVE} statement for the common block
(such as @samp{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 @code{SAVE} statements in an @code{INCLUDE}
file would prevent otherwise standard-conforming code
from also specifying the @code{SAVE} statement, by itself,
to indicate that all local variables and arrays are to
have the @code{SAVE} attribute.

For this reason, @command{g77} already has been changed to
allow this combination, because although the general
problem of gratuitously rejecting unambiguous and
``safe'' constructs still exists in @command{g77}, this
particular construct was deemed useful enough that
it was worth fixing @command{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 @command{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 @command{g77} just for cases like yours.

@node READONLY Keyword
@subsection @code{READONLY} Keyword
@cindex READONLY

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

@emph{Note:} It is not sufficient for @command{g77} and @code{libg2c}
(its version of @code{libf2c})
to assume that @code{READONLY} does not need some kind of explicit support
at run time,
due to UNIX systems not (generally) needing it.
@command{g77} is not just a UNIX-based compiler!

Further, mounting of non-UNIX filesystems on UNIX systems
(such as via NFS)
might require proper @code{READONLY} support.

@cindex SHARED
(Similar issues might be involved with supporting the @code{SHARED}
keyword.)

@node FLUSH Statement
@subsection @code{FLUSH} Statement

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

@node Expressions in FORMAT Statements
@subsection Expressions in @code{FORMAT} Statements
@cindex FORMAT statement
@cindex statements, FORMAT

@command{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
Supporting this requires a significant redesign or replacement
of @code{libg2c}.

However, @command{g77} does support
this construct when the expression is constant
(as of version 0.5.22).
For example:

@smallexample
      PARAMETER (IWIDTH = 12)
10    FORMAT (I<IWIDTH>)
@end smallexample

Otherwise, at least for output (@code{PRINT} and
@code{WRITE}), Fortran code making use of this feature can
be rewritten to avoid it by constructing the @code{FORMAT}
string in a @code{CHARACTER} variable or array, then
using that variable or array in place of the @code{FORMAT}
statement label to do the original @code{PRINT} or @code{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:

@smallexample
      READ 20, I
20    FORMAT (I<J>)
@end smallexample

However, this cannot, in general, be rewritten, especially
when @code{ERR=} and @code{END=} constructs are employed:

@smallexample
      READ 30, J, I
30    FORMAT (I<J>)
@end smallexample

@node Explicit Assembler Code
@subsection Explicit Assembler Code

@command{g77} needs to provide some way, a la @command{gcc}, for @command{g77}
code to specify explicit assembler code.

@node Q Edit Descriptor
@subsection Q Edit Descriptor
@cindex FORMAT statement
@cindex Q edit descriptor
@cindex edit descriptor, Q

The @code{Q} edit descriptor in @code{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 @code{libg2c}.

A workaround might be using internal I/O or the stream-based intrinsics.
@xref{FGetC Intrinsic (subroutine)}.

@node Old-style PARAMETER Statements
@subsection Old-style PARAMETER Statements
@cindex PARAMETER statement
@cindex statements, PARAMETER

@command{g77} doesn't accept @samp{PARAMETER I=1}.
Supporting this obsolete form of
the @code{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, @samp{PARAMETER (I=1)} (possibly needing
@samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
otherwise, in the obsolete form of @code{PARAMETER}, the
type of the variable is set from the type of the constant being
assigned to it).

@node TYPE and ACCEPT I/O Statements
@subsection @code{TYPE} and @code{ACCEPT} I/O Statements
@cindex TYPE statement
@cindex statements, TYPE
@cindex ACCEPT statement
@cindex statements, ACCEPT

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

Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
by @samp{PRINT fmt,list}.
And, any @samp{ACCEPT fmt,list} statement can be
replaced by @samp{READ fmt,list}.

@node STRUCTURE UNION RECORD MAP
@subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
@cindex STRUCTURE statement
@cindex statements, STRUCTURE
@cindex UNION statement
@cindex statements, UNION
@cindex RECORD statement
@cindex statements, RECORD
@cindex MAP statement
@cindex statements, MAP

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

@node OPEN CLOSE and INQUIRE Keywords
@subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
@cindex disposition of files
@cindex OPEN statement
@cindex statements, OPEN
@cindex CLOSE statement
@cindex statements, CLOSE
@cindex INQUIRE statement
@cindex statements, INQUIRE

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

@cindex FORM='PRINT'
@cindex ANS carriage control
@cindex carriage control
@pindex asa
@pindex fpr
@command{g77} doesn't support @code{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 @command{fpr} or @command{asa}.  You can get
a version of @command{asa} from
@uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
systems which will probably build easily on other systems.
Alternatively, @command{fpr} is in BSD distributions in various archive
sites.

@c (Can both programs can be used in a pipeline,
@c with a named input file,
@c and/or with a named output file???)

@node ENCODE and DECODE
@subsection @code{ENCODE} and @code{DECODE}
@cindex ENCODE statement
@cindex statements, ENCODE
@cindex DECODE statement
@cindex statements, DECODE

@command{g77} doesn't support @code{ENCODE} or @code{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

@smallexample
      INTEGER*1 LINE(80)
@dots{}
      DECODE (80, 9000, LINE) A, B, C
@dots{}
9000  FORMAT (1X, 3(F10.5))
@end smallexample

@noindent
with:

@smallexample
      CHARACTER*80 LINE
@dots{}
      READ (UNIT=LINE, FMT=9000) A, B, C
@dots{}
9000  FORMAT (1X, 3(F10.5))
@end smallexample

Similarly, replace a code fragment like

@smallexample
      INTEGER*1 LINE(80)
@dots{}
      ENCODE (80, 9000, LINE) A, B, C
@dots{}
9000  FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
@end smallexample

@noindent
with:

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

It is entirely possible that @code{ENCODE} and @code{DECODE} will
be supported by a future version of @command{g77}.

@node AUTOMATIC Statement
@subsection @code{AUTOMATIC} Statement
@cindex @code{AUTOMATIC} statement
@cindex statements, @code{AUTOMATIC}
@cindex automatic variables
@cindex variables, automatic

@command{g77} doesn't support the @code{AUTOMATIC} statement that
@command{f2c} does.

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

@code{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.

@code{AUTOMATIC} would not, by itself, designate the containing procedure
as recursive.

@code{AUTOMATIC} should work syntactically like @code{SAVE},
in that @code{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 @code{AUTOMATIC}
would not be permitted to be initialized via @code{DATA}
or other specification of any initial values,
requiring explicit initialization,
such as via assignment statements.

@cindex UNSAVE
@cindex STATIC
Perhaps @code{UNSAVE} and @code{STATIC},
as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
should be provided as well.

@node Suppressing Space Padding
@subsection Suppressing Space Padding of Source Lines

@command{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:

@smallexample
10    PRINT *,'HOW MANY
     1 SPACES?'
@end smallexample

@noindent
@command{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 @samp{MANY} and @samp{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 @file{comp.lang.fortran}
to offer conformance to this widespread practice in the
industry.
@command{g77} should return the favor by offering conformance
to Digital's approach to handling the above example.

@node Fortran Preprocessor
@subsection Fortran Preprocessor

@command{g77} should offer a preprocessor designed specifically
for Fortran to replace @samp{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 @code{INCLUDE} directive.

@node Bit Operations on Floating-point Data
@subsection Bit Operations on Floating-point Data
@cindex @code{And} intrinsic
@cindex intrinsics, @code{And}
@cindex @code{Or} intrinsic
@cindex intrinsics, @code{Or}
@cindex @code{Shift} intrinsic
@cindex intrinsics, @code{Shift}

@command{g77} does not allow @code{REAL} and other non-integral types for
arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.

For example, this program is rejected by @command{g77}, because
the intrinsic @code{Iand} does not accept @code{REAL} arguments:

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

@node Really Ugly Character Assignments
@subsection Really Ugly Character Assignments

An option such as @option{-fugly-char} should be provided
to allow

@smallexample
REAL*8 A1
DATA A1 / '12345678' /
@end smallexample

and:

@smallexample
REAL*8 A1
A1 = 'ABCDEFGH'
@end smallexample

@node POSIX Standard
@subsection @code{POSIX} Standard

@command{g77} should support the POSIX standard for Fortran.

@node Floating-point Exception Handling
@subsection Floating-point Exception Handling
@cindex floating-point, exceptions
@cindex exceptions, floating-point
@cindex FPE handling
@cindex NaN values

The @command{gcc} backend and, consequently, @command{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 behavior is normally inherited from the system-dependent startup
code, though some targets, such as the Alpha, have code generation
options which change the behavior.

Most systems provide some C-callable mechanism to change this; this can
be invoked at startup using @command{gcc}'s @code{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:

@smallexample
#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);
@}
@end smallexample

A convenient trick is to compile this something like:
@smallexample
gcc -o libtrapfpe.a trapfpe.c
@end smallexample
and then use it by adding @option{-trapfpe} to the @command{g77} command line
when linking.

@node Nonportable Conversions
@subsection Nonportable Conversions
@cindex nonportable conversions
@cindex conversions, nonportable

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

Some of these conversions are accepted by @command{g77}
when the @option{-fugly-logint} option is specified.
Perhaps it should accept more or all of them.

@node Large Automatic Arrays
@subsection Large Automatic Arrays
@cindex automatic arrays
@cindex arrays, automatic

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

@node Support for Threads
@subsection Support for Threads
@cindex threads
@cindex parallel processing

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

@node Enabling Debug Lines
@subsection Enabling Debug Lines
@cindex debug line
@cindex comment line, debug

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

@node Better Warnings
@subsection Better Warnings

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

@smallexample
PROGRAM X
PRINT *, A
END
@end smallexample

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

Fixing this requires one of the following:

@itemize @bullet
@item
Switch to new library, @code{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.

@item
Have @command{g77} pass a pointer to a temporary
containing a copy of @samp{A},
instead of to @samp{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 @samp{A} might then end up living in a register,
which could help with inner loops.

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

Probably the best solution for now, but not quite trivial
to implement in the general case.
@end itemize

@node Gracefully Handle Sensible Bad Code
@subsection Gracefully Handle Sensible Bad Code

@command{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:

@smallexample
INTRINSIC ZABS
CALL FOO(ZABS)
END
@end smallexample

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

@node Non-standard Conversions
@subsection Non-standard Conversions

@option{-Wconversion} and related should flag places where non-standard
conversions are found.
Perhaps much of this would be part of @option{-Wugly*}.

@node Non-standard Intrinsics
@subsection Non-standard Intrinsics

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

@node Modifying DO Variable
@subsection Modifying @code{DO} Variable

@command{g77} should warn about modifying @code{DO} variables
via @code{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 @command{g77} should warn about
the invalid assignment to @samp{NOTHER}:

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

@node Better Pedantic Compilation
@subsection Better Pedantic Compilation

@command{g77} needs to support @option{-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 @code{COMMON} (F77 does not allow it to be
placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
follow statement-function-definition statements; about all sorts of
syntactic extensions.

@node Warn About Implicit Conversions
@subsection Warn About Implicit Conversions

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

For example, it would warn about cases like this:

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

@node Invalid Use of Hollerith Constant
@subsection Invalid Use of Hollerith Constant

@command{g77} should disallow statements like @samp{RETURN 2HAB},
which are invalid in both source forms
(unlike @samp{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.

@node Dummy Array Without Dimensioning Dummy
@subsection Dummy Array Without Dimensioning Dummy

@command{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, @command{g77} does complain about a variable that
dimensions an array but doesn't appear in any dummy list or @code{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, @command{g77} should warn about the entry point @samp{ALT}
below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
list of arguments:

@smallexample
SUBROUTINE PRIMARY(ARRAY, ISIZE)
REAL ARRAY(ISIZE)
ENTRY ALT(ARRAY)
@end smallexample

@node Invalid FORMAT Specifiers
@subsection Invalid FORMAT Specifiers

@command{g77} should check @code{FORMAT} specifiers for validity
as it does @code{FORMAT} statements.

For example, a diagnostic would be produced for:

@smallexample
PRINT 'HI THERE!'  !User meant PRINT *, 'HI THERE!'
@end smallexample

@node Ambiguous Dialects
@subsection Ambiguous Dialects

@command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic},
@option{-Wvxt}, @option{-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.

@node Unused Labels
@subsection Unused Labels

@command{g77} should warn about unused labels when @option{-Wunused} is in effect.

@node Informational Messages
@subsection Informational Messages

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

Perhaps info messages should simply be eliminated.

@node Uninitialized Variables at Run Time
@subsection Uninitialized Variables at Run Time

@command{g77} needs an option to initialize everything (not otherwise
explicitly initialized) to ``weird''
(machine-dependent) values, e.g. NaNs, bad (non-@code{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 @samp{-O -Wuninitialized} can catch
many such bugs at compile time.

@node Portable Unformatted Files
@subsection Portable Unformatted Files

@cindex unformatted files
@cindex file formats
@cindex binary data
@cindex byte ordering
@command{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 @command{g77} runtime
should at least be able to read files written by @command{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
@command{g77} (@code{libf2c}) unformatted files, they are written as
follows:
@table @asis
@item Sequential
Unformatted sequential records consist of
@enumerate
@item
A number giving the length of the record contents;
@item
the length of record contents again (for backspace).
@end enumerate

The record length is of C type
@code{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.
@item Direct access
Unformatted direct access files form a byte stream of length
@var{records}*@var{recl} bytes, where @var{records} is the maximum
record number (@code{REC=@var{records}}) written and @var{recl} is the
record length in bytes specified in the @code{OPEN} statement
(@code{RECL=@var{recl}}).  Data appear in the records as determined by
the relevant @code{WRITE} statement.  Dummy records with arbitrary
contents appear in the file in place of records which haven't been
written.
@end table

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 @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
@code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
@command{g77}.

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

@cindex HDF
@cindex PDB
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 (@uref{http://hdf.ncsa.uiuc.edu/})
or PACT's PDB@footnote{No, not @emph{that} one.}
(@uref{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 @command{g77} runtime library should use such
techniques.

@node Better List-directed I/O
@subsection Better List-directed I/O

Values output using list-directed I/O
(@samp{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 @code{libf2c}.)

It is likely this item will require the @code{libg77} project
to be undertaken.

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

@node Default to Console I/O
@subsection Default to Console I/O

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

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

This change probably requires the @code{libg77} project.

@node Labels Visible to Debugger
@subsection Labels Visible to Debugger

@command{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.

@node Disappointments
@section Disappointments and Misunderstandings

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

@menu
* Mangling of Names::                       @samp{SUBROUTINE FOO} is given
                                              external name @samp{foo_}.
* Multiple Definitions of External Names::  No doing both @samp{COMMON /FOO/}
                                              and @samp{SUBROUTINE FOO}.
* Limitation on Implicit Declarations::     No @samp{IMPLICIT CHARACTER*(*)}.
@end menu

@node Mangling of Names
@subsection Mangling of Names in Source Code
@cindex naming issues
@cindex external names
@cindex common blocks
@cindex name space
@cindex underscore

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.

@node Multiple Definitions of External Names
@subsection Multiple Definitions of External Names
@cindex block data
@cindex BLOCK DATA statement
@cindex statements, BLOCK DATA
@cindex @code{COMMON} statement
@cindex statements, @code{COMMON}
@cindex naming conflicts

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

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

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

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

@node Limitation on Implicit Declarations
@subsection Limitation on Implicit Declarations
@cindex IMPLICIT CHARACTER*(*) statement
@cindex statements, IMPLICIT CHARACTER*(*)

@command{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
This is not standard-conforming.

@node Non-bugs
@section 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 @samp{'\\'} is a constant that
                                       is one, not two, characters long.
* Initializing Before Specifying::   Why @samp{DATA VAR/1/} can't precede
                                       @samp{COMMON VAR}.
* Context-Sensitive Intrinsicness::  Why @samp{CALL SQRT} won't work.
* Context-Sensitive Constants::      Why @samp{9.435784839284958} is a
                                       single-precision constant,
                                       and might be interpreted as
                                       @samp{9.435785} or similar.
* Equivalence Versus Equality::      Why @samp{.TRUE. .EQ. .TRUE.} won't work.
* Order of Side Effects::            Why @samp{J = IFUNC() - IFUNC()} might
                                       not behave as expected.
@end menu

@node Backslash in Constants
@subsection Backslash in Constants
@cindex backslash
@cindex @command{f77} support
@cindex support, @command{f77}

In the opinion of many experienced Fortran users,
@option{-fno-backslash} should be the default, not @option{-fbackslash},
as currently set by @command{g77}.

First of all, you can always specify
@option{-fno-backslash} to turn off this processing.

Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to
@option{-fbackslash} because that is what most UNIX @command{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 @option{-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 @option{-fno-backslash} the default for GNU
Fortran and thus require users of UNIX @command{f77} and @command{f2c}
to specify @option{-fbackslash} to get the UNIX behavior.

However, the realization that @command{g77} is intended as
a replacement for @emph{UNIX} @command{f77}, caused the author
to choose to make @command{g77} as compatible with
@command{f77} as feasible, which meant making @option{-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 @command{f77} to do, by default?''
Although at least one UNIX @command{f77} does not provide
@option{-fbackslash} as a default, it appears that
the majority of them do, which suggests that
the majority of code that is compiled by UNIX @command{f77}
compilers expects @option{-fbackslash} to be the default.

It is probably the case that more code exists
that would @emph{not} work with @option{-fbackslash}
in force than code that requires it be in force.

However, most of @emph{that} code is not being compiled
with @command{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
@command{g77}'s default of @option{-fbackslash} than would
exist for the majority of UNIX @command{f77} users who
would have to modify existing, working build procedures
to explicitly specify @option{-fbackslash} if that was
not the default.

One suggestion has been to configure the default for
@option{-fbackslash} (and perhaps other options as well)
based on the configuration of @command{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 @command{gcc}.
To change them for @command{g77}, you must first change them
for @command{gcc}.
Do not ask the maintainers of @command{g77} to do this for you,
or to disassociate @command{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).
@xref{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 (@samp{\})
being interpreted either way in particular, such as by
starting a program unit with:

@smallexample
CHARACTER BACKSL
PARAMETER (BACKSL = '\\')
@end smallexample

@noindent
Then, use concatenation of @samp{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.)

@node Initializing Before Specifying
@subsection Initializing Before Specifying
@cindex initialization, statement placement
@cindex placing initialization statements

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

It is @emph{possible} @command{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
@command{g77} always require placement of @code{DATA}
so that it can possibly immediately write constants
to the output file, thus saving time and space.

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

@node Context-Sensitive Intrinsicness
@subsection Context-Sensitive Intrinsicness
@cindex intrinsics, context-sensitive
@cindex context-sensitive intrinsics

@command{g77} treats procedure references to @emph{possible} intrinsic
names as always enabling their intrinsic nature, regardless of
whether the @emph{form} of the reference is valid for that
intrinsic.

For example, @samp{CALL SQRT} is interpreted by @command{g77} as
an invalid reference to the @code{SQRT} intrinsic function,
because the reference is a subroutine invocation.

First, @command{g77} recognizes the statement @samp{CALL SQRT}
as a reference to a @emph{procedure} named @samp{SQRT}, not
to a @emph{variable} with that name (as it would for a statement
such as @samp{V = SQRT}).

Next, @command{g77} establishes that, in the program unit being compiled,
@code{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, @samp{EXTERNAL SQRT} was present).

Finally, @command{g77} recognizes that the @emph{form} of the
reference is invalid for that particular intrinsic.
That is, it recognizes that it is invalid for an intrinsic
@emph{function}, such as @code{SQRT}, to be invoked as
a @emph{subroutine}.

At that point, @command{g77} issues a diagnostic.

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

However, @command{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, @command{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 @samp{EXTERNAL SQRT} statement in a program unit that calls
a user-written subroutine named @samp{SQRT}.

@node Context-Sensitive Constants
@subsection Context-Sensitive Constants
@cindex constants, context-sensitive
@cindex context-sensitive constants

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

For example, consider the following statement:

@smallexample
PRINT *, 9.435784839284958 * 2D0
@end smallexample

@noindent
@command{g77} will interpret the (truncated) constant
@samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
constant, because the suffix @code{D0} is not specified.

As a result, the output of the above statement when
compiled by @command{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 @emph{explicitly}
specified as a double-precision constant.
(This has the effect of appending @emph{decimal}, not
@emph{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:

@smallexample
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
@end smallexample

@noindent
Running the above program should
result in the same value being
printed three times.
With @command{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 @samp{5.000000000001}, which
on most systems is exactly equal to @samp{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 (@code{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.
@command{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
@command{g77} can do to help flag cases of this in such code
could be very helpful.

@node Equivalence Versus Equality
@subsection Equivalence Versus Equality
@cindex .EQV., with integer operands
@cindex comparing logical expressions
@cindex logical expressions, comparing

Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
is not supported, except via @option{-fugly-logint}, which is not
recommended except for legacy code (where the behavior expected
by the @emph{code} is assumed).

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

New code should never be written expecting @code{.EQ.} or @code{.NE.}
to work if either of its operands is @code{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:

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

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

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

Other programmers will argue that the precedence is the same as
the precedence for @code{.EQV.}, which is restricted by the standards
to @code{LOGICAL} operands.
By this interpretation, the subexpression @samp{L.AND.M} must be
evaluated first, resulting in a program that @emph{does} execute
the @code{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 @code{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.
@command{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
@samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
you, without knowing more context, whether the @samp{&} and @samp{-}
operators are infix (binary) or unary!)

Most dangerous of all is the fact that,
even assuming consensus on its meaning,
an expression like @samp{L.AND.M.EQ.N},
if it is the result of a typographical error,
doesn't @emph{look} like it has such a typo.
Even experienced Fortran programmers would not likely notice that
@samp{L.AND.M.EQV.N} was, in fact, intended.

So, this is a prime example of a circumstance in which
a quality compiler diagnoses the code,
instead of leaving it up to someone debugging it
to know to turn on special compiler options
that might diagnose it.

@node Order of Side Effects
@subsection Order of Side Effects
@cindex side effects, order of evaluation
@cindex order of evaluation, side effects

@command{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 @command{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:

@smallexample
J = IFUNC() - IFUNC()
@end smallexample

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

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

@itemize @bullet
@item
The generation of random numbers
that are intended to influence return values.

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

@item
Updating information in common blocks.
@end itemize

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

@node Warnings and Errors
@section Warning Messages and Error Messages

@cindex error messages
@cindex warnings vs errors
@cindex messages, warning and error
The GNU compiler can produce two kinds of diagnostics: errors and
warnings.
Each kind has a different purpose:

@itemize @w{}
@item
@emph{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.

@item
@emph{Warnings} report other unusual conditions in your code that
@emph{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 @samp{warning:} to distinguish them
from error messages.
@end itemize

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
@option{-W} options (for instance, @option{-Wall} requests a variety of
useful warnings).

@emph{Note:} Currently, the text of the line and a pointer to the column
is printed in most @command{g77} diagnostics.

@xref{Warning Options,,Options to Request or Suppress Warnings}, for
more detail on these and related command-line options.

@node Open Questions
@chapter Open Questions

Please consider offering useful answers to these questions!

@itemize @bullet
@item
@code{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?
@end itemize

@node Bugs
@chapter Reporting Bugs
@cindex bugs
@cindex 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.
@xref{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
@ref{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.
@end menu

@xref{Trouble,,Known Causes of Trouble with GNU Fortran},
for information on problems we already know about.

@xref{Service,,How To Get Help with GNU Fortran},
for information on where to ask for help.

@node Bug Criteria
@section Have You Found a Bug?
@cindex bug criteria

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

@itemize @bullet
@cindex fatal signal
@cindex core dump
@item
If the compiler gets a fatal signal, for any input whatever, that is a
compiler bug.
Reliable compilers never crash---they just remain obsolete.

@cindex invalid assembly code
@cindex assembly code, invalid
@item
If the compiler produces invalid assembly code, for any input whatever,
@c (except an @code{asm} statement),
that is a compiler bug, unless the
compiler reports errors (not just warnings) which would ordinarily
prevent the assembler from being run.

@cindex undefined behavior
@cindex undefined function value
@item
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.
@c (@pxref{Incompatibilities}).
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.

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

@cindex invalid input
@item
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''.

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

Many, perhaps most, bug reports against @command{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 @command{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 @command{g77}:

@itemize @bullet
@item
Compile your code using the @command{g77} options @samp{-W -Wall -O}.
These options enable many useful warning; the @option{-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 @command{g77}.

@item
Compile your code using the @command{g77} options @option{-finit-local-zero},
@option{-fno-automatic}, @option{-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 @command{g77}---a @command{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 unwarranted assumptions
about the Fortran dialect and/or underlying machine it is
being compiled and run on.

@xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
for information on the @option{-fno-automatic} and
@option{-finit-local-zero} options and how to convert
their use into selective changes in your own code.

@item
@pindex ftnchek
Validate your code with @command{ftnchek} or a similar code-checking
tool.
@command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
or @uref{ftp://ftp.dsm.fordham.edu}.

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

@smallexample
# 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)
@end smallexample

@item
Try your code out using other Fortran compilers, such as @command{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 @emph{except}
@command{g77}, that does @emph{not} mean the bug is in @command{g77}.
It might mean the bug is in your code, and that @command{g77} simply
exposes it more readily than other compilers.
@end itemize

@node Bug Lists
@section Where to Report Bugs
@cindex bug report mailing lists
@kindex @value{email-bugs}
Send bug reports for GNU Fortran to @email{@value{email-bugs}}.

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:

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

@node Bug Reporting
@section How to Report Bugs
@cindex compiler bugs, reporting

The fundamental principle of reporting bugs usefully is this:
@strong{report all the facts}.
If you are not sure whether to state a
fact or leave it out, state it!

Often people omit facts because they think they know what causes the
problem and they conclude that some details don't matter.
Thus, you might
assume that the name of the variable you use in an example does not matter.
Well, probably it doesn't, but one cannot be sure.
Perhaps the bug is a
stray memory reference which happens to fetch from the location where that
name is stored in memory; perhaps, if the name were different, the contents
of that location would fool the compiler into doing the right thing despite
the bug.
Play it safe and give a specific, complete example.
That is the
easiest thing for you to do, and the most helpful.

Keep in mind that the purpose of a bug report is to enable someone to
fix the bug if it is not known.
It isn't very important what happens if
the bug is already known.
Therefore, always write your bug reports on
the assumption that the bug is not known.

Sometimes people give a few sketchy facts and ask, ``Does this ring a
bell?''
This cannot help us fix a bug, so it is rarely helpful.
We respond by asking for enough details to enable us to investigate.
You might as well expedite matters by sending them to begin with.
(Besides, there are enough bells ringing around here as it is.)

Try to make your bug report self-contained.
If we have to ask you for
more information, it is best if you include all the previous information
in your response, as well as the information that was missing.

Please report each bug in a separate message.
This makes it easier for
us to track which bugs have been fixed and to forward your bugs reports
to the appropriate maintainer.

Do not compress and encode any part of your bug report using programs
such as @file{uuencode}.
If you do so it will slow down the processing
of your bug.
If you must submit multiple large files, use @file{shar},
which allows us to read your message without having to run any
decompression programs.

(As a special exception for GNU Fortran bug-reporting, at least
for now, if you are sending more than a few lines of code, if
your program's source file format contains ``interesting'' things
like trailing spaces or strange characters, or if you need to
include binary data files, it is acceptable to put all the
files together in a @command{tar} archive, and, whether you need to
do that, it is acceptable to then compress the single file (@command{tar}
archive or source file)
using @command{gzip} and encode it via @command{uuencode}.
Do not use any MIME stuff---the current maintainer can't decode this.
Using @command{compress} instead of @command{gzip} is acceptable, assuming
you have licensed the use of the patented algorithm in
@command{compress} from Unisys.)

To enable someone to investigate the bug, you should include all these
things:

@itemize @bullet
@item
The version of GNU Fortran.
You can get this by running @command{g77} with the @option{-v} option.
(Ignore any error messages that might be displayed
when the linker is run.)

Without this, we won't know whether there is any point in looking for
the bug in the current version of GNU Fortran.

@item
@cindex preprocessor
@cindex cpp program
@cindex programs, cpp
@pindex cpp
A complete input file that will reproduce the bug.

If your source file(s) require preprocessing
(for example, their names have suffixes like
@samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
and the bug is in the compiler proper (@file{f771})
or in a subsequent phase of processing,
run your source file through the C preprocessor
by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
Then, include the contents of @var{newfile} in the bug report.
(When you do this, use the same preprocessor options---such as
@option{-I}, @option{-D}, and @option{-U}---that you used in actual
compilation.)

A single statement is not enough of an example.
In order to compile it,
it must be embedded in a complete file of compiler input.
The bug might depend on the details of how this is done.

Without a real example one can compile,
all anyone can do about your bug report is wish you luck.
It would be futile to try to guess how to provoke the bug.
For example, bugs in register allocation and reloading
can depend on every little detail of the source and include files
that trigger them.

@item
@cindex included files
@cindex INCLUDE directive
@cindex directive, INCLUDE
@cindex #include directive
@cindex directive, #include
Note that you should include with your bug report any files
included by the source file
(via the @code{#include} or @code{INCLUDE} directive)
that you send, and any files they include, and so on.

It is not necessary to replace
the @code{#include} and @code{INCLUDE} directives
with the actual files in the version of the source file that
you send, but it might make submitting the bug report easier
in the end.
However, be sure to @emph{reproduce} the bug using the @emph{exact}
version of the source material you submit, to avoid wild-goose
chases.

@item
The command arguments you gave GNU Fortran to compile that example
and observe the bug.  For example, did you use @option{-O}?  To guarantee
you won't omit something important, list all the options.

If we were to try to guess the arguments, we would probably guess wrong
and then we would not encounter the bug.

@item
The type of machine you are using, and the operating system name and
version number.
(Much of this information is printed by @samp{g77 -v}---if you
include that, send along any additional info you have that you
don't see clearly represented in that output.)

@item
The operands you gave to the @command{configure} command when you installed
the compiler.

@item
A complete list of any modifications you have made to the compiler
source.  (We don't promise to investigate the bug unless it happens in
an unmodified compiler.  But if you've made modifications and don't tell
us, then you are sending us on a wild-goose chase.)

Be precise about these changes.  A description in English is not
enough---send a context diff for them.

Adding files of your own (such as a machine description for a machine we
don't support) is a modification of the compiler source.

@item
Details of any other deviations from the standard procedure for installing
GNU Fortran.

@item
A description of what behavior you observe that you believe is
incorrect.  For example, ``The compiler gets a fatal signal,'' or,
``The assembler instruction at line 208 in the output is incorrect.''

Of course, if the bug is that the compiler gets a fatal signal, then one
can't miss it.  But if the bug is incorrect output, the maintainer might
not notice unless it is glaringly wrong.  None of us has time to study
all the assembler code from a 50-line Fortran program just on the chance that
one instruction might be wrong.  We need @emph{you} to do this part!

Even if the problem you experience is a fatal signal, you should still
say so explicitly.  Suppose something strange is going on, such as, your
copy of the compiler is out of synch, or you have encountered a bug in
the C library on your system.  (This has happened!)  Your copy might
crash and the copy here would not.  If you @i{said} to expect a crash,
then when the compiler here fails to crash, we would know that the bug
was not happening.  If you don't say to expect a crash, then we would
not know whether the bug was happening.  We would not be able to draw
any conclusion from our observations.

If the problem is a diagnostic when building GNU Fortran with some other
compiler, say whether it is a warning or an error.

Often the observed symptom is incorrect output when your program is run.
Sad to say, this is not enough information unless the program is short
and simple.  None of us has time to study a large program to figure out
how it would work if compiled correctly, much less which line of it was
compiled wrong.  So you will have to do that.  Tell us which source line
it is, and what incorrect result happens when that line is executed.  A
person who understands the program can find this as easily as finding a
bug in the program itself.

@item
If you send examples of assembler code output from GNU Fortran,
please use @option{-g} when you make them.  The debugging information
includes source line numbers which are essential for correlating the
output with the input.

@item
If you wish to mention something in the GNU Fortran source, refer to it by
context, not by line number.

The line numbers in the development sources don't match those in your
sources.  Your line numbers would convey no convenient information to the
maintainers.

@item
Additional information from a debugger might enable someone to find a
problem on a machine which he does not have available.  However, you
need to think when you collect this information if you want it to have
any chance of being useful.

@cindex backtrace for bug reports
For example, many people send just a backtrace, but that is never
useful by itself.  A simple backtrace with arguments conveys little
about GNU Fortran because the compiler is largely data-driven; the same
functions are called over and over for different RTL insns, doing
different things depending on the details of the insn.

Most of the arguments listed in the backtrace are useless because they
are pointers to RTL list structure.  The numeric values of the
pointers, which the debugger prints in the backtrace, have no
significance whatever; all that matters is the contents of the objects
they point to (and most of the contents are other such pointers).

In addition, most compiler passes consist of one or more loops that
scan the RTL insn sequence.  The most vital piece of information about
such a loop---which insn it has reached---is usually in a local variable,
not in an argument.

@findex debug_rtx
What you need to provide in addition to a backtrace are the values of
the local variables for several stack frames up.  When a local
variable or an argument is an RTX, first print its value and then use
the GDB command @command{pr} to print the RTL expression that it points
to.  (If GDB doesn't run on your machine, use your debugger to call
the function @code{debug_rtx} with the RTX as an argument.)  In
general, whenever a variable is a pointer, its value is no use
without the data it points to.
@end itemize

Here are some things that are not necessary:

@itemize @bullet
@item
A description of the envelope of the bug.

Often people who encounter a bug spend a lot of time investigating
which changes to the input file will make the bug go away and which
changes will not affect it.

This is often time consuming and not very useful, because the way we
will find the bug is by running a single example under the debugger with
breakpoints, not by pure deduction from a series of examples.  You might
as well save your time for something else.

Of course, if you can find a simpler example to report @emph{instead} of
the original one, that is a convenience.  Errors in the output will be
easier to spot, running under the debugger will take less time, etc.
Most GNU Fortran bugs involve just one function, so the most straightforward
way to simplify an example is to delete all the function definitions
except the one where the bug occurs.  Those earlier in the file may be
replaced by external declarations if the crucial function depends on
them.  (Exception: inline functions might affect compilation of functions
defined later in the file.)

However, simplification is not vital; if you don't want to do this,
report the bug anyway and send the entire test case you used.

@item
In particular, some people insert conditionals @samp{#ifdef BUG} around
a statement which, if removed, makes the bug not happen.  These are just
clutter; we won't pay any attention to them anyway.  Besides, you should
send us preprocessor output, and that can't have conditionals.

@item
A patch for the bug.

A patch for the bug is useful if it is a good one.  But don't omit the
necessary information, such as the test case, on the assumption that a
patch is all we need.  We might see problems with your patch and decide
to fix the problem another way, or we might not understand it at all.

Sometimes with a program as complicated as GNU Fortran it is very hard to
construct an example that will make the program follow a certain path
through the code.  If you don't send the example, we won't be able to
construct one, so we won't be able to verify that the bug is fixed.

And if we can't understand what bug you are trying to fix, or why your
patch should be an improvement, we won't install it.  A test case will
help us to understand.

See @uref{http://gcc.gnu.org/contribute.html}
for guidelines on how to make it easy for us to
understand and install your patches.

@item
A guess about what the bug is or what it depends on.

Such guesses are usually wrong.  Even the maintainer can't guess right
about such things without first using the debugger to find the facts.

@item
A core dump file.

We have no way of examining a core dump for your type of machine
unless we have an identical system---and if we do have one,
we should be able to reproduce the crash ourselves.
@end itemize

@node Service
@chapter How To Get Help with GNU Fortran

If you need help installing, using or changing GNU Fortran, there are two
ways to find it:

@itemize @bullet
@item
Look in the service directory for someone who might help you for a fee.
The service directory is found in the file named @file{SERVICE} in the
GNU CC distribution.

@item
Send a message to @email{@value{email-help}}.
@end itemize

@end ifset
@ifset INTERNALS
@node Adding Options
@chapter Adding Options
@cindex options, adding
@cindex adding options

To add a new command-line option to @command{g77}, first decide
what kind of option you wish to add.
Search the @command{g77} and @command{gcc} documentation for one
or more options that is most closely like the one you want to add
(in terms of what kind of effect it has, and so on) to
help clarify its nature.

@itemize @bullet
@item
@emph{Fortran options} are options that apply only
when compiling Fortran programs.
They are accepted by @command{g77} and @command{gcc}, but
they apply only when compiling Fortran programs.

@item
@emph{Compiler options} are options that apply
when compiling most any kind of program.
@end itemize

@emph{Fortran options} are listed in the file
@file{@value{path-g77}/lang-options.h},
which is used during the build of @command{gcc} to
build a list of all options that are accepted by
at least one language's compiler.
This list goes into the @code{documented_lang_options} array
in @file{gcc/toplev.c}, which uses this array to
determine whether a particular option should be
offered to the linked-in front end for processing
by calling @code{lang_option_decode}, which, for
@command{g77}, is in @file{@value{path-g77}/com.c} and just
calls @code{ffe_decode_option}.

If the linked-in front end ``rejects'' a
particular option passed to it, @file{toplev.c}
just ignores the option, because @emph{some}
language's compiler is willing to accept it.

This allows commands like @samp{gcc -fno-asm foo.c bar.f}
to work, even though Fortran compilation does
not currently support the @option{-fno-asm} option;
even though the @code{f771} version of @code{lang_decode_option}
rejects @option{-fno-asm}, @file{toplev.c} doesn't
produce a diagnostic because some other language (C)
does accept it.

This also means that commands like
@samp{g77 -fno-asm foo.f} yield no diagnostics,
despite the fact that no phase of the command was
able to recognize and process @option{-fno-asm}---perhaps
a warning about this would be helpful if it were
possible.

Code that processes Fortran options is found in
@file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
This code needs to check positive and negative forms
of each option.

The defaults for Fortran options are set in their
global definitions, also found in @file{@value{path-g77}/top.c}.
Many of these defaults are actually macros defined
in @file{@value{path-g77}/target.h}, since they might be
machine-specific.
However, since, in practice, GNU compilers
should behave the same way on all configurations
(especially when it comes to language constructs),
the practice of setting defaults in @file{target.h}
is likely to be deprecated and, ultimately, stopped
in future versions of @command{g77}.

Accessor macros for Fortran options, used by code
in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}.

@emph{Compiler options} are listed in @file{gcc/toplev.c}
in the array @code{f_options}.
An option not listed in @code{lang_options} is
looked up in @code{f_options} and handled from there.

The defaults for compiler options are set in the
global definitions for the corresponding variables,
some of which are in @file{gcc/toplev.c}.

You can set different defaults for @emph{Fortran-oriented}
or @emph{Fortran-reticent} compiler options by changing
the source code of @command{g77} and rebuilding.
How to do this depends on the version of @command{g77}:

@table @code
@item G77 0.5.24 (EGCS 1.1)
@itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.

(Note that these versions of @command{g77}
perform internal consistency checking automatically
when the @option{-fversion} option is specified.)

@item G77 0.5.23
@itemx G77 0.5.24 (EGCS 1.0)
Change the way @code{f771} handles the @option{-fset-g77-defaults}
option, which is always provided as the first option when
called by @command{g77} or @command{gcc}.

This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
Have it change just the variables that you want to default
to a different setting for Fortran compiles compared to
compiles of other languages.

The @option{-fset-g77-defaults} option is passed to @code{f771}
automatically because of the specification information
kept in @file{@value{path-g77}/lang-specs.h}.
This file tells the @command{gcc} command how to recognize,
in this case, Fortran source files (those to be preprocessed,
and those that are not), and further, how to invoke the
appropriate programs (including @code{f771}) to process
those source files.

It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults},
@option{-fversion}, and other options are passed, as appropriate,
even when the user has not explicitly specified them.
Other ``internal'' options such as @option{-quiet} also
are passed via this mechanism.
@end table

@node Projects
@chapter Projects
@cindex projects

If you want to contribute to @command{g77} by doing research,
design, specification, documentation, coding, or testing,
the following information should give you some ideas.
More relevant information might be available from
@uref{ftp://alpha.gnu.org/gnu/g77/projects/}.

@menu
* Efficiency::               Make @command{g77} itself compile code faster.
* Better Optimization::      Teach @command{g77} to generate faster code.
* Simplify Porting::         Make @command{g77} easier to configure, build,
                             and install.
* More Extensions::          Features many users won't know to ask for.
* Machine Model::            @command{g77} should better leverage @command{gcc}.
* Internals Documentation::  Make maintenance easier.
* Internals Improvements::   Make internals more robust.
* Better Diagnostics::       Make using @command{g77} on new code easier.
@end menu

@node Efficiency
@section Improve Efficiency
@cindex efficiency

Don't bother doing any performance analysis until most of the
following items are taken care of, because there's no question
they represent serious space/time problems, although some of
them show up only given certain kinds of (popular) input.

@itemize @bullet
@item
Improve @code{malloc} package and its uses to specify more info about
memory pools and, where feasible, use obstacks to implement them.

@item
Skip over uninitialized portions of aggregate areas (arrays,
@code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
This would reduce memory usage for large initialized aggregate
areas, even ones with only one initialized element.

As of version 0.5.18, a portion of this item has already been
accomplished.

@item
Prescan the statement (in @file{sta.c}) so that the nature of the statement
is determined as much as possible by looking entirely at its form,
and not looking at any context (previous statements, including types
of symbols).
This would allow ripping out of the statement-confirmation,
symbol retraction/confirmation, and diagnostic inhibition
mechanisms.
Plus, it would result in much-improved diagnostics.
For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
is not a subroutine intrinsic, would result actual error instead of the
unimplemented-statement catch-all.

@item
Throughout @command{g77}, don't pass line/column pairs where
a simple @code{ffewhere} type, which points to the error as much as is
desired by the configuration, will do, and don't pass @code{ffelexToken} types
where a simple @code{ffewhere} type will do.
Then, allow new default
configuration of @code{ffewhere} such that the source line text is not
preserved, and leave it to things like Emacs' next-error function
to point to them (now that @samp{next-error} supports column,
or, perhaps, character-offset, numbers).
The change in calling sequences should improve performance somewhat,
as should not having to save source lines.
(Whether this whole
item will improve performance is questionable, but it should
improve maintainability.)

@item
Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
as regards the assembly output.
Some of this might require improving
the back end, but lots of improvement in space/time required in @command{g77}
itself can be fairly easily obtained without touching the back end.
Maybe type-conversion, where necessary, can be speeded up as well in
cases like the one shown (converting the @samp{2} into @samp{2.}).

@item
If analysis shows it to be worthwhile, optimize @file{lex.c}.

@item
Consider redesigning @file{lex.c} to not need any feedback
during tokenization, by keeping track of enough parse state on its
own.
@end itemize

@node Better Optimization
@section Better Optimization
@cindex optimization, better
@cindex code generation, improving

Much of this work should be put off until after @command{g77} has
all the features necessary for its widespread acceptance as a
useful F77 compiler.
However, perhaps this work can be done in parallel during
the feature-adding work.

@itemize @bullet
@item
Do the equivalent of the trick of putting @samp{extern inline} in front
of every function definition in @code{libg2c} and #include'ing the resulting
file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions
that are at all worth inlining.
(Some of this has already been done, such as for integral exponentiation.)

@item
When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
and it's clear that types line up
and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
make @samp{CHAR_VAR}, not a
temporary, be the receiver for @samp{CHAR_FUNC}.
(This is now done for @code{COMPLEX} variables.)

@item
Design and implement Fortran-specific optimizations that don't
really belong in the back end, or where the front end needs to
give the back end more info than it currently does.

@item
Design and implement a new run-time library interface, with the
code going into @code{libgcc} so no special linking is required to
link Fortran programs using standard language features.
This library
would speed up lots of things, from I/O (using precompiled formats,
doing just one, or, at most, very few, calls for arrays or array sections,
and so on) to general computing (array/section implementations of
various intrinsics, implementation of commonly performed loops that
aren't likely to be optimally compiled otherwise, etc.).

Among the important things the library would do are:

@itemize @bullet
@item
Be a one-stop-shop-type
library, hence shareable and usable by all, in that what are now
library-build-time options in @code{libg2c} would be moved at least to the
@command{g77} compile phase, if not to finer grains (such as choosing how
list-directed I/O formatting is done by default at @code{OPEN} time, for
preconnected units via options or even statements in the main program
unit, maybe even on a per-I/O basis with appropriate pragma-like
devices).
@end itemize

@item
Probably requiring the new library design, change interface to
normally have @code{COMPLEX} functions return their values in the way
@command{gcc} would if they were declared @code{__complex__ float},
rather than using
the mechanism currently used by @code{CHARACTER} functions (whereby the
functions are compiled as returning void and their first arg is
a pointer to where to store the result).
(Don't append underscores to
external names for @code{COMPLEX} functions in some cases once @command{g77} uses
@command{gcc} rather than @command{f2c} calling conventions.)

@item
Do something useful with @code{doiter} references where possible.
For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
a @code{DO} loop that uses @samp{I} as the
iteration variable, and the back end might find that info useful
in determining whether it needs to read @samp{I} back into a register after
the call.
(It normally has to do that, unless it knows @samp{FOO} never
modifies its passed-by-reference argument, which is rarely the case
for Fortran-77 code.)
@end itemize

@node Simplify Porting
@section Simplify Porting
@cindex porting, simplify
@cindex simplify porting

Making @command{g77} easier to configure, port, build, and install, either
as a single-system compiler or as a cross-compiler, would be
very useful.

@itemize @bullet
@item
A new library (replacing @code{libg2c}) should improve portability as well as
produce more optimal code.
Further, @command{g77} and the new library should
conspire to simplify naming of externals, such as by removing unnecessarily
added underscores, and to reduce/eliminate the possibility of naming
conflicts, while making debugger more straightforward.

Also, it should
make multi-language applications more feasible, such as by providing
Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
descriptors.

@item
Possibly related to a new library, @command{g77} should produce the equivalent
of a @command{gcc} @samp{main(argc, argv)} function when it compiles a
main program unit, instead of compiling something that must be
called by a library
implementation of @code{main()}.

This would do many useful things such as
provide more flexibility in terms of setting up exception handling,
not requiring programmers to start their debugging sessions with
@kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.

@item
The GBE needs to understand the difference between alignment
requirements and desires.
For example, on Intel x86 machines, @command{g77} currently imposes
overly strict alignment requirements, due to the back end, but it
would be useful for Fortran and C programmers to be able to override
these @emph{recommendations} as long as they don't violate the actual
processor @emph{requirements}.
@end itemize

@node More Extensions
@section More Extensions
@cindex extensions, more

These extensions are not the sort of things users ask for ``by name'',
but they might improve the usability of @command{g77}, and Fortran in
general, in the long run.
Some of these items really pertain to improving @command{g77} internals
so that some popular extensions can be more easily supported.

@itemize @bullet
@item
Look through all the documentation on the GNU Fortran language,
dialects, compiler, missing features, bugs, and so on.
Many mentions of incomplete or missing features are
sprinkled throughout.
It is not worth repeating them here.

@item
Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
named and unnamed.
The idea is to provide a forward-looking, effective
replacement for things like the old-style @code{PARAMETER} statement
when people
really need typelessness in a maintainable, portable, clearly documented
way.
Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
and whatever else might come along.
(This is not really a call for polymorphism per se, just
an ability to express limited, syntactic polymorphism.)

@item
Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.

@item
Support arbitrary file unit numbers, instead of limiting them
to 0 through @samp{MXUNIT-1}.
(This is a @code{libg2c} issue.)

@item
@samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
@samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
later @code{UNIT=} in the first example is invalid.
Make sure this is what users of this feature would expect.

@item
Currently @command{g77} disallows @samp{READ(1'10)} since
it is an obnoxious syntax, but
supporting it might be pretty easy if needed.
More details are needed, such
as whether general expressions separated by an apostrophe are supported,
or maybe the record number can be a general expression, and so on.

@item
Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
fully.
Currently there is no support at all
for @code{%FILL} in @code{STRUCTURE} and related syntax,
whereas the rest of the
stuff has at least some parsing support.
This requires either major
changes to @code{libg2c} or its replacement.

@item
F90 and @command{g77} probably disagree about label scoping relative to
@code{INTERFACE} and @code{END INTERFACE}, and their contained
procedure interface bodies (blocks?).

@item
@code{ENTRY} doesn't support F90 @code{RESULT()} yet,
since that was added after S8.112.

@item
Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
with the final form of the standard (it was vague at S8.112).

@item
It seems to be an ``open'' question whether a file, immediately after being
@code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
might be nice to offer an option of opening to ``undefined'' status, requiring
an explicit absolute-positioning operation to be performed before any
other (besides @code{CLOSE}) to assist in making applications port to systems
(some IBM?) that @code{OPEN} to the end of a file or some such thing.
@end itemize

@node Machine Model
@section Machine Model

This items pertain to generalizing @command{g77}'s view of
the machine model to more fully accept whatever the GBE
provides it via its configuration.

@itemize @bullet
@item
Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
exclusively so the target float format need not be required.
This
means changing the way @command{g77} handles initialization of aggregate areas
having more than one type, such as @code{REAL} and @code{INTEGER},
because currently
it initializes them as if they were arrays of @code{char} and uses the
bit patterns of the constants of the various types in them to determine
what to stuff in elements of the arrays.

@item
Rely more and more on back-end info and capabilities, especially in the
area of constants (where having the @command{g77} front-end's IL just store
the appropriate tree nodes containing constants might be best).

@item
Suite of C and Fortran programs that a user/administrator can run on a
machine to help determine the configuration for @command{g77} before building
and help determine if the compiler works (especially with whatever
libraries are installed) after building.
@end itemize

@node Internals Documentation
@section Internals Documentation

Better info on how @command{g77} works and how to port it is needed.

@xref{Front End}, which contains some information
on @command{g77} internals.

@node Internals Improvements
@section Internals Improvements

Some more items that would make @command{g77} more reliable
and easier to maintain:

@itemize @bullet
@item
Generally make expression handling focus
more on critical syntax stuff, leaving semantics to callers.
For example,
anything a caller can check, semantically, let it do so, rather
than having @file{expr.c} do it.
(Exceptions might include things like
diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
it seems
important to preserve the left-to-right-in-source order of production
of diagnostics.)

@item
Come up with better naming conventions for @option{-D} to establish requirements
to achieve desired implementation dialect via @file{proj.h}.

@item
Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.

@item
Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.

@item
Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
(after determining if there is indeed no real need for it).

@item
Utility to read and check @file{bad.def} messages and their references in the
code, to make sure calls are consistent with message templates.

@item
Search and fix @samp{&ffe@dots{}} and similar so that
@samp{ffe@dots{}ptr@dots{}} macros are
available instead (a good argument for wishing this could have written all
this stuff in C++, perhaps).
On the other hand, it's questionable whether this sort of
improvement is really necessary, given the availability of
tools such as Emacs and Perl, which make finding any
address-taking of structure members easy enough?

@item
Some modules truly export the member names of their structures (and the
structures themselves), maybe fix this, and fix other modules that just
appear to as well (by appending @samp{_}, though it'd be ugly and probably
not worth the time).

@item
Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
in @file{proj.h}
and use them throughout @command{g77} source code (especially in the definitions
of access macros in @samp{.h} files) so they can be tailored
to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.

@item
Decorate throughout with @code{const} and other such stuff.

@item
All F90 notational derivations in the source code are still based
on the S8.112 version of the draft standard.
Probably should update
to the official standard, or put documentation of the rules as used
in the code@dots{}uh@dots{}in the code.

@item
Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
inside but invoked via paths not involving @code{ffeexpr_lhs} or
@code{ffeexpr_rhs}) might be creating things
in improper pools, leading to such things staying around too long or
(doubtful, but possible and dangerous) not long enough.

@item
Some @code{ffebld_list_new} (or whatever) calls might not be matched by
@code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
(It definitely is not a problem just yet.)

@item
Probably not doing clean things when we fail to @code{EQUIVALENCE} something
due to alignment/mismatch or other problems---they end up without
@code{ffestorag} objects, so maybe the backend (and other parts of the front
end) can notice that and handle like an @code{opANY} (do what it wants, just
don't complain or crash).
Most of this seems to have been addressed
by now, but a code review wouldn't hurt.
@end itemize

@node Better Diagnostics
@section Better Diagnostics

These are things users might not ask about, or that need to
be looked into, before worrying about.
Also here are items that involve reducing unnecessary diagnostic
clutter.

@itemize @bullet
@item
When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
lengths, type classes, and so on),
@code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
it specifies.

@item
Speed up and improve error handling for data when repeat-count is
specified.
For example, don't output 20 unnecessary messages after the
first necessary one for:

@smallexample
INTEGER X(20)
CONTINUE
DATA (X(I), J= 1, 20) /20*5/
END
@end smallexample

@noindent
(The @code{CONTINUE} statement ensures the @code{DATA} statement
is processed in the context of executable, not specification,
statements.)
@end itemize

@include ffe.texi

@end ifset

@ifset USING
@node Diagnostics
@chapter Diagnostics
@cindex diagnostics

Some diagnostics produced by @command{g77} require sufficient explanation
that the explanations are given below, and the diagnostics themselves
identify the appropriate explanation.

Identification uses the GNU Info format---specifically, the @command{info}
command that displays the explanation is given within square
brackets in the diagnostic.
For example:

@smallexample
foo.f:5: Invalid statement [info -f g77 M FOOEY]
@end smallexample

More details about the above diagnostic is found in the @command{g77} Info
documentation, menu item @samp{M}, submenu item @samp{FOOEY},
which is displayed by typing the UNIX command
@samp{info -f g77 M FOOEY}.

Other Info readers, such as EMACS, may be just as easily used to display
the pertinent node.
In the above example, @samp{g77} is the Info document name,
@samp{M} is the top-level menu item to select,
and, in that node (named @samp{Diagnostics}, the name of
this chapter, which is the very text you're reading now),
@samp{FOOEY} is the menu item to select.

@iftex
In this printed version of the @command{g77} manual, the above example
points to a section, below, entitled @samp{FOOEY}---though, of course,
as the above is just a sample, no such section exists.
@end iftex

@menu
* CMPAMBIG::    Ambiguous use of intrinsic.
* EXPIMP::      Intrinsic used explicitly and implicitly.
* INTGLOB::     Intrinsic also used as name of global.
* LEX::         Various lexer messages
* GLOBALS::     Disagreements about globals.
* LINKFAIL::    When linking @code{f771} fails.
* Y2KBAD::      Use of non-Y2K-compliant intrinsic.
@end menu

@node CMPAMBIG
@section @code{CMPAMBIG}

@noindent
@smallexample
Ambiguous use of intrinsic @var{intrinsic} @dots{}
@end smallexample

The type of the argument to the invocation of the @var{intrinsic}
intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
Typically, it is @code{COMPLEX(KIND=2)}, also known as
@code{DOUBLE COMPLEX}.

The interpretation of this invocation depends on the particular
dialect of Fortran for which the code was written.
Some dialects convert the real part of the argument to
@code{REAL(KIND=1)}, thus losing precision; other dialects,
and Fortran 90, do no such conversion.

So, GNU Fortran rejects such invocations except under certain
circumstances, to avoid making an incorrect assumption that results
in generating the wrong code.

To determine the dialect of the program unit, perhaps even whether
that particular invocation is properly coded, determine how the
result of the intrinsic is used.

The result of @var{intrinsic} is expected (by the original programmer)
to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:

@itemize @bullet
@item
It is passed as an argument to a procedure that explicitly or
implicitly declares that argument @code{REAL(KIND=1)}.

For example,
a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
statement specifying the dummy argument corresponding to an
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
of @code{REAL(KIND=2)}.

@item
It is used in a context that would otherwise not include
any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
invocation as @code{REAL(KIND=2)} would result in unnecessary
promotions and (typically) more expensive operations on the
wider type.

For example:

@smallexample
DOUBLE COMPLEX Z
@dots{}
R(1) = T * REAL(Z)
@end smallexample

The above example suggests the programmer expected the real part
of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
multiplied by @samp{T} (presumed, along with @samp{R} above, to
be type @code{REAL(KIND=1)}).

Otherwise, the conversion would have to be delayed until after
the multiplication, requiring not only an extra conversion
(of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
expensive multiplication (a double-precision multiplication instead
of a single-precision one).
@end itemize

The result of @var{intrinsic} is expected (by the original programmer)
to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:

@itemize @bullet
@item
It is passed as an argument to a procedure that explicitly or
implicitly declares that argument @code{REAL(KIND=2)}.

For example, a procedure specifying a @code{DOUBLE PRECISION}
dummy argument corresponding to an
actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
@code{DOUBLE COMPLEX}, strongly suggests that the programmer
expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
of @code{REAL(KIND=1)}.

@item
It is used in an expression context that includes
other @code{REAL(KIND=2)} operands,
or is assigned to a @code{REAL(KIND=2)} variable or array element.

For example:

@smallexample
DOUBLE COMPLEX Z
DOUBLE PRECISION R, T
@dots{}
R(1) = T * REAL(Z)
@end smallexample

The above example suggests the programmer expected the real part
of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
by the @code{REAL()} intrinsic.

Otherwise, the conversion would have to be immediately followed
by a conversion back to @code{REAL(KIND=2)}, losing
the original, full precision of the real part of @code{Z},
before being multiplied by @samp{T}.
@end itemize

Once you have determined whether a particular invocation of @var{intrinsic}
expects the Fortran 90 interpretation, you can:

@itemize @bullet
@item
Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
@code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
is @code{AIMAG})
if it expected the Fortran 90 interpretation.

This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
some other type, such as @code{COMPLEX*32}, you should use the
appropriate intrinsic, such as the one to convert to @code{REAL*16}
(perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
@code{QIMAG()} in place of @code{DIMAG()}).

@item
Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
otherwise.
This converts to @code{REAL(KIND=1)} in all working
Fortran compilers.
@end itemize

If you don't want to change the code, and you are certain that all
ambiguous invocations of @var{intrinsic} in the source file have
the same expectation regarding interpretation, you can:

@itemize @bullet
@item
Compile with the @command{g77} option @option{-ff90}, to enable the
Fortran 90 interpretation.

@item
Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex},
to enable the non-Fortran-90 interpretations.
@end itemize

@xref{REAL() and AIMAG() of Complex}, for more information on this
issue.

Note: If the above suggestions don't produce enough evidence
as to whether a particular program expects the Fortran 90
interpretation of this ambiguous invocation of @var{intrinsic},
there is one more thing you can try.

If you have access to most or all the compilers used on the
program to create successfully tested and deployed executables,
read the documentation for, and @emph{also} test out, each compiler
to determine how it treats the @var{intrinsic} intrinsic in
this case.
(If all the compilers don't agree on an interpretation, there
might be lurking bugs in the deployed versions of the program.)

The following sample program might help:

@cindex JCB003 program
@smallexample
      PROGRAM JCB003
C
C Written by James Craig Burley 1997-02-23.
C
C Determine how compilers handle non-standard REAL
C and AIMAG on DOUBLE COMPLEX operands.
C
      DOUBLE COMPLEX Z
      REAL R
      Z = (3.3D0, 4.4D0)
      R = Z
      CALL DUMDUM(Z, R)
      R = REAL(Z) - R
      IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
      R = 4.4D0
      CALL DUMDUM(Z, R)
      R = AIMAG(Z) - R
      IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
      IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
      END
C
C Just to make sure compiler doesn't use naive flow
C analysis to optimize away careful work above,
C which might invalidate results....
C
      SUBROUTINE DUMDUM(Z, R)
      DOUBLE COMPLEX Z
      REAL R
      END
@end smallexample

If the above program prints contradictory results on a
particular compiler, run away!

@node EXPIMP
@section @code{EXPIMP}

@noindent
@smallexample
Intrinsic @var{intrinsic} referenced @dots{}
@end smallexample

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

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

After verifying that the program unit making implicit use
of the intrinsic is indeed written expecting the intrinsic,
add an @samp{INTRINSIC @var{intrinsic}} statement to that
program unit to prevent this warning.

This and related warnings are disabled by using
the @option{-Wno-globals} option when compiling.

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

@node INTGLOB
@section @code{INTGLOB}

@noindent
@smallexample
Same name `@var{intrinsic}' given @dots{}
@end smallexample

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

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

For example:

@smallexample
INTEGER FUNCTION TIME()
@dots{}
END
@dots{}
PROGRAM SAMP
INTEGER TIME
PRINT *, 'Time is ', TIME()
END
@end smallexample

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

As a result, the program @samp{SAMP} will @emph{not}
invoke the @samp{TIME} function in the same source file.

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

After verifying that the program unit making implicit use
of the intrinsic is indeed written expecting the intrinsic,
add an @samp{INTRINSIC @var{intrinsic}} statement to that
program unit to prevent this warning.

Or, if you believe the program unit is designed to invoke the
program-defined procedure instead of the intrinsic (as
recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}}
statement to the program unit that references the name to
prevent this warning.

This and related warnings are disabled by using
the @option{-Wno-globals} option when compiling.

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

@node LEX
@section @code{LEX}

@noindent
@smallexample
Unrecognized character @dots{}
Invalid first character @dots{}
Line too long @dots{}
Non-numeric character @dots{}
Continuation indicator @dots{}
Label at @dots{} invalid with continuation line indicator @dots{}
Character constant @dots{}
Continuation line @dots{}
Statement at @dots{} begins with invalid token
@end smallexample

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

@itemize @bullet
@item
The source file contains something other than Fortran code.

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

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

@item
The source file contains free-form Fortran code, but @option{-ffree-form}
was not specified on the command line to compile it.

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

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

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

@xref{Source Form}, for more information.

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

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

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

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

The result of editing the above line might be:

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

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

@emph{Replacing} the @samp{C} in column 1 with a space
is the proper change to make, to ensure the @code{CALL}
keyword starts in or after column 7.

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

@xref{Source Form}, for more information.

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

A source file containing lines beginning with @code{#define},
@code{#include}, @code{#if}, and so on is likely one that
requires preprocessing.

If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
the file normally will be compiled @emph{without} preprocessing
by @command{g77}.

Change the file's suffix from @samp{.f} to @samp{.F}
(or, on systems with case-insensitive file names,
to @samp{.fpp} or @samp{.FPP}),
from @samp{.for} to @samp{.fpp},
or from @samp{.FOR} to @samp{.FPP}.
@command{g77} compiles files with such names @emph{with}
preprocessing.

@pindex cpp
@cindex preprocessor
@cindex cpp program
@cindex programs, cpp
@cindex @option{-x f77-cpp-input} option
@cindex options, @option{-x f77-cpp-input}
Or, learn how to use @command{gcc}'s @option{-x} option to specify
the language @samp{f77-cpp-input} for Fortran files that
require preprocessing.
@xref{Overall Options,,Options Controlling the Kind of
Output,gcc,Using the GNU Compiler Collection (GCC)}.

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

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

@xref{Overall Options,,Options Controlling the Kind of Output},
for suggestions about how to use, and not use, preprocessing
for Fortran code.
@end itemize

@node GLOBALS
@section @code{GLOBALS}

@noindent
@smallexample
Global name @var{name} defined at @dots{} already defined@dots{}
Global name @var{name} at @dots{} has different type@dots{}
Too many arguments passed to @var{name} at @dots{}
Too few arguments passed to @var{name} at @dots{}
Argument #@var{n} of @var{name} is @dots{}
@end smallexample

These messages all identify disagreements about the
global procedure named @var{name} among different program units
(usually including @var{name} itself).

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

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

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

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

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

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

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

@node LINKFAIL
@section @code{LINKFAIL}

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

Compiling with @option{-mminimal-toc}
might solve this problem, e.g.@: by adding
@smallexample
BOOT_CFLAGS='-mminimal-toc -O2 -g'
@end smallexample
to the @code{make bootstrap} command line.

@node Y2KBAD
@section @code{Y2KBAD}
@cindex Y2K compliance
@cindex Year 2000 compliance

@noindent
@smallexample
Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
@end smallexample

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

@xref{Year 2000 (Y2K) Problems}.

@end ifset

@node Keyword Index
@unnumbered Keyword Index

@printindex cp
@bye