path: root/gnu/usr.bin/gcc/f/g77.texi

\input texinfo  @c -*-texinfo-*-
@c fix @set inside @example:
@tex
\gdef\set{\begingroup\catcode` =10 \parsearg\setxxx}
\gdef\setyyy#1 #2\endsetyyy{%
  \def\temp{#2}%
  \ifx\temp\empty \global\expandafter\let\csname SET#1\endcsname = \empty
  \else \setzzz{#1}#2\endsetzzz % Remove the trailing space \setxxx inserted.
  \fi
  \endgroup
}
@end tex

@c %**start of header 
@setfilename g77.info
@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 (For FSF printing, turn on smallbook; that is all that is needed.)

@c smallbook

@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
@setchapternewpage odd

@ifinfo
This file explains how to use the GNU Fortran system.

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

Copyright (C) 1995, 1996 Free Software Foundation, Inc.

Permission is granted to make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

@ignore
Permission is granted to process this file through Tex and print the
results, provided the printed document carries copying permission
notice identical to this one except for the removal of this paragraph
(this paragraph not being relevant to the printed manual).

@end ignore
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled ``GNU General Public License,'' ``Funding for Free
Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the sections entitled ``GNU General Public License,''
``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
And Feel'@w{}'', and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.
@end ifinfo

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

@finalout
@titlepage
@comment The title is printed in a large font.
@center @titlefont{Using GNU Fortran}
@sp 2
@center James Craig Burley
@sp 3
@center Last updated 1996-03-23
@sp 1
@c The version number appears some more times in this file.

@center for version 0.5.18
@page
@vskip 0pt plus 1filll
Copyright @copyright{} 1995, 1996 Free Software Foundation, Inc.
@sp 2
For GNU Fortran Version 0.5.18*
@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 make and distribute verbatim copies of
this manual provided the copyright notice and this permission notice
are preserved on all copies.

Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided also that the
sections entitled ``GNU General Public License,'' ``Funding for Free
Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
included exactly as in the original, and provided that the entire
resulting derived work is distributed under the terms of a permission
notice identical to this one.

Permission is granted to copy and distribute translations of this manual
into another language, under the above conditions for modified versions,
except that the sections entitled ``GNU General Public License,''
``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
And Feel'@w{}'', and this permission notice, may be included in
translations approved by the Free Software Foundation instead of in the
original English.
@end titlepage
@page

@ifinfo

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

@ifset INTERNALS
@ifset USING
This manual documents how to run, install and port the GNU Fortran
compiler, as well as its new features and incompatibilities, and how to
report bugs.  It corresponds to GNU Fortran version 0.5.18.
@end ifset
@end ifset

@ifclear INTERNALS
This manual documents how to run and install the GNU Fortran compiler,
as well as its new features and incompatibilities, and how to report
bugs.  It corresponds to GNU Fortran version 0.5.18.
@end ifclear
@ifclear USING
This manual documents how to port the GNU Fortran compiler,
as well as its new features and incompatibilities, and how to report
bugs.  It corresponds to GNU Fortran version 0.5.18.
@end ifclear

@end ifinfo
@menu
* Copying::         GNU General Public License says
                    how you can copy and share GNU Fortran.
* 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.
* Look and Feel::   Protect your freedom---fight ``look and feel''.
@ifset USING
* Getting Started:: Finding your way around this manual.
* What is GNU Fortran?::  How @code{g77} fits into the universe.
* G77 and GCC::     You can compile Fortran, C, or other programs.
* Invoking G77::    Command options supported by @code{g77}.
* News::            News about recent releases of @code{g77}.
* Changes::         User-visible changes to recent releases of @code{g77}.
* Language::        The GNU Fortran language.
* Installation::    How to configure, compile and install GNU Fortran.
* Debugging and Interfacing::  How @code{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 @code{g77} about new options.
* Projects::        Projects for @code{g77} internals hackers.
@end ifset

* Index::	    Index of concepts and symbol names.
@end menu

@node Copying
@unnumbered GNU GENERAL PUBLIC LICENSE
@center Version 2, June 1991

@display
Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA

Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.
@end display

@unnumberedsec Preamble

  The licenses for most software are designed to take away your
freedom to share and change it.  By contrast, the GNU General Public
License is intended to guarantee your freedom to share and change free
software---to make sure the software is free for all its users.  This
General Public License applies to most of the Free Software
Foundation's software and to any other program whose authors commit to
using it.  (Some other Free Software Foundation software is covered by
the GNU Library General Public License instead.)  You can apply it to
your programs, too.

  When we speak of free software, we are referring to freedom, not
price.  Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
this service if you wish), that you receive source code or can get it
if you want it, that you can change the software or use pieces of it
in new free programs; and that you know you can do these things.

  To protect your rights, we need to make restrictions that forbid
anyone to deny you these rights or to ask you to surrender the rights.
These restrictions translate to certain responsibilities for you if you
distribute copies of the software, or if you modify it.

  For example, if you distribute copies of such a program, whether
gratis or for a fee, you must give the recipients all the rights that
you have.  You must make sure that they, too, receive or can get the
source code.  And you must show them these terms so they know their
rights.

  We protect your rights with two steps: (1) copyright the software, and
(2) offer you this license which gives you legal permission to copy,
distribute and/or modify the software.

  Also, for each author's protection and ours, we want to make certain
that everyone understands that there is no warranty for this free
software.  If the software is modified by someone else and passed on, we
want its recipients to know that what they have is not the original, so
that any problems introduced by others will not reflect on the original
authors' reputations.

  Finally, any free program is threatened constantly by software
patents.  We wish to avoid the danger that redistributors of a free
program will individually obtain patent licenses, in effect making the
program proprietary.  To prevent this, we have made it clear that any
patent must be licensed for everyone's free use or not licensed at all.

  The precise terms and conditions for copying, distribution and
modification follow.

@iftex
@unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@end iftex
@ifinfo
@center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
@end ifinfo

@enumerate 0
@item
This License applies to any program or other work which contains
a notice placed by the copyright holder saying it may be distributed
under the terms of this General Public License.  The ``Program'', below,
refers to any such program or work, and a ``work based on the Program''
means either the Program or any derivative work under copyright law:
that is to say, a work containing the Program or a portion of it,
either verbatim or with modifications and/or translated into another
language.  (Hereinafter, translation is included without limitation in
the term ``modification''.)  Each licensee is addressed as ``you''.

Activities other than copying, distribution and modification are not
covered by this License; they are outside its scope.  The act of
running the Program is not restricted, and the output from the Program
is covered only if its contents constitute a work based on the
Program (independent of having been made by running the Program).
Whether that is true depends on what the Program does.

@item
You may copy and distribute verbatim copies of the Program's
source code as you receive it, in any medium, provided that you
conspicuously and appropriately publish on each copy an appropriate
copyright notice and disclaimer of warranty; keep intact all the
notices that refer to this License and to the absence of any warranty;
and give any other recipients of the Program a copy of this License
along with the Program.

You may charge a fee for the physical act of transferring a copy, and
you may at your option offer warranty protection in exchange for a fee.

@item
You may modify your copy or copies of the Program or any portion
of it, thus forming a work based on the Program, and copy and
distribute such modifications or work under the terms of Section 1
above, provided that you also meet all of these conditions:

@enumerate a
@item
You must cause the modified files to carry prominent notices
stating that you changed the files and the date of any change.

@item
You must cause any work that you distribute or publish, that in
whole or in part contains or is derived from the Program or any
part thereof, to be licensed as a whole at no charge to all third
parties under the terms of this License.

@item
If the modified program normally reads commands interactively
when run, you must cause it, when started running for such
interactive use in the most ordinary way, to print or display an
announcement including an appropriate copyright notice and a
notice that there is no warranty (or else, saying that you provide
a warranty) and that users may redistribute the program under
these conditions, and telling the user how to view a copy of this
License.  (Exception: if the Program itself is interactive but
does not normally print such an announcement, your work based on
the Program is not required to print an announcement.)
@end enumerate

These requirements apply to the modified work as a whole.  If
identifiable sections of that work are not derived from the Program,
and can be reasonably considered independent and separate works in
themselves, then this License, and its terms, do not apply to those
sections when you distribute them as separate works.  But when you
distribute the same sections as part of a whole which is a work based
on the Program, the distribution of the whole must be on the terms of
this License, whose permissions for other licensees extend to the
entire whole, and thus to each and every part regardless of who wrote it.

Thus, it is not the intent of this section to claim rights or contest
your rights to work written entirely by you; rather, the intent is to
exercise the right to control the distribution of derivative or
collective works based on the Program.

In addition, mere aggregation of another work not based on the Program
with the Program (or with a work based on the Program) on a volume of
a storage or distribution medium does not bring the other work under
the scope of this License.

@item
You may copy and distribute the Program (or a work based on it,
under Section 2) in object code or executable form under the terms of
Sections 1 and 2 above provided that you also do one of the following:

@enumerate a
@item
Accompany it with the complete corresponding machine-readable
source code, which must be distributed under the terms of Sections
1 and 2 above on a medium customarily used for software interchange; or,

@item
Accompany it with a written offer, valid for at least three
years, to give any third party, for a charge no more than your
cost of physically performing source distribution, a complete
machine-readable copy of the corresponding source code, to be
distributed under the terms of Sections 1 and 2 above on a medium
customarily used for software interchange; or,

@item
Accompany it with the information you received as to the offer
to distribute corresponding source code.  (This alternative is
allowed only for noncommercial distribution and only if you
received the program in object code or executable form with such
an offer, in accord with Subsection b above.)
@end enumerate

The source code for a work means the preferred form of the work for
making modifications to it.  For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.  However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.

If distribution of executable or object code is made by offering
access to copy from a designated place, then offering equivalent
access to copy the source code from the same place counts as
distribution of the source code, even though third parties are not
compelled to copy the source along with the object code.

@item
You may not copy, modify, sublicense, or distribute the Program
except as expressly provided under this License.  Any attempt
otherwise to copy, modify, sublicense or distribute the Program is
void, and will automatically terminate your rights under this License.
However, parties who have received copies, or rights, from you under
this License will not have their licenses terminated so long as such
parties remain in full compliance.

@item
You are not required to accept this License, since you have not
signed it.  However, nothing else grants you permission to modify or
distribute the Program or its derivative works.  These actions are
prohibited by law if you do not accept this License.  Therefore, by
modifying or distributing the Program (or any work based on the
Program), you indicate your acceptance of this License to do so, and
all its terms and conditions for copying, distributing or modifying
the Program or works based on it.

@item
Each time you redistribute the Program (or any work based on the
Program), the recipient automatically receives a license from the
original licensor to copy, distribute or modify the Program subject to
these terms and conditions.  You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties to
this License.

@item
If, as a consequence of a court judgment or allegation of patent
infringement or for any other reason (not limited to patent issues),
conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot
distribute so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you
may not distribute the Program at all.  For example, if a patent
license would not permit royalty-free redistribution of the Program by
all those who receive copies directly or indirectly through you, then
the only way you could satisfy both it and this License would be to
refrain entirely from distribution of the Program.

If any portion of this section is held invalid or unenforceable under
any particular circumstance, the balance of the section is intended to
apply and the section as a whole is intended to apply in other
circumstances.

It is not the purpose of this section to induce you to infringe any
patents or other property right claims or to contest validity of any
such claims; this section has the sole purpose of protecting the
integrity of the free software distribution system, which is
implemented by public license practices.  Many people have made
generous contributions to the wide range of software distributed
through that system in reliance on consistent application of that
system; it is up to the author/donor to decide if he or she is willing
to distribute software through any other system and a licensee cannot
impose that choice.

This section is intended to make thoroughly clear what is believed to
be a consequence of the rest of this License.

@item
If the distribution and/or use of the Program is restricted in
certain countries either by patents or by copyrighted interfaces, the
original copyright holder who places the Program under this License
may add an explicit geographical distribution limitation excluding
those countries, so that distribution is permitted only in or among
countries not thus excluded.  In such case, this License incorporates
the limitation as if written in the body of this License.

@item
The Free Software Foundation may publish revised and/or new versions
of the General Public License from time to time.  Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.

Each version is given a distinguishing version number.  If the Program
specifies a version number of this License which applies to it and ``any
later version'', you have the option of following the terms and conditions
either of that version or of any later version published by the Free
Software Foundation.  If the Program does not specify a version number of
this License, you may choose any version ever published by the Free Software
Foundation.

@item
If you wish to incorporate parts of the Program into other free
programs whose distribution conditions are different, write to the author
to ask for permission.  For software which is copyrighted by the Free
Software Foundation, write to the Free Software Foundation; we sometimes
make exceptions for this.  Our decision will be guided by the two goals
of preserving the free status of all derivatives of our free software and
of promoting the sharing and reuse of software generally.

@iftex
@heading NO WARRANTY
@end iftex
@ifinfo
@center NO WARRANTY
@end ifinfo

@item
BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW.  EXCEPT WHEN
OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.  THE ENTIRE RISK AS
TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE
PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
REPAIR OR CORRECTION.

@item
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.
@end enumerate

@iftex
@heading END OF TERMS AND CONDITIONS
@end iftex
@ifinfo
@center END OF TERMS AND CONDITIONS
@end ifinfo

@page
@unnumberedsec How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
convey the exclusion of warranty; and each file should have at least
the ``copyright'' line and a pointer to where the full notice is found.

@smallexample
@var{one line to give the program's name and a brief idea of what it does.}
Copyright (C) 19@var{yy}  @var{name of author}

This program is free software; you can redistribute it and/or modify 
it under the terms of the GNU General Public License as published by 
the Free Software Foundation; either version 2 of the License, or 
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
@end smallexample

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this
when it starts in an interactive mode:

@smallexample
Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
type `show w'.  
This is free software, and you are welcome to redistribute it 
under certain conditions; type `show c' for details.
@end smallexample

The hypothetical commands @samp{show w} and @samp{show c} should show
the appropriate parts of the General Public License.  Of course, the
commands you use may be called something other than @samp{show w} and
@samp{show c}; they could even be mouse-clicks or menu items---whatever
suits your program.

You should also get your employer (if you work as a programmer) or your
school, if any, to sign a ``copyright disclaimer'' for the program, if
necessary.  Here is a sample; alter the names:

@smallexample
Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.

@var{signature of Ty Coon}, 1 April 1989
Ty Coon, President of Vice
@end smallexample

This General Public License does not permit incorporating your program into
proprietary programs.  If your program is a subroutine library, you may
consider it more useful to permit linking proprietary applications with the
library.  If this is what you want to do, use the GNU Library General
Public License instead of this License.

@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 GNU CC,gcc,Using and Porting GNU CC},
for more information.

@item
The run-time library used by GNU Fortran is a minor repackaging
of the @code{libf2c} library (combined from the @code{libF77} and
@code{libI77} libraries) provided as part of @code{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 @code{g77}'s
public release.  This work consisted of testing, researching, sometimes
debugging, and occasionally providing small amounts of code and fixes
for @code{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)---@code{takafumi@@u-aizu.ac.jp}
@item
Kate Hedstrom
@item
Michel Kern (INRIA and Rice University)---@code{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
Scott Snyder (@code{snyder@@d0sgif.fnal.gov})
provided the patch to add rudimentary support
for @samp{INTEGER*1}, @samp{INTEGER*2}, and
@samp{LOGICAL*1}.
This inspired Craig to add further support,
even though the resulting support
would still be incomplete, because version 0.6 is still
a ways off.

@item
David Ronis (@code{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 @code{g77-0.5.16/f/DOC} file.

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

@item
Many other individuals have helped debug, test, and improve @code{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

@node Funding
@chapter Funding Free Software

If you want to have more free software a few years from now, it makes
sense for you to help encourage people to contribute funds for its
development.  The most effective approach known is to encourage
commercial redistributors to donate.

Users of free software systems can boost the pace of development by
encouraging for-a-fee distributors to donate part of their selling price
to free software developers---the Free Software Foundation, and others.

The way to convince distributors to do this is to demand it and expect
it from them.  So when you compare distributors, judge them partly by
how much they give to free software development.  Show distributors
they must compete to be the one who gives the most.

To make this approach work, you must insist on numbers that you can
compare, such as, ``We will donate ten dollars to the Frobnitz project
for each disk sold.''  Don't be satisfied with a vague promise, such as
``A portion of the profits are donated,'' since it doesn't give a basis
for comparison.

Even a precise fraction ``of the profits from this disk'' is not very
meaningful, since creative accounting and unrelated business decisions
can greatly alter what fraction of the sales price counts as profit.
If the price you pay is $50, ten percent of the profit is probably
less than a dollar; it might be a few cents, or nothing at all.

Some redistributors do development work themselves.  This is useful too;
but to keep everyone honest, you need to inquire how much they do, and
what kind.  Some kinds of development make much more long-term
difference than others.  For example, maintaining a separate version of
a program contributes very little; maintaining the standard version of a
program for the whole community contributes much.  Easy new ports
contribute little, since someone else would surely do them; difficult
ports such as adding a new CPU to the GNU C compiler contribute more;
major new features or packages contribute the most.

By establishing the idea that supporting further development is ``the
proper thing to do'' when distributing free software for a fee, we can
assure a steady flow of resources into making more free software.

@display
Copyright (C) 1994 Free Software Foundation, Inc.
Verbatim copying and redistribution of this section is permitted
without royalty; alteration is not permitted.
@end display

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

Work on GNU Fortran is still being done mostly by its author,
James Craig Burley (@code{burley@@gnu.ai.mit.edu}), who is a volunteer
for, not an employee of, the Free Software Foundation (FSF).
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 @code{gnu@@prep.ai.mit.edu} for information on funding the FSF.

To fund specific GNU Fortran work in particular, the FSF might
provide a means for that, but the FSF does not provide direct funding
to the author of GNU Fortran to continue his work.  The FSF has
employee salary restrictions that can be incompatible with the
financial needs of some volunteers, who therefore choose to
remain volunteers and thus be able to be free to do contract work
and otherwise make their own schedules for doing GNU work.

Still, funding the FSF at least indirectly benefits work
on specific projects like GNU Fortran because it ensures the
continuing operation of the FSF offices, their workstations, their
network connections, and so on, which are invaluable to volunteers.
(Similarly, hiring Cygnus Support can help a project like GNU
Fortran---Cygnus has been a long-time donor of equipment usage to the author
of GNU Fortran, and this too has been invaluable---@xref{Contributors}.)

Currently, the only way to directly fund the author of GNU Fortran
in his work on that project is to hire him for the work you want
him to do, or donate money to him.
Several people have done this
already, with the result that he has not needed to immediately find
contract work on a few occasions.
If more people did this, he
would be able to plan on not doing contract work for many months and
could thus devote that time to work on projects (such as the planned
changes for @code{g77-0.6}) that require longer timeframes to complete.
For the latest information on the status of the author, do
@samp{finger -l burley@@gnu.ai.mit.edu}, i.e. access @code{burley}'s
@code{.plan} file just as you would @code{fortran}'s to get @code{g77}
status (except there's no public @code{ftp} access to @code{burley}'s
@code{.plan} file---you can email him asking for it).

Another important way to support work on GNU Fortran is to volunteer
to help out.
Work is needed on documentation, testing, porting
to various machines, and in some cases, coding (although major
changes planned for version 0.6 make it difficult to add manpower to this
area).
Email @code{fortran@@gnu.ai.mit.edu} to volunteer for this work.

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

@node Look and Feel
@chapter Protect Your Freedom---Fight ``Look And Feel''
@c the above chapter heading overflows onto the next line. --mew 1/26/93 

To preserve the ability to write free software, including replacements
for proprietary software, authors must be free to replicate the
user interface to which users of existing software have become
accustomed.

@xref{Look and Feel,,Protect Your Freedom---Fight ``Look And Feel'',
gcc,Using and Porting GNU CC}, 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 @code{gcc},
you should see @ref{G77 and GCC}.

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

If you're acquainted with previous versions of @code{g77},
you should see @ref{News}.
Further, if you've actually used previous versions of @code{g77},
especially if you've written or modified Fortran code to
be compiled by previous versions of @code{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 don't already have @code{g77} installed on your
system, you must see @ref{Installation}.

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 @code{g77}---see @ref{Bugs}, for information on
reporting them, after reading the other material.

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

If you would like to help the @code{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
@code{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 @code{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 @code{g77}, is designed initially as a free replacement
for, or alternative to, the UNIX @code{f77} command.
(Similarly, @code{gcc} is designed as a replacement
for the UNIX @code{cc} command.)

@code{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, @code{g77}, @code{gcc}, and @code{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
@cindex gdb command
@cindex commands, 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 @code{gdb}).

@cindex libraries
@cindex linking
@cindex ld command
@cindex commands, 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
@code{ld} command.
However, the @code{g77} and @code{gcc}
commands, as with most compiler commands, automatically
perform the linking step by calling on @code{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 g77
@cindex g77, components of
@code{g77} consists of several components:

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

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

@cindex libf2c library
@cindex libraries, libf2c
@cindex run-time library
@item
The @code{libf2c} 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 @code{g77}
compilation phase.

@cindex f771 program
@cindex programs, f771
@cindex assembler
@cindex as command
@cindex commands, 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 @code{as}.
@end itemize

@code{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, @code{gcc} determines which actions to perform, including
preprocessing, compiling (in a variety of possible languages), assembling,
and linking.

@cindex driver, gcc command as
@cindex 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
@samp{foo.c} through the preprocessor @samp{cpp}, then
the C compiler (internally named
@code{cc1}), then the assembler (usually @code{as}), then the linker
(@code{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},
@code{gcc} would use the C++ compiler (named @code{cc1plus}).

@cindex f771 program
@cindex programs, f771
In a GNU Fortran installation, @code{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 gcc not recognizing Fortran source
@cindex unrecognized file format
@cindex file format not recognized
Non-Fortran-related operation of @code{gcc} is generally
unaffected by installing the GNU Fortran version of @code{gcc}.
However, without the installed version of @code{gcc} being the
GNU Fortran version, @code{gcc} will not be able to compile
and link Fortran programs---and since @code{g77} uses @code{gcc}
to do most of the actual work, neither will @code{g77}!

@cindex g77 command
@cindex commands, g77
The @code{g77} command is essentially just a front-end for
the @code{gcc} command.
Fortran users will normally use @code{g77} instead of @code{gcc},
because @code{g77}
knows how to specify the libraries needed to link with Fortran programs
(@code{libf2c} and @code{lm}).
@code{g77} can still compile and link programs and
source files written in other languages, just like @code{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.
(It also produces an error message near the end of the output,
a diagnostic from the linker, usually @code{ld}---you can safely
ignore this error, but do include the entire output with any
bug report you submit.)
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 @code{gcc}
with which that version of @code{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 @code{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 @code{g77} when compiling Fortran code) into machine
code that, when run, calls on functions in @code{libf2c}, so
@code{libf2c} must be linked with almost every useful program
having any component compiled by GNU Fortran.
(As mentioned above, the @code{g77} command takes
care of all this for you.)

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

@cindex GNU Back End (GBE)
@cindex GBE
@cindex 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 g77 front end
@cindex front end, 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 @samp{-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 gcc command
@cindex commands, gcc
A GNU Fortran installation includes a modified version of the @code{gcc}
command.

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

In a GNU Fortran installation, @code{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++; or Objective-C,gcc,Using and Porting GNU CC},
for information on the way different languages are handled
by the GNU CC compiler (@code{gcc}).

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

@cindex -v option
@cindex g77 options, -v
@cindex options, -v
@cindex -@w{}-driver option
@cindex g77 options, --driver
@cindex options, --driver
Use the @samp{-v} option with @code{g77}
to see what is going on---the first line of output is the invocation
of the @code{gcc} command.
Use @samp{--driver=true} to disable actual invocation
of @code{gcc} (this works because @samp{true} is the name of a
UNIX command that simply returns success status).

@node Invoking G77
@chapter GNU Fortran Command Options
@cindex GNU Fortran command options
@cindex command options
@cindex options, GNU Fortran command

The @code{g77} command supports all the options supported by the
@code{gcc} command.
@xref{Invoking GCC,,GNU CC Command Options,gcc,Using and Porting GNU CC},
for information
on the non-Fortran-specific aspects of the @code{gcc} command (and,
therefore, the @code{g77} command).

The @code{g77} command supports one option not supported by
the @code{gcc} command:

@table @code
@cindex -@w{}-driver option
@cindex g77 options, driver
@cindex options, --driver
@item --driver=@var{command}
Specifies that @var{command}, rather than @code{gcc}, is to
be invoked by @code{g77} to do its job.
For example, within the gcc build directory after
building GNU Fortran (but without having to install it),
@samp{./g77 --driver=./xgcc foo.f -B./}.
@end table

@cindex options, negative forms
@cindex negative forms of options
All other options are supported both by @code{g77} and by @code{gcc} as
modified (and reinstalled) by the @code{g77} distribution.
In some cases, options have positive and negative forms;
the negative form of @samp{-ffoo} would be @samp{-fno-foo}.
This manual documents only one of these two forms, whichever
one is not the default.

@menu
* Option Summary::	Brief list of all @code{g77} options,
                        without explanations.
* Overall Options::     Controlling the kind of output:
                        an executable, object files, assembler files,
                        or preprocessed source.
* Fortran Dialect Options::  Controlling the variant of Fortran language
                             compiled.
* Warning Options::     How picky should the compiler be?
* Debugging Options::   Symbol tables, measurements, and debugging dumps.
* Optimize Options::    How much optimization?
* Preprocessor Options:: Controlling header files and macro definitions.
                         Also, getting dependency information for Make.
* Directory Options::   Where to find header files and libraries.
                        Where to find the compiler executable files.
* Code Gen Options::    Specifying conventions for function calls, data layout
                        and register usage.
* Environment Variables:: Env vars that affect GNU Fortran.
@end menu

@node Option Summary
@section Option Summary

Here is a summary of all the options specific to GNU Fortran, grouped
by type.  Explanations are in the following sections.

@table @emph
@item Overall Options
@xref{Overall Options,,Options Controlling the Kind of Output}.
@smallexample
--driver  -fversion  -fset-g77-defaults
@end smallexample

@item Fortran Language Options
@xref{Fortran Dialect Options,,Options Controlling Fortran Dialect}.
@smallexample
-ffree-form  -fno-fixed-form  -ff90  -fvxt-not-f90
-ff90-not-vxt  -fdollar-ok  -fno-backslash
-fintrin-case-initcap  -fintrin-case-upper
-fintrin-case-lower  -fintrin-case-any
-fmatch-case-initcap  -fmatch-case-upper
-fmatch-case-lower  -fmatch-case-any
-fsource-case-upper -fsource-case-lower  -fsource-case-preserve
-fsymbol-case-initcap  -fsymbol-case-upper
-fsymbol-case-lower  -fsymbol-case-any
-fcase-strict-upper  -fcase-strict-lower
-fcase-initcap  -fcase-upper  -fcase-lower  -fcase-preserve
-fdcp-intrinsics-delete  -fdcp-intrinsics-hide
-fdcp-intrinsics-disable  -fdcp-intrinsics-enable
-ff2c-intrinsics-delete  -ff2c-intrinsics-hide
-ff2c-intrinsics-disable  -ff2c-intrinsics-enable
-ff90-intrinsics-delete  -ff90-intrinsics-hide
-ff90-intrinsics-disable  -ff90-intrinsics-enable
-fmil-intrinsics-delete  -fmil-intrinsics-hide
-fmil-intrinsics-disable  -fmil-intrinsics-enable
-funix-intrinsics-delete  -funix-intrinsics-hide
-funix-intrinsics-disable  -funix-intrinsics-enable
-fvxt-intrinsics-delete  -fvxt-intrinsics-hide
-fvxt-intrinsics-disable  -fvxt-intrinsics-enable
-ffixed-line-length-@var{n}  -ffixed-line-length-none
@end smallexample

@item Warning Options
@xref{Warning Options,,Options to Request or Suppress Warnings}.
@smallexample
-fsyntax-only  -pedantic  -pedantic-errors  -fpedantic
-fugly  -fno-ugly-args  -fno-ugly-init  -w  -Wimplicit
-Wunused  -Wuninitialized  -Wall  -Wsurprising  -Werror
-W
@end smallexample

@item Debugging Options
@xref{Debugging Options,,Options for Debugging Your Program or GCC}.
@smallexample
-g
@end smallexample

@item Optimization Options
@xref{Optimize Options,,Options that Control Optimization}.
@smallexample
-ffloat-store  -fforce-mem  -fforce-addr  -fno-inline
-ffast-math  -fstrength-reduce  -frerun-cse-after-loop
-fexpensive-optimizations  -fdelayed-branch
-fschedule-insns  -fschedule-insn2  -fcaller-saves
-funroll-loops  -funroll-all-loops
-fno-move-all-movables  -fno-reduce-all-givs
-fno-rerun-loop-opt
@end smallexample

@item Directory Options
@xref{Directory Options,,Options for Directory Search}.
@smallexample
-I@var{dir}  -I-
@end smallexample

@item Code Generation Options
@xref{Code Gen Options,,Options for Code Generation Conventions}.
@smallexample
-fno-automatic  -finit-local-zero  -fno-f2c
-ff2c-library  -fno-underscoring  -fno-ident
-fpcc-struct-return  -freg-struct-return
-fshort-double  -fno-common  -fpack-struct
-fzeros
@end smallexample
@end table

@menu
* Overall Options::     Controlling the kind of output:
                        an executable, object files, assembler files,
                        or preprocessed source.
* Fortran Dialect Options::  Controlling the variant of Fortran language
                             compiled.
* Warning Options::     How picky should the compiler be?
* Debugging Options::   Symbol tables, measurements, and debugging dumps.
* Optimize Options::    How much optimization?
* Preprocessor Options:: Controlling header files and macro definitions.
                         Also, getting dependency information for Make.
* Directory Options::   Where to find header files and libraries.
                        Where to find the compiler executable files.
* Code Gen Options::    Specifying conventions for function calls, data layout
                        and register usage.
@end menu

@node Overall Options
@section Options Controlling the Kind of Output
@cindex overall options
@cindex options, overall

Compilation can involve as many as four stages: preprocessing, compilation
proper, assembly, and linking, always in that order.  The first three
stages apply to an individual source file, and end by producing an
object file; linking combines all the object files (those newly
compiled, and those specified as input) into an executable file.

@cindex file name suffix
@cindex suffixes, file name
@cindex file name extension
@cindex extensions, file name
@cindex file type
@cindex types, file
For any given input file, the file name suffix determines what kind of
compilation is done.
Suffixes specific to GNU Fortran are listed
below.
@xref{Overall Options,,gcc,Using and Porting GNU CC}, for
information on suffixes recognized by GNU CC.

@table @code
@item @var{file}.f
@item @var{file}.for
Fortran source code that should not be preprocessed.

@cindex preprocessor
@cindex C preprocessor
@cindex cpp preprocessor
@cindex Fortran preprocessor
@cindex cpp program
@cindex programs, cpp
@cindex .F
@cindex .fpp
@item @var{file}.F
@item @var{file}.fpp
Fortran source code that must be preprocessed (by the C preprocessor
@code{cpp}, which is part of GNU CC).
@end table

UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
nomenclature.
Users of other operating systems, especially those that cannot
distinguish upper-case
letters from lower-case letters in their file names, typically use
the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.

@cindex #define
@cindex #include
@cindex #if
Use of the preprocessor @code{cpp} allows use of C-like
constructs such as @samp{#define} and @samp{#include}, but can
lead to unexpected, even mistaken, results due to Fortran's source file
format.
It is recommended that use of the C preprocessor
be limited to @samp{#include} and, in
conjunction with @samp{#define}, only @samp{#if} and related directives,
thus avoiding in-line macro expansion entirely.
This recommendation applies especially
when using the traditional fixed source form.
With free source form,
fewer unexpected transformations are likely to happen, but use of
Hollerith and things like continued character constants can nevertheless
present problems.

The following options that affect overall processing are recognized
by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:

@table @code
@item --driver=@var{command}
This works only when invoking the @code{g77} command, not
when invoking the @code{gcc} command.
@xref{Invoking G77,,GNU Fortran Command Options}, for
information on this option.

@cindex -fversion option
@cindex options, -fversion
@cindex printing version information
@cindex version information, printing
@item -fversion
Ensure that the @code{g77}-specific version of the compiler phase is reported,
if run.
(This is supplied automatically when @samp{-v} or @samp{--version}
is specified as a command-line option for @code{g77} or @code{gcc}
and when the resulting commands compile Fortran source files.)

@cindex -fset-g77-defaults option
@cindex options, -fset-g77-defaults
@item -fset-g77-defaults
Set up whatever @code{gcc} options are to apply to Fortran
compilations.
For version 0.5.18, this is equivalent to @samp{-fmove-all-movables
-freduce-all-givs -frerun-loop-opt}.
(This is supplied automatically when compiling Fortran code.
The description of this option is here so that users seeing
it in the output of, say, @samp{g77 -v} understand why it is
there.
Also, developers who run @code{f771} directly might want to specify it
by hand to get the same defaults as they would running @code{f771}
via @code{g77} or @code{gcc}.)
@end table

@xref{Overall Options,,Options Controlling the Kind of Output,
gcc,Using and Porting GNU CC}, for information
on more options that control the overall operation of the @code{gcc} command
(and, by extension, the @code{g77} command).

@node Fortran Dialect Options
@section Options Controlling Fortran Dialect
@cindex dialect options
@cindex language dialect options
@cindex options, dialect

The following options control the dialect of Fortran
that the compiler accepts:

@table @code
@cindex -ffree-form option
@cindex options, -ffree-form
@cindex -fno-fixed-form option
@cindex options, -fno-fixed-form
@cindex source file form
@cindex free form
@cindex fixed form
@cindex Fortran 90 features
@item -ffree-form
@item -fno-fixed-form
Specify that the source file is written in free form
(introduced in Fortran 90) instead of the more-traditional fixed form.

@cindex -ff90 option
@cindex options, -ff90
@cindex Fortran 90 features
@item -ff90
Allow certain Fortran-90 constructs.

This option controls whether certain
Fortran 90 constructs are recognized.
(Other Fortran 90 constructs
might or might not be recognized depending on other options such as
@samp{-fvxt-not-f90}, @samp{-ff90-intrinsics-enable}, and the
current level of support for Fortran 90.)

@xref{Extensions,,GNU Fortran Extensions}, for more information.

@cindex -fvxt-not-f90 option
@cindex options, -fvxt-not-f90
@item -fvxt-not-f90
@cindex -ff90-not-vxt option
@cindex options, -ff90-not-vxt
@item -ff90-not-vxt
@cindex Fortran 90 features
@cindex VXT features
Specify whether Fortran 90 or other popular extensions
are to be assumed for ambiguous constructs.
The default is -fvxt-not-f90.

For example, with @samp{-ff90-not-vxt},
@samp{PRINT *,"double-quoted string"} is valid,
while with @samp{-fvxt-not-f90}, @samp{PRINT *,"2000} is valid.

(There is no way to allow
both constructs in the general case, since statements like
@samp{PRINT *,"2000 !comment?"} would be ambiguous.)

@xref{Dialects,,GNU Fortran Dialects}, for more information.

@cindex -fdollar-ok option
@cindex options, -fdollar-ok
@item -fdollar-ok
@cindex dollar sign
@cindex symbol names
@cindex character set
Allow @samp{$} as a valid character in a symbol name.

@cindex -fno-backslash option
@cindex options, -fno-backslash
@item -fno-backslash
@cindex backslash
@cindex character constants
@cindex Hollerith constants
Specify that @samp{\} is not to be specially interpreted in character
and Hollerith constants a la C and many UNIX Fortran compilers.

For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
three characters, with the second one being newline.
With @samp{-fno-backslash}, it specifies four characters,
@samp{A}, @samp{\}, @samp{n}, and @samp{B}.

Note that @code{g77} implements a fairly general form of backslash
processing that is incompatible with the narrower forms supported
by some other compilers.
For example, @samp{'A\003B'} is a three-character string in @code{g77},
whereas other compilers that support backslash might not support
the three-octal-digit form, and thus treat that string as longer
than three characters.

@xref{Non-bugs,,Certain Changes We Don't Want to Make}, for
information on why @samp{-fbackslash} is the default
instead of @samp{-fno-backslash}.

@cindex -fintrin-case-initcap option
@cindex options, -fintrin-case-initcap
@item -fintrin-case-initcap
@cindex -fintrin-case-upper option
@cindex options, -fintrin-case-upper
@item -fintrin-case-upper
@cindex -fintrin-case-lower option
@cindex options, -fintrin-case-lower
@item -fintrin-case-lower
@cindex -fintrin-case-any option
@cindex options, -fintrin-case-any
@item -fintrin-case-any
Specify expected case for intrinsic names.
@samp{-fintrin-case-lower} is the default.

@cindex -fmatch-case-initcap option
@cindex options, -fmatch-case-initcap
@item -fmatch-case-initcap
@cindex -fmatch-case-upper option
@cindex options, -fmatch-case-upper
@item -fmatch-case-upper
@cindex -fmatch-case-lower option
@cindex options, -fmatch-case-lower
@item -fmatch-case-lower
@cindex -fmatch-case-any option
@cindex options, -fmatch-case-any
@item -fmatch-case-any
Specify expected case for keywords.
@samp{-fmatch-case-lower} is the default.

@cindex -fsource-case-upper option
@cindex options, -fsource-case-upper
@item -fsource-case-upper
@cindex -fsource-case-lower option
@cindex options, -fsource-case-lower
@item -fsource-case-lower
@cindex -fsource-case-preserve option
@cindex options, -fsource-case-preserve
@item -fsource-case-preserve
Specify whether source text other than character and Hollerith constants
is to be translated to uppercase, to lowercase, or preserved as is.
@samp{-fsource-case-lower} is the default.

@cindex -fsymbol-case-initcap option
@cindex options, -fsymbol-case-initcap
@item -fsymbol-case-initcap
@cindex -fsymbol-case-upper option
@cindex options, -fsymbol-case-upper
@item -fsymbol-case-upper
@cindex -fsymbol-case-lower option
@cindex options, -fsymbol-case-lower
@item -fsymbol-case-lower
@cindex -fsymbol-case-any option
@cindex options, -fsymbol-case-any
@item -fsymbol-case-any
Specify valid cases for user-defined symbol names.
@samp{-fsymbol-case-any} is the default.

@cindex -fcase-strict-upper option
@cindex options, -fcase-strict-upper
@item -fcase-strict-upper
Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
-fsymbol-case-upper}.
(Requires all pertinent source to be in uppercase.)

@cindex -fcase-strict-lower option
@cindex options, -fcase-strict-lower
@item -fcase-strict-lower
Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
-fsymbol-case-lower}.
(Requires all pertinent source to be in lowercase.)

@cindex -fcase-initcap option
@cindex options, -fcase-initcap
@item -fcase-initcap
Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
-fsymbol-case-initcap}.
(Requires all pertinent source to be in initial capitals,
as in @samp{Print *,SqRt(Value)}.)

@cindex -fcase-upper option
@cindex options, -fcase-upper
@item -fcase-upper
Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
-fsymbol-case-any}.
(Maps all pertinent source to uppercase.)

@cindex -fcase-lower option
@cindex options, -fcase-lower
@item -fcase-lower
Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
-fsymbol-case-any}.
(Maps all pertinent source to lowercase.)

@cindex -fcase-preserve option
@cindex options, -fcase-preserve
@item -fcase-preserve
Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
-fsymbol-case-any}.
(Preserves all case in user-defined symbols,
while allowing any-case matching of intrinsics and keywords.
For example, @samp{call Foo(i,I)} would pass two @emph{different}
variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)

@cindex -fdcp-intrinsics-delete option
@cindex options, -fdcp-intrinsics-delete
@item -fdcp-intrinsics-delete
@cindex -fdcp-intrinsics-hide option
@cindex options, -fdcp-intrinsics-hide
@item -fdcp-intrinsics-hide
@cindex -fdcp-intrinsics-disable option
@cindex options, -fdcp-intrinsics-disable
@item -fdcp-intrinsics-disable
@cindex -fdcp-intrinsics-enable option
@cindex options, -fdcp-intrinsics-enable
@item -fdcp-intrinsics-enable
@cindex Digital Fortran features
@cindex COMPLEX intrinsics
@cindex intrinsics, COMPLEX
Specify status of Digital's COMPLEX-related intrinsics.
@samp{-fdcp-intrinsics-enable} is the default.

@cindex -ff2c-intrinsics-delete option
@cindex options, -ff2c-intrinsics-delete
@item -ff2c-intrinsics-delete
@cindex -ff2c-intrinsics-hide option
@cindex options, -ff2c-intrinsics-hide
@item -ff2c-intrinsics-hide
@cindex -ff2c-intrinsics-disable option
@cindex options, -ff2c-intrinsics-disable
@item -ff2c-intrinsics-disable
@cindex -ff2c-intrinsics-enable option
@cindex options, -ff2c-intrinsics-enable
@item -ff2c-intrinsics-enable
@cindex f2c intrinsics
@cindex intrinsics, f2c
Specify status of f2c-specific intrinsics.
@samp{-ff2c-intrinsics-enable} is the default.

@cindex -ff90-intrinsics-delete option
@cindex options, -ff90-intrinsics-delete
@item -ff90-intrinsics-delete
@cindex -ff90-intrinsics-hide option
@cindex options, -ff90-intrinsics-hide
@item -ff90-intrinsics-hide
@cindex -ff90-intrinsics-disable option
@cindex options, -ff90-intrinsics-disable
@item -ff90-intrinsics-disable
@cindex -ff90-intrinsics-enable option
@cindex options, -ff90-intrinsics-enable
@item -ff90-intrinsics-enable
@cindex Fortran 90 intrinsics
@cindex intrinsics, Fortran 90
Specify status of F90-specific intrinsics.
@samp{-ff90-intrinsics-delete} is the default.

@cindex -fmil-intrinsics-delete option
@cindex options, -fmil-intrinsics-delete
@item -fmil-intrinsics-delete
@cindex -fmil-intrinsics-hide option
@cindex options, -fmil-intrinsics-hide
@item -fmil-intrinsics-hide
@cindex -fmil-intrinsics-disable option
@cindex options, -fmil-intrinsics-disable
@item -fmil-intrinsics-disable
@cindex -fmil-intrinsics-enable option
@cindex options, -fmil-intrinsics-enable
@item -fmil-intrinsics-enable
@cindex MIL-STD 1753
@cindex intrinsics, MIL-STD 1753
Specify status of MIL-STD-1753-specific intrinsics.
@samp{-fmil-intrinsics-enable} is the default.

@cindex -funix-intrinsics-delete option
@cindex options, -funix-intrinsics-delete
@item -funix-intrinsics-delete
@cindex -funix-intrinsics-hide option
@cindex options, -funix-intrinsics-hide
@item -funix-intrinsics-hide
@cindex -funix-intrinsics-disable option
@cindex options, -funix-intrinsics-disable
@item -funix-intrinsics-disable
@cindex -funix-intrinsics-enable option
@cindex options, -funix-intrinsics-enable
@item -funix-intrinsics-enable
@cindex UNIX intrinsics
@cindex intrinsics, UNIX
Specify status of UNIX intrinsics.
@samp{-funix-intrinsics-enable} is the default.

@cindex FLUSH() intrinsic
@cindex intrinsics, FLUSH()
For example, if your code invokes @code{FLUSH} as
a library function and thus works with other UNIX Fortran
compilers or earlier version of @code{g77}, either add the
@samp{EXTERNAL FLUSH} statement or, perhaps
more convenient for you, compile with the -funix-intrinsics-hide or
-funix-intrinsics-delete option.

@cindex ABORT() intrinsic
@cindex intrinsics, ABORT()
@cindex EXIT() intrinsic
@cindex intrinsics, EXIT()
@cindex SIGNAL() intrinsic
@cindex intrinsics, SIGNAL()
@cindex SYSTEM() intrinsic
@cindex intrinsics, SYSTEM()
@cindex intrinsic subroutines
@cindex subroutines, intrinsic
@cindex intrinsic functions
@cindex functions, intrinsic
@cindex side effects
@cindex intrinsics, side effects of
Note that @code{ABORT}, @code{EXIT}, @code{FLUSH}, @code{SIGNAL}, and
@code{SYSTEM} are intrinsic subroutines, not functions (since they have
side effects), so to get the return values from @code{SIGNAL} and
@code{SYSTEM}, append a final argument specifying an @samp{INTEGER}
variable or array element to receive the returned status.
(For example, @samp{CALL SYSTEM('rm foo',ISTAT)}.)

@code{FLUSH()} accepts an optional single @samp{INTEGER} argument,
since many Fortran implementations allow or require a unit number.
Currently, since @code{libf2c}
does not flush a given unit number, this argument is not used---all
units are flushed by @code{libf2c}'s implementation of @code{FLUSH()}.
Do not depend on this behavior---if you want to flush all units,
use @samp{CALL FLUSH} (that is, specify no arguments to @code{FLUSH}).

@code{EXIT()} accepts an optional single @samp{INTEGER} argument.
If omitted, zero is the default (as in @samp{CALL EXIT(0)}).
The default might change on
configurations where the ``normal return status'' is not zero, however.
If you want to return a ``success'' status, it is best to call @code{EXIT}
with no arguments in your code, and let @code{g77} choose the appropriate
default.

@cindex -fvxt-intrinsics-delete option
@cindex options, -fvxt-intrinsics-delete
@item -fvxt-intrinsics-delete
@cindex -fvxt-intrinsics-hide option
@cindex options, -fvxt-intrinsics-hide
@item -fvxt-intrinsics-hide
@cindex -fvxt-intrinsics-disable option
@cindex options, -fvxt-intrinsics-disable
@item -fvxt-intrinsics-disable
@cindex -fvxt-intrinsics-enable option
@cindex options, -fvxt-intrinsics-enable
@item -fvxt-intrinsics-enable
@cindex VXT intrinsics
@cindex intrinsics, VXT
Specify status of VXT intrinsics.
@samp{-fvxt-intrinsics-delete} is the default.

@cindex -ffixed-line-length-@var{n} option
@cindex options, -ffixed-line-length-@var{n}
@item -ffixed-line-length-@var{n}
@cindex source file format
@cindex line length
@cindex length of source lines
@cindex fixed-form line length
Set column after which characters are ignored in typical fixed-form
lines in the source file.

@cindex card image
@cindex extended-source option
Popular values for @var{n} include 72 (the
standard and the default), 80 (card image), and 132 (corresponds
to ``extended-source'' options in some popular compilers).
@var{n} may be @samp{none}, meaning that the entire line is meaningful
and that continued character constants never have implicit spaces appended
to them to fill out the line.
@samp{-ffixed-line-length-0} means the same thing as
@samp{-ffixed-line-length-none}.
@end table

@node Warning Options
@section Options to Request or Suppress Warnings
@cindex options to control warnings
@cindex warning messages
@cindex messages, warning
@cindex suppressing warnings

Warnings are diagnostic messages that report constructions which
are not inherently erroneous but which are risky or suggest there
might have been an error.

You can request many specific warnings with options beginning @samp{-W},
for example @samp{-Wimplicit} to request warnings on implicit
declarations.  Each of these specific warning options also has a
negative form beginning @samp{-Wno-} to turn off warnings;
for example, @samp{-Wno-implicit}.  This manual lists only one of the
two forms, whichever is not the default.

These options control the amount and kinds of warnings produced by GNU
Fortran:

@table @code
@cindex syntax checking
@cindex -fsyntax-only option
@cindex options, -fsyntax-only
@item -fsyntax-only
Check the code for syntax errors, but don't do anything beyond that.

@cindex -pedantic option
@cindex options, -pedantic
@item -pedantic
Issue warnings for uses of extensions to ANSI FORTRAN 77.
@samp{-pedantic} also applies to C-language constructs where they
occur in GNU Fortran source files, such as use of @samp{\e} in a
character constant within a directive like @samp{#include}.

Valid ANSI FORTRAN 77 programs should compile properly with or without
this option.
However, without this option, certain GNU extensions and traditional
Fortran features are supported as well.
With this option, many of them are rejected.

Some users try to use @samp{-pedantic} to check programs for strict ANSI
conformance.  They soon find that it does not do quite what they want:
it finds some non-ANSI practices, but not all---however, improvements
to @code{g77} in this area are welcome.

@cindex -pedantic-errors option
@cindex options, -pedantic-errors
@item -pedantic-errors
Like @samp{-pedantic}, except that errors are produced rather than
warnings.

@cindex -fpedantic option
@cindex options, -fpedantic
@item -fpedantic
Like @samp{-pedantic}, but applies only to Fortran constructs.

@cindex -fugly option
@cindex options, -fugly
@item -fugly
@cindex ugly features
@cindex features, ugly
Specify that certain ``ugly'' constructs are to be quietly accepted.
Implies @samp{-fugly-args} and @samp{-fugly-init} as well.

For example, with @samp{-fno-ugly}, @samp{CALL FOO(,)} means to pass
one null argument, whereas with @samp{-fugly}, it means to pass two null
arguments.

@cindex -fno-ugly-args option
@cindex options, -fno-ugly-args
@item -fno-ugly-args
Disallow passing Hollerith and typeless constants as actual
arguments (for example, @samp{CALL FOO(4HABCD)}).

@cindex -fno-ugly-init option
@cindex options, -fno-ugly-init
@item -fno-ugly-init
Disallow use of Hollerith and typeless constants as initial
values (in @code{PARAMETER} and @code{DATA} statements), and
use of character constants to
initialize numeric types and vice versa.

For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
@samp{-fno-ugly-init}.

@cindex -w option
@cindex options, -w
@item -w
Inhibit all warning messages.

@cindex -Wimplicit option
@cindex options, -Wimplicit
@item -Wimplicit
@cindex implicit declaration, warning
@cindex warnings, implicit declaration
@cindex -u option
@cindex /WARNINGS=DECLARATIONS switch
@cindex IMPLICIT NONE, similar effect
@cindex effecting IMPLICIT NONE
Warn whenever a variable, array, or function is implicitly
declared.
Has an effect similar to using the @samp{IMPLICIT NONE} statement
in every program unit.
(Some Fortran compilers provide this feature by an option
named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)

@cindex -Wunused option
@cindex options, -Wunused
@item -Wunused
@cindex unused variables
@cindex variables, unused
Warn whenever a variable is unused aside from its declaration.

@cindex -Wuninitialized option
@cindex options, -Wuninitialized
@item -Wuninitialized
@cindex uninitialized variables
@cindex variables, uninitialized
Warn whenever an automatic variable is used without first being initialized.

These warnings are possible only in optimizing compilation,
because they require data flow information that is computed only
when optimizing.  If you don't specify @samp{-O}, you simply won't
get these warnings.

These warnings occur only for variables that are candidates for
register allocation.  Therefore, they do not occur for a variable that
is declared @code{volatile}, or whose address is taken, or whose size
is other than 1, 2, 4 or 8 bytes.  Also, they do not occur for
arrays, even when they are in registers.

Note that there may be no warning about a variable that is used only
to compute a value that itself is never used, because such
computations may be deleted by data flow analysis before the warnings
are printed.

These warnings are made optional because GNU Fortran is not smart
enough to see all the reasons why the code might be correct
despite appearing to have an error.  Here is one example of how
this can happen:

@example
SUBROUTINE DISPAT(J)
IF (J.EQ.1) I=1
IF (J.EQ.2) I=4
IF (J.EQ.3) I=5
CALL FOO(I)
END
@end example

@noindent
If the value of @code{J} is always 1, 2 or 3, then @code{I} is
always initialized, but GNU Fortran doesn't know this.  Here is
another common case:

@example
SUBROUTINE MAYBE(FLAG)
LOGICAL FLAG
IF (FLAG) VALUE = 3.14
@dots{}
IF (FLAG) PRINT *, VALUE
END
@end example

@noindent
This has no bug because @code{VALUE} is used only if it is set.

@cindex -Wall option
@cindex options, -Wall
@item -Wall
@cindex all warnings
@cindex warnings, all
The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
These are all the
options which pertain to usage that we recommend avoiding and that we
believe is easy to avoid.
(As more warnings are added to @code{g77}, some might
be added to the list enabled by @samp{-Wall}.)
@end table

The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
because they warn about constructions that we consider reasonable to
use, on occasion, in clean programs.

@table @code
@c @item -W
@c Print extra warning messages for these events:
@c 
@c @itemize @bullet
@c @item
@c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
@c arguments.
@c 
@c @end itemize
@c
@cindex -Wsurprising option
@cindex options, -Wsurprising
@item -Wsurprising
Warn about ``suspicious'' constructs that are interpreted
by the compiler in a way that might well be surprising to
someone reading the code.
These differences can result in subtle, compiler-dependent
(even machine-dependent) behavioral differences.
The constructs warned about include:

@itemize @bullet
@item
Expressions having two arithmetic operators in a row, such
as @samp{X*-Y}.
Such a construct is nonstandard, and can produce
unexpected results in more complicated situations such
as @samp{X**-Y*Z}.
@code{g77}, along with many other compilers, interprets
this example differently than many programmers, and a few
other compilers.
Specifically, @code{g77} interprets @samp{X**-Y*Z} as
@samp{(X**(-Y))*Z}, while others might think it should
be interpreted as @samp{X**(-(Y*Z))}.

A revealing example is the constant expression @samp{2**-2*1.},
which @code{g77} evaluates to .25, while others might evaluate
it to 0., the difference being the way precedence affects type
promotion.

(The @samp{-fpedantic} option also warns about expressions
having two arithmetic operators in a row.)

@item
Expressions with a unary minus followed by an operand and then
a binary operator other than plus or minus.
For example, @samp{-2**2} produces a warning, because
the precedence is @samp{-(2**2)}, yielding -4, not
@samp{(-2)**2}, which yields 4, and which might represent
what a programmer expects.
Even cases such as @samp{-I*J} produce warnings,
even though, in most configurations and situations,
there is no computational difference between the
results of the two interpretations---the purpose
of this warning is to warn about differing interpretations
and encourage a better style of coding, not to identify
only those places where bugs might exist in the user's
code.

@cindex DO statement
@cindex statements, DO
@item
@samp{DO} loops with @samp{DO} variables that are not
of integral type---that is, using @samp{REAL} or
@samp{DOUBLE PRECISION} variables as loop control
variables.
Although such loops can be written to work in the
``obvious'' way, the way @code{g77} is required by the
Fortran standard to interpret such code is likely to
be quite different from the way many programmers expect.
(This is true of all @samp{DO} loops, but the differences
are pronounced for non-integral loop control variables.)

@xref{Loops}, for more information.
@end itemize

@cindex -Werror option
@cindex options, -Werror
@item -Werror
Make all warnings into errors.

@cindex -W option
@cindex options, -W
@item -W
@cindex extra warnings
@cindex warnings, extra
Turns on ``extra warnings'' and the @samp{uninitialized} option.
(This might change in future versions of @code{g77}.)

``Extra warnings'' are issued for:

@itemize @bullet
@item
@cindex unused parameters
@cindex parameters, unused
@cindex unused arguments
@cindex arguments, unused
@cindex unused dummies
@cindex dummies, unused
Unused parameters to a procedure (when @samp{-Wunused} also is
specified).

@item
@cindex overflow
Overflows involving floating-point constants (not available
for certain configurations?).
@end itemize
@end table

@xref{Warning Options,,Options to Request or Suppress Warnings,
gcc,Using and Porting GNU CC}, for information on more options offered
by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.

Some of these have no effect when compiling programs written in Fortran:

@table @code
@cindex -Wcomment option
@cindex options, -Wcomment
@item -Wcomment
@cindex -Wformat option
@cindex options, -Wformat
@item -Wformat
@cindex -Wparentheses option
@cindex options, -Wparentheses
@item -Wparentheses
@cindex -Wswitch option
@cindex options, -Wswitch
@item -Wswitch
@cindex -Wtraditional option
@cindex options, -Wtraditional
@item -Wtraditional
@cindex -Wshadow option
@cindex options, -Wshadow
@item -Wshadow
@cindex -Wid-clash-@var{len} option
@cindex options, -Wid-clash-@var{len}
@item -Wid-clash-@var{len}
@cindex -Wlarger-than-@var{len} option
@cindex options, -Wlarger-than-@var{len}
@item -Wlarger-than-@var{len}
@cindex -Wconversion option
@cindex options, -Wconversion
@item -Wconversion
@cindex -Waggregate-return option
@cindex options, -Waggregate-return
@item -Waggregate-return
@cindex -Wredundant-decls option
@cindex options, -Wredundant-decls
@item -Wredundant-decls
@cindex unsupported warnings
@cindex warnings, unsupported
These options all could have some relevant meaning for
GNU Fortran programs, but are not yet supported.
@end table

@node Debugging Options
@section Options for Debugging Your Program or GNU Fortran
@cindex options, debugging
@cindex debugging information options

GNU Fortran has various special options that are used for debugging
either your program or @code{g77}.

@table @code
@cindex -g option
@cindex options, -g
@item -g
Produce debugging information in the operating system's native format
(stabs, COFF, XCOFF, or DWARF).  GDB can work with this debugging
information.

@cindex COMMON blocks
@cindex EQUIVALENCE areas
@cindex missing debug features
Support for this option in Fortran programs is incomplete.
In particular, names of variables and arrays in common blocks
or that are storage-associated via @samp{EQUIVALENCE} are
unavailable to the debugger.
@end table

@xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
gcc,Using and Porting GNU CC}, for more information on debugging options.

@node Optimize Options
@section Options That Control Optimization
@cindex optimize options
@cindex options, optimization

Most Fortran users will want to use no optimization when
developing and testing programs, and use @samp{-O} or @samp{-O2} when
compiling programs for late-cycle testing and for production use.

The following flags have particular applicability when
compiling Fortran programs:

@table @code
@cindex -ffloat-store option
@cindex options, -ffloat-store
@item -ffloat-store
@cindex IEEE conformance
@cindex conformance, IEEE
Might help a Fortran program that depends on exact IEEE conformance
on some machines, but might slow down a program that doesn't.

@cindex -fforce-mem option
@cindex options, -fforce-mem
@item -fforce-mem
@cindex -fforce-addr option
@cindex options, -fforce-addr
@item -fforce-addr
@cindex loops, speeding up
@cindex speeding up loops
Might improve optimization of loops.

@cindex -fno-inline option
@cindex options, -fno-inline
@item -fno-inline
@cindex in-line compilation
@cindex compilation, in-line
Don't compile statement functions inline.
Might reduce the size of a program unit---which might be at
expense of some speed (though it should compile faster).
Note that if you are not optimizing, no functions can be expanded inline.

@cindex -ffast-math option
@cindex options, -ffast-math
@item -ffast-math
@cindex IEEE conformance
@cindex conformance, IEEE
Might allow some programs designed to not be too dependent
on IEEE behavior for floating-point to run faster, or die trying.

@cindex -fstrength-reduce option
@cindex options, -fstrength-reduce
@item -fstrength-reduce
@cindex loops, speeding up
@cindex speeding up loops
Might make some loops run faster.

@cindex -frerun-cse-after-loop option
@cindex options, -frerun-cse-after-loop
@item -frerun-cse-after-loop
@cindex -fexpensive-optimizations option
@cindex options, -fexpensive-optimizations
@item -fexpensive-optimizations
@cindex -fdelayed-branch option
@cindex options, -fdelayed-branch
@item -fdelayed-branch
@cindex -fschedule-insns option
@cindex options, -fschedule-insns
@item -fschedule-insns
@cindex -fschedule-insns2 option
@cindex options, -fschedule-insns2
@item -fschedule-insns2
@cindex -fcaller-saves option
@cindex options, -fcaller-saves
@item -fcaller-saves
Might improve performance on some code.

@cindex -funroll-loops option
@cindex options, -funroll-loops
@item -funroll-loops
@cindex loops, unrolling
@cindex unrolling loops
Definitely improves performance on some code.

@cindex -funroll-all-loops option
@cindex options, -funroll-all-loops
@item -funroll-all-loops
Definitely improves performance on some code.

@item -fno-move-all-movables
@item -fno-reduce-all-givs
@item -fno-rerun-loop-opt
Each of these might improve performance on some code.

Analysis of Fortran code optimization and the resulting
optimizations triggered by the above options were
contributed by Toon Moene (@code{toon@@moene.indiv.nluug.nl}).

Please let us know how use of these options affects
the performance of your production code.
We're particularly interested in code that runs faster
when these options are @emph{disabled}, and in
non-Fortran code that benefits when they are
@emph{enabled} via the above @code{gcc} command-line options.
@end table

@xref{Optimize Options,,Options That Control Optimization,
gcc,Using and Porting GNU CC}, for more information on options
to optimize the generated machine code.

@node Preprocessor Options
@section Options Controlling the Preprocessor
@cindex preprocessor options
@cindex options, preprocessor
@cindex cpp program
@cindex programs, cpp

These options control the C preprocessor, which is run on each C source
file before actual compilation.

@xref{Preprocessor Options,,Options Controlling the Preprocessor,
gcc,Using and Porting GNU CC}, for information on C preprocessor options.

@cindex INCLUDE statement
@cindex statements, INCLUDE
Some of these options also affect how @code{g77} processes the
@samp{INCLUDE} statement.
Since this statement is processed even when preprocessing
is not requested, it is not described in this section.
@xref{Directory Options,,Options for Directory Search}, for
information on how @code{g77} processes the @samp{INCLUDE} statement.

@node Directory Options
@section Options for Directory Search
@cindex directory options
@cindex options, directory search
@cindex search path

These options affect how the @code{cpp} preprocessor searches
for files specified via the @samp{#include} directive.
Therefore, when compiling Fortran programs, they are meaningful
when the preproecssor is used.

@cindex INCLUDE statement
@cindex statements, INCLUDE
Some of these options also affect how @code{g77} searches
for files specified via the @samp{INCLUDE} statement.
These options are:

@table @code
@cindex -I- option
@cindex options, -I-
@item -I-
@cindex -Idir option
@cindex options, -Idir
@item -I@var{dir}
@cindex directory search paths for inclusion
@cindex inclusion, directory search paths for
@cindex searching for included files
These affect interpretation of the @samp{INCLUDE} statement
(as well as of the @samp{#include} directive of the @code{cpp}
preprocessor).

Note that @samp{-I@var{dir}} must be specified @emph{without} any
spaces between @samp{-I} and the directory name---that is,
@samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
is rejected by the @code{g77} compiler (though the preprocessor supports
the latter form).
@c this is due to toplev.c's inflexible option processing
Also note that the general behavior of @samp{-I} and
@samp{INCLUDE} is pretty much the same as of @samp{-I} with
@samp{#include} in the @code{cpp} preprocessor, with regard to
looking for @file{header.gcc} files and other such things.

@xref{Directory Optoins,,Options for Directory Search,
gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
@end table

@node Code Gen Options
@section Options for Code Generation Conventions
@cindex code generation conventions
@cindex options, code generation 
@cindex run-time options

These machine-independent options control the interface conventions
used in code generation.

Most of them have both positive and negative forms; the negative form
of @samp{-ffoo} would be @samp{-fno-foo}.  In the table below, only
one of the forms is listed---the one which is not the default.  You
can figure out the other form by either removing @samp{no-} or adding
it.

@table @code
@cindex -fno-automatic option
@cindex options, -fno-automatic
@item -fno-automatic
@cindex SAVE statement
@cindex statements, SAVE
Treat each program unit as if the @code{SAVE} statement was specified
for every local variable and array referenced in it.
Does not affect common blocks.
(Some Fortran compilers provide this option under
the name @samp{-static}.)

@cindex -finit-local-zero option
@cindex options, -finit-local-zero
@item -finit-local-zero
@cindex DATA statement
@cindex statements, DATA
@cindex initialization of local variables
@cindex variables, initialization of
@cindex uninitialized variables
@cindex variables, uninitialized
Specify that variables and arrays that are local to a program unit
(not in a common block and not passed as an argument) are to be initialized
to binary zeros.

Since there is a run-time penalty for initialization of variables
that are not given the @code{SAVE} attribute, it might be a
good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.

@cindex -fno-f2c option
@cindex options, -fno-f2c
@item -fno-f2c
@cindex f2c compatibility
@cindex compatibility, f2c
Do not generate code designed to be compatible with code generated
by @code{f2c}.

This does not affect the generation of code that interfaces with the
@code{libf2c} library.

@strong{Caution:} If @samp{-fno-f2c} is used when compiling any
source file used in a program, it must be used when compiling
@emph{all} Fortran source files used in that program.

@c seems kinda dumb to tell people about an option they can't use -- jcb
@c then again, we want users building future-compatible libraries with it.
@cindex -ff2c-library option
@cindex options, -ff2c-library
@item -ff2c-library
Specify that use of @code{libf2c} is required.
This is the default for the current version of @code{g77}.

Currently it is not
valid to specify @samp{-fno-f2c-library}.
This option is provided so users can specify it in shell
scripts that build programs and libraries that require the
@code{libf2c} library, even when being compiled by future
versions of @code{g77} that might otherwise default to
generating code for an incompatible library.

@cindex -fno-underscoring option
@cindex options, -fno-underscoring
@item -fno-underscoring
@cindex underscores
@cindex symbol names, underscores
@cindex transforming symbol names
@cindex symbol names, transforming
Do not transform names of entities specified in the Fortran
source file by appending underscores to them.

With @samp{-funderscoring} in effect, @code{g77} appends two underscores
to names with underscores and one underscore to external names with
no underscores.  (@code{g77} also appends two underscores to internal
names with underscores to avoid naming collisions with external names.)

This is done to ensure compatibility with code produced by many
UNIX Fortran compilers, including @code{f2c}, which perform the
same transformations.

Use of @samp{-fno-underscoring} is not recommended unless you are
experimenting with issues such as integration of (GNU) Fortran into
existing system environments (vis-a-vis existing libraries, tools, and
so on).

For example, with @samp{-funderscoring}, and assuming other defaults like
@samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
external functions while @samp{my_var} and @samp{lvar} are local variables,
a statement like

@smallexample
I = J() + MAX_COUNT (MY_VAR, LVAR)
@end smallexample

@noindent
is implemented as something akin to:

@smallexample
i = j_() + max_count__(&my_var__, &lvar);
@end smallexample

With @samp{-fno-underscoring}, the same statement is implemented as:

@smallexample
i = j() + max_count(&my_var, &lvar);
@end smallexample

Use of @samp{-fno-underscoring} allows direct specification of
user-defined names while debugging and when interfacing @code{g77}-compiled
code with other languages.

Note that just because the names match does @emph{not} mean that the
interface implemented by @code{g77} for an external name matches the
interface implemented by some other language for that same name.
That is, getting code produced by @code{g77} to link to code produced
by some other compiler using this or any other method can be only a
small part of the overall solution---getting the code generated by
both compilers to agree on issues other than naming can require
significant effort, and, unlike naming disagreements, linkers normally
cannot detect disagreements in these other areas.

Also, note that with @samp{-fno-underscoring}, the lack of appended
underscores introduces the very real possibility that a user-defined
external name will conflict with a name in a system library, which
could make finding unresolved-reference bugs quite difficult in some
cases---they might occur at program run time, and show up only as
buggy behavior at run time.

In future versions of @code{g77}, we hope to improve naming and linking
issues so that debugging always involves using the names as they appear
in the source, even if the names as seen by the linker are mangled to
prevent accidental linking between procedures with incompatible
interfaces.

@cindex -fno-second-underscore option
@cindex options, -fno-second-underscore
@item -fno-second-underscore
@cindex underscores
@cindex symbol names, underscores
@cindex transforming symbol names
@cindex symbol names, transforming
Do not append a second underscore to names of entities specified
in the Fortran source file.

This option has no effect if @samp{-fno-underscoring} is not
in effect.

Otherwise, with this option, an external name such as @samp{MAX_COUNT}
is implemented as a reference to the link-time external symbol
@samp{max_count_}, instead of @samp{max_count__}.

@cindex -fno-ident option
@cindex options, -fno-ident
@item -fno-ident
Ignore the @samp{#ident} directive.

@cindex -fzeros option
@cindex options, -fzeros
@item -fzeros
Treat initial values of zero as if they were any other value.

As of version 0.5.18, @code{g77} normally treats @samp{DATA} and
other statements that are used specify initial values of zero
for variables and arrays as if no values were actually specified,
in the sense that no diagnostics regarding multiple initializations
are produced.

This is done to speed up compiling of programs that initialize
large arrays to zeros.

Use @samp{-fzeros} to revert to the simpler, slower behavior
that can catch multiple initializations by keeping track of
all initializations, zero or otherwise.

@emph{Caution:} Future versions of @code{g77} might disregard this option
(and its negative form, the default) or interpret it somewhat
differently.
The interpretation changes will affect only non-standard
programs; standard-conforming programs should not be affected.
@end table

@xref{Code Gen Options,,Options for Code Generation Conventions,
gcc,Using and Porting GNU CC}, for information on more options
offered by the GBE
shared by @code{g77}, @code{gcc}, and other GNU compilers.

Some of these do @emph{not} work when compiling programs written in Fortran:

@table @code
@cindex -fpcc-struct-return option
@cindex options, -fpcc-struct-return
@item -fpcc-struct-return
@cindex -freg-struct-return option
@cindex options, -freg-struct-return
@item -freg-struct-return
You should not use these except strictly the same way as you
used them to build the version of @code{libf2c} with which
you will be linking all code compiled by @code{g77} with the
same option.

@cindex -fshort-double option
@cindex options, -fshort-double
@item -fshort-double
This probably either has no effect on Fortran programs, or
makes them act loopy.

@cindex -fno-common option
@cindex options, -fno-common
@item -fno-common
Do not use this when compiling Fortran programs,
or there will be Trouble.

@cindex -fpack-struct option
@cindex options, -fpack-struct
@item -fpack-struct
This probably will break any calls to the @code{libf2c} library,
at the very least, even if it is built with the same option.
@end table

@node Environment Variables
@section Environment Variables Affecting GNU Fortran
@cindex environment variables

GNU Fortran currently does not make use of any environment
variables to control its operation above and beyond those
that affect the operation of @code{gcc}.

@xref{Environment Variables,,Environment Variables Affecting GNU CC,
gcc,Using and Porting GNU CC}, for information on environment
variables.

@include news.texi

@node Changes
@chapter User-visible Changes
@cindex versions, recent
@cindex recent versions
@cindex changes, user-visible
@cindex user-visible changes

To find out about existing bugs and ongoing plans for GNU
Fortran, on Internet do @samp{finger -l fortran@@gnu.ai.mit.edu}
or whatever is the equivalent on your system.
(You might need to use the address @samp{fortran@@gate-1.gnu.ai.mit.edu}
instead, or use @samp{gate-2}, @samp{gate-3}, @samp{gate-4}, and so on,
instead of @samp{gate-1}.)

Alternatively, retrieve @file{gnu.ai.mit.edu:/g77.plan} via
anonymous ftp, or if you cannot do that, email
@samp{fortran@@gnu.ai.mit.edu} asking for a recent copy of the
GNU Fortran @file{.plan} file.
(The @code{finger} command shown above obtains the most recent
copy of all these methods.)

@heading In 0.5.18:

@itemize @bullet
@item
The @code{BYTE} and @code{WORD} statements now are supported,
to a limited extent.

@item
@samp{INTEGER*1}, @samp{INTEGER*2}, @samp{INTEGER*8},
and their @samp{LOGICAL}
equivalents, now are supported to a limited extent.
Among the missing elements are complete intrinsic and constant
support.

@item
Support automatic arrays in procedures.
For example, @samp{REAL A(N)}, where @samp{A} is
not a dummy argument, specifies that @samp{A} is
an automatic array.
The size of @samp{A} is calculated from the value
of @samp{N} each time the procedure is called,
that amount of space is allocated, and that space
is freed when the procedure returns to its caller.

@item
Add @samp{-fno-zeros} option, enabled by default,
to reduce compile-time CPU and memory usage for
code that provides initial zero values for variables
and arrays.

@item
Introduce three new options that apply to all compilations
by @code{g77}-aware GNU compilers---@samp{-fmove-all-movables},
@samp{-freduce-all-givs}, and @samp{-frerun-loop-opt}---which
can improve the run-time performance of some programs.

@item
Replace much of the existing documentation with a single
Info document.

@item
New option @samp{-fno-second-underscore}.
@end itemize

@heading In 0.5.17:

@itemize @bullet
@item
The @samp{ERF()} and @samp{ERFC()} intrinsics now are generic
intrinsics, mapping to @samp{ERF}/@samp{DERF} and
@samp{ERFC}/@samp{DERFC}, respectively.
@emph{Note:} Use @samp{INTRINSIC ERF,ERFC} in any code that
might reference these as generic intrinsics, to
improve the likelihood of diagnostics (instead of subtle run-time
bugs) when using compilers that don't support these as intrinsics.

@item
New option @samp{-Wsurprising}.

@item
DO loops with non-@samp{INTEGER} variables now diagnosed only when
@samp{-Wsurprising} specified.
Previously, this was diagnosed @emph{unless} @samp{-fpedantic} or
@samp{-fugly} was specified.
@end itemize

@heading In 0.5.16:

@itemize @bullet
@item
@code{libf2c} changed to output a leading zero (0) digit for floating-point
values output via list-directed and formatted output (to bring @code{g77}
more in line with many existing Fortran implementations---the
ANSI FORTRAN 77 standard leaves this choice to the implementation).

@item
@code{libf2c} no longer built with debugging information
intact, making it much smaller.

@item
Automatic installation of the @code{g77} command now works.

@item
Diagnostic messages now more informative, a la @code{gcc},
including messages like @samp{In function `foo':} and @samp{In file
included from...:}.

@item
New group of intrinsics called @samp{unix}, including @samp{ABORT},
@samp{DERF}, @samp{DERFC}, @samp{ERF}, @samp{ERFC}, @samp{EXIT},
@samp{FLUSH}, @samp{GETARG}, @samp{GETENV}, @samp{SIGNAL}, and
@samp{SYSTEM}.

@item
@samp{-funix-intrinsics-@{delete,hide,disable,enable@}}
options added.

@item
@samp{-fno-underscoring} option added.

@item
@samp{--driver} option added to the @code{g77} command.

@item
Support for the @code{gcc} options @samp{-fident} and @samp{-fno-ident}
added.

@item
@samp{g77 -v} returns much more version info, making the submission
of better bug reports easily.

@item
Many improvements to the @code{g77} command to better fulfill its role as
a front-end to the @code{gcc} driver.
For example, @code{g77} now
recognizes @samp{--version} as a verbose way of specifying @samp{-v}.

@item
Compiling preprocessed (@file{*.F} and @file{*.fpp}) files now
results in better diagnostics and debugging information, as the
source-location info now is passed all the
way through the compilation process instead of being lost.
@end itemize

@heading In 0.5.15:

@itemize @bullet
@item
@samp{-ffixed-line-length-@var{n}} option introduced.
@end itemize

@heading In 0.5.14:

@itemize @bullet
@item
Support for gcc's @samp{-I} option added.

@item
@samp{-fbackslash} option added.

@item
@samp{-fugly-args} option enabled by default (allows @samp{CALL FOO(4HABCD)}).

@item
@samp{-fugly-init} option added.

@item
@samp{-finit-local-zero} option added.

@item
Support for the @code{gcc} option @samp{-Wimplicit} added.

@item
@samp{-Wall} now implies @samp{-Wunused} and, when @samp{-O} is
specified, @samp{-Wuninitialized}.

@cindex Hollerith constants
@cindex constants, Hollerith
@item
Hollerith constants as actual arguments now are passed by reference
instead of by value---so @samp{CALL FOO(4HABCD)} now is compiled exactly
the same as @samp{CALL FOO(%REF('ABCD'))}, instead of as
@samp{CALL FOO(%VAL('ABCD'))}.

@item
Hollerith constants converted to larger types now are padded on the
right with spaces.
When converted to smaller types, warnings are issued
if non-spaces are truncated on the right.

@item
Format specifications of arrays of types other than @samp{CHARACTER} are
allowed in I/O statements, such as when they contain Hollerith
data.

@cindex typeless constants
@cindex constants, typeless
@item
Typeless constants as actual arguments now are passed by reference
to an @samp{INTEGER} version of the constant instead of by value.

@item
Typeless constants converted to larger types are padded on the left
with zeros.
When converted to smaller types, warnings are issued if non-zero
bits are truncated on the left.

@cindex %DESCR() intrinsic
@cindex intrinsics, %DESCR()
@item
@samp{%DESCR()} of a non-@samp{CHARACTER} expression treats the expression
as if it were @samp{CHARACTER}, passing both a pointer to the expression
and the length of the type of the expression in bytes, by value, in the
``hidden'' list of lengths used for @samp{CHARACTER} arguments.

@item
The @samp{ICHAR()}, @samp{IACHAR()}, and @samp{LEN()} intrinsics now
accept character expressions involving concatenation of assumed-length
dummy arguments.

@item
Block data program units now may contain @samp{NAMELIST}, @samp{EXTERNAL},
@samp{INTRINSIC}, and @samp{VOLATILE} statements.

@item
Zero-length character expressions now supported.

@item
Support for the @code{f2c} intrinsic @samp{IMAG()} added.

@item
@samp{INCLUDE} statement restrictions, such as no continuation
lines allowed, now lifted.
@end itemize

@node Language
@chapter The GNU Fortran Language

GNU Fortran supports a variety of extensions to, and dialects
of, the Fortran language.
Its primary base is the ANSI FORTRAN 77 standard.
It offers some extensions that are popular among users
of UNIX @code{f77} and @code{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.

Part of what defines a particular implementation of a Fortran
system, such as @code{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.

@menu
* Standard Support:: Degree of support for the ANSI FORTRAN 77 standard.
* Extensions::       Extensions to GNU Fortran.
* Types::            Data types.
* Constants::        Constants and their types.
* Source Form::      Form of source files (fixed, free, and so on).
* Pedantic Compilation::  Warnings about non-standard constructs.
* Case Sensitivity:: Uppercase and lowercase in source files.
* Intrinsics::       How intrinsics are grouped for easy management.
* Dialects::         Dialects supported by GNU Fortran.
* Object Compatibility::  Compatibility issues for code generated by @code{g77}.
* Distensions::      Misfeatures supported by GNU Fortran.
@end menu

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

GNU Fortran supports ANSI FORTRAN 77 with the following caveats:

@itemize @bullet
@item
No passing of an external procedure as an actual argument if the procedure's
type is declared @samp{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.

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

@item
No passing of a dummy procedure as an actual argument if the procedure's
type is declared @samp{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.

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

@item
The @samp{DO} variable for an implied-@samp{DO} construct in a
@samp{DATA} statement may not be used as the @samp{DO} variable
for an outer implied-@samp{DO} construct.  For example, this
fragment is disallowed by @code{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.

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

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

@noindent
This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
requirements offer no additional capabilities.
However, @code{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.
@end itemize

In summary, the only ANSI FORTRAN 77 features @code{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.

@node Extensions
@section GNU Fortran Extensions
@cindex extensions
@cindex language extensions

GNU Fortran supports ANSI FORTRAN 77 plus:

@itemize @bullet
@cindex LOC() intrinsic
@cindex intrinsics, LOC()
@item
@samp{LOC()}, if @samp{-funix-intrinsics-enable} is in force.

@item
@cindex %LOC() intrinsic
@cindex intrinsics, %LOC()
@cindex %VAL() intrinsic
@cindex intrinsics, %VAL()
@cindex %REF() intrinsic
@cindex intrinsics, %REF()
@cindex %DESCR() intrinsic
@cindex intrinsics, %DESCR()
@samp{%LOC}, @samp{%VAL}, @samp{%REF}, and @samp{%DESCR}---where
@samp{%DESCR} currently means the same thing as passing the argument
as if it were a @samp{CHARACTER} variable (with the phantom
length argument appended to the argument list).

@item
MIL-STD 1753 features (@samp{IAND}, @samp{IOR}, @samp{MVBITS},
@samp{DO WHILE}, @samp{END DO}, and so on).

@cindex NAMELIST statement
@cindex statements, NAMELIST
@item
@samp{NAMELIST}.

@item
Most @code{f2c} intrinsics (@samp{AND}, @samp{OR}, @samp{LSHIFT},
@samp{RSHIFT}, and so on).

@item
@samp{DOUBLE COMPLEX} and related intrinsics (standard and @code{f2c}
varieties).

@item
Various Fortran 90 features, such as @samp{CYCLE}, @samp{EXIT},
@samp{SELECT CASE} (except for @samp{CHARACTER} types).

@item
Various DEC VAX/VMS FORTRAN v4.0 features (loosely called VXT extensions).

@item
Various @code{f2c} features.

@item
Source files that are uppercase-only (enforced), lowercase-only
(enforced), caseless, and various other combinations as chosen via
command-line options.

@item
Arbitrary (limited only by available memory) number of continuation lines.

@item
Use of @samp{&} in column 1 to indicate a continuation line
(as supported by @code{f2c}).

@item
Dollar signs (@samp{$}) in identifiers (other than as the first character)
when the @samp{-fdollar-ok} option is specified.
@end itemize

When @samp{-ff90} is specified, the language dialect changes as follows:

@itemize @bullet
@item
The type of @samp{REAL(Z)}, where @samp{Z} is type
@samp{DOUBLE COMPLEX}, is @samp{DOUBLE PRECISION}
instead of @samp{REAL}.

@item
Zero-length @samp{CHARACTER} entities are accepted,
even when @samp{-fpedantic} is specified.

@item
Zero-size array dimensions (as in @samp{INTEGER I(10,20,4:2)})
are accepted,
although these are not supported by @samp{libf2c}, so diagnostics
are nevertheless produced for @code{g77}.

@item
@samp{DOUBLE COMPLEX} (explicit or implicit) is accepted,
even when @samp{-fpedantic} is specified.

@item
Substrings of constants (as in @samp{'hello'(3:5)}) are
accepted, even when @samp{-fpedantic} is specified.

@item
@samp{DATA} statements are allowed to precede executable statements,
even when @samp{-fpedantic} specified.

Note that this does not allow all possible means of specifying
further attributes via specification statements for a variable
after it has been given an initial value via @samp{DATA} or a
type-declaration statement.
For example,
after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
@samp{INTEGER J} is permitted.

@item
@cindex semicolons
@cindex statements, separated by semicolon
Use of a semicolon (@samp{;}) as a statement separator
is accepted, even when @samp{-fpedantic} specified
(so @samp{CALL FOO; CALL BAR} works).

@item
Underscores (@samp{_}) are accepted in symbol names (except as the
first character, since Fortran 90 provides a different interpretation
for certain cases where that would occur---though @code{g77} does
not yet support that interpretation).
@end itemize

@node Types
@section 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
is offered by the various types such as @samp{LOGICAL}, @samp{INTEGER},
@samp{REAL}, @samp{DOUBLE PRECISION}, @samp{COMPLEX}, and @samp{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 @samp{LOGICAL}, @samp{INTEGER}, and @samp{REAL}
occupy the same amount of storage space, and that @samp{COMPLEX} and
@samp{DOUBLE PRECISION} take twice as much storage space as @samp{REAL}.
Further, it requires that @samp{COMPLEX}
entities be ordered such that when a @samp{COMPLEX} variable is
storage-associated (such as via @samp{EQUIVALENCE})
with a two-element @samp{REAL} array named @samp{R}, @samp{R(1)}
corresponds to the real element and @samp{R(2)} to the imaginary
element of the @samp{COMPLEX} variable.
No particular requirements as to precision of any of these are placed on
the implementation, nor is the relationship of storage sizes of these
types to the @samp{CHARACTER} type specified by the standard.

@code{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 @samp{DOUBLE PRECISION}
on a boundary that is not an even multiple of its size, but still an
even multiple of the size of a @samp{REAL} 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 @code{gcc} and @code{g77}.
@code{g77} warns about such
situations when it encounters them.)

@code{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
@code{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 @code{gcc} built in the same release as @code{g77} (and
which was therefore used to build both the @code{g77} compiler
components and the @code{libf2c} run-time library):

@table @code
@cindex REAL type
@cindex types, REAL
@item REAL
Same as @samp{float} type.

@cindex DOUBLE PRECISION type
@cindex types, DOUBLE PRECISION
@item DOUBLE PRECISION
Same as whatever floating-point type that is twice the size
of a @samp{float}---usually, this is a @samp{double}.

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

@cindex LOGICAL type
@cindex types, LOGICAL
@item LOGICAL
Same @code{gcc} type as @samp{INTEGER}.

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

@cindex DOUBLE COMPLEX type
@cindex types, DOUBLE COMPLEX
@item DOUBLE COMPLEX
Two @samp{DOUBLE PRECISION} scalars.

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

@cindex KIND= notation
@item @var{numeric-type}(KIND=@var{n})
@var{n}=1 corresponds to @samp{REAL}, @samp{INTEGER}, @samp{LOGICAL},
@samp{COMPLEX}.
@var{n}=2 corresponds to @samp{DOUBLE PRECISION}, @samp{DOUBLE COMPLEX},
and, for integral types, @samp{char} (usually @samp{INTEGER*1}
and @samp{LOGICAL*1}).
@var{n}=3 corresponds to @samp{short} for integral types
(usually @samp{INTEGER*2} and @samp{LOGICAL*2}).
@var{n}=4 corresponds to @samp{long long} for integral types
(this usually means @samp{INTEGER*8} and @samp{LOGICAL*8}).

Note that these are proposed correspondences and might change
in future versions of @code{g77}---avoid writing code depending
on them.
@end table

For now, @code{g77} does not support numeric types other
than the ones listed above.
So, on a typical 32-bit machine, only @samp{INTEGER*4}, @samp{REAL*4},
@samp{LOGICAL*4}, @samp{COMPLEX*8}, and so on, will work.
Other types supported by @code{g77}
are derived from gcc types such as @samp{char}, @samp{short},
@samp{int}, @samp{long int}, @samp{long long int}, @samp{long double},
and so on.
That is, whatever types @samp{gcc} already supports, @code{g77} probably
will support in a future version.
The rules for the @samp{@var{numeric-type}*@var{n}} notation will
apply to the new 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 Constants
@section Constants
@cindex constants
@cindex types, constants

@code{g77} strictly assigns types to all constants not
documented as ``typeless'' (the typeless constants include things like
@samp{Z'1'}).
Context is never a determining factor for the type, and hence
the interpretation, of a typed constant.
Examples: @samp{1} is always type @samp{INTEGER},
@samp{3.141592653545256234} is always type @samp{REAL} (even if the
additional precision specified is lost, and even when used in a @samp{DOUBLE
PRECISION} context), @samp{1E0} is always type @samp{REAL}, and @samp{1D0}
is always type @samp{DOUBLE PRECISION}.

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.
@code{g77} will not support these dangerous
semantics, but 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 @code{g77} might differ
from how other compilers assign types to constants.

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

The @samp{-ffree-form} (aka @samp{-fno-fixed-form}) and @samp{-ffixed-form}
(aka @samp{-fno-free-form}) command-line options govern how the
source file is interpreted.
Fixed form
corresponds to classic 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 @samp{R = 3 . 1}).

The way a Fortran compiler views source files depends entirely on the
implementation choices made for the compiler.
GNU Fortran currently tries to be somewhat like a few popular compilers
(@code{f2c}, DEC Fortran, and so on), though a cleaner default
definition along with more
flexibility offered by command-line options is likely to be offered
in version 0.6.

Here are some facts regarding the way @code{g77} interprets source lines:

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

@cindex tab characters
@item
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 @code{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.

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

Note that this default behavior probably will change for version 0.6,
when it will presumably be available via a command-line option.
The default as of version 0.6 is planned to be a ``pure visual''
model, where tabs are immediately
converted to spaces and otherwise have no effect, so the way a typical
user sees source lines produces a consistent result no matter how the
spacing in those source lines is actually implemented via tabs, spaces,
and trailing tabs/spaces before newline.
Command-line options are likely to be added to specify whether all or
just-tabbed lines are to be extended to 132 or full input-line length,
and perhaps even an option will be added to specify the truncated-line
behavior to which some Digital compilers default (and which affects
the way continued character/Hollerith constants are interpreted).

@item
Source lines shorter than the applicable fixed length are treated as
if they were padded with spaces to that length.

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

@code{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 @samp{-ffixed-line-length-none}, for example.
@end itemize

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

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

With @samp{-ff90} in force along with @samp{-fpedantic}, some constructs are
accepted that result in diagnostics when @samp{-fno-f90} and
@samp{-fpedantic} are both in force.
@xref{Extensions,,GNU Fortran Extensions}, for information on those constructs.

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

@itemize @bullet
@item
Automatic arrays, as in @samp{REAL A(N)}, where @samp{A}
is not a dummy argument.

@item
@samp{READ (5), I} and @samp{WRITE (10), J}---the standard disallows the
comma in each case, while allowing it in @samp{READ 10, I}, but many
compilers (including @code{f2c}) allow the superfluous comma.

@item
@samp{DOUBLE COMPLEX}, either explicitly (via explicit or @samp{IMPLICIT}
statement) or implicitly (as in @samp{C*D}, where @samp{C} is @samp{COMPLEX}
and @samp{D} is @samp{DOUBLE PRECISION}, which is prohibited by the
standard because it should produce a non-standard @samp{DOUBLE COMPLEX}
result).

@item
Automatic conversion of numeric
expressions to @samp{INTEGER} in contexts such as:
@itemize --
@item
Array-reference indexes.
@item
Alternate-return values.
@item
Computed @samp{GOTO}.
@item
@samp{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 @samp{CHARACTER} entities in specification statements.
@item
Kind types in specification entities (a Fortran 90 feature).
@item
Initial, terminal, and incrementation parameters for implied-@samp{DO}
constructs in @samp{DATA} statements.
@end itemize

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

@item
Substring operators applied to character constants and named
constants (such as @samp{PRINT *,'hello'(3:5)}, which would print @samp{llo}).

@item
Null argument passed to statement function (as in @samp{PRINT *,FOO(,3)}).

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

@item
Differences between named-@samp{COMMON}-block sizes between program units.

@item
Specification statements following first @samp{DATA} statement (normally
@samp{DATA I/1/} may be followed by @samp{INTEGER J}, though not
@samp{INTEGER I}, but @samp{-fpedantic} disables use of both cases.

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

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

@item
Use of @samp{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 @samp{-fpedantic} is specified along with @samp{-ff90}, the
following constructs result in diagnostics:

@itemize @bullet
@item
Use of semicolons on line with INCLUDE statement.
@end itemize

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

Low-level switches are identified in this discussion thusly:

@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: @code{g77} eventually will support @samp{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, @samp{NAMELIST} is supported @samp{libf2c},
which uppercases @samp{NAMELIST} input and symbol names for matching.
This means not only that @samp{NAMELIST} output currently shows symbol
(and keyword) names in uppercase even if lower-case source
conversion (option A2) is selected, but that @samp{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 @samp{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 @samp{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 @samp{libg77} is written),
but that seems to be overkill for a product in beta test.

Note 2: Rules for InitialCaps names are:
@itemize --
@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 @samp{BN} and @samp{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 @samp{-fcase-strict-upper} to specify this
combination.

Number 43 is like Number 22 except all input must be lowercase.  Use
@samp{-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 @samp{-fcase-upper} to specify this combination.

Number 66 is the ``canonical'' UNIX model whereby all the source is
translated to lowercase.
Use @samp{-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 Intrinsics
@section Intrinsics
@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 @samp{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 @samp{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 @code{g77} to pretend as though the intrinsics in
that group do not exist at all, whereas disabling it tells @code{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 @samp{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 @samp{INTRINSIC} statements in the appropriate places.
However, it should be the goal of development to use @samp{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 @samp{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
@item dcp
@samp{DOUBLE COMPLEX} intrinsics from the standards (F77, F90).
@item f2c
Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
@item f90
Fortran 90 intrinsics.
@item mil
MIL-STD 1753 intrinsics (@samp{MVBITS}, @samp{IAND}, @samp{BTEST}, and so on).
@item unix
UNIX intrinsics (@samp{IARGC}, @samp{EXIT}, @samp{ERF}, and so on).
@item vxt
VAX/VMS FORTRAN (current as of v4) intrinsics.
@end table

@node Dialects
@section GNU Fortran Dialects
@cindex language dialects
@cindex dialects of language
@cindex Fortran 90 features
@cindex VXT features

The @samp{-fvxt-not-f90} and @samp{-ff90-not-vxt} command-line options
control how @code{g77} interprets certain tokens and constructs that
have different meanings in VAX FORTRAN (circa v4) and Fortran 90.
@cindex VXT extensions
@cindex extensions, VXT
(Generally, this manual uses the invented acronym VXT to refer
to many popular VAX FORTRAN extensions, though not necessarily
those that are specific to the VAX processor architecture or the
VMS operating system.
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 @code{g77}
someday, and is considered a VXT extension.)

When @samp{-ff90-not-vxt} is specified, the following interpretations are made
(and, when @samp{-fvxt-not-f90} is in effect, the opposite interpretations
are made):

@itemize @bullet
@cindex double quotes
@cindex character constants
@cindex constants, character
@cindex octal constants
@cindex constants, octal
@item
Double-quote character (@samp{"}) delimits character constant just as does
apostrophe (@samp{'}), rather than beginning an octal constant of
@samp{INTEGER} type.

@cindex exclamation points
@cindex continuation character
@cindex characters, continuation
@cindex comment character
@cindex characters, comment
@item
An exclamation point (@samp{!}) in column 5 of fixed-form source file
treated as a continuation character rather than the beginning of a comment
(as it does in any other column).

@cindex TYPE statement
@cindex statements, TYPE
@item
@samp{TYPE FOO} and @samp{TYPE (FOO), BAR}
statements are recognized as the Fortran 90 variety, not I/O statements.
(However, the F90 variety is @emph{not} supported, so this really just
ensures that @code{g77} will produce a diagnostic instead of trying to
implement the VXT @samp{TYPE} statement---which currently is not supported
either.)
@end itemize

@node Object Compatibility
@section Object Compatibility
@cindex object code
@cindex code, object
@cindex compatibility
@cindex f2c compatibility
@cindex compilers, compatibility

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
exectable 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
@samp{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, @code{g77} generates code that is
object-compatible with code generated by a version of
@code{f2c} configured (with, for example, @file{f2c.h} definitions)
to be generally compatible with @code{g77} as built by @code{gcc}.
(Normally, @code{f2c} will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of @code{f2c}, or versions having certain configuration changes
to @code{f2c} internals, will produce object files that are
incompatible with @code{g77}.)

For example, a Fortran string subroutine
argument will become two arguments on the C side: a @samp{char *}
and an @samp{int} length.

Much of this compatibility results from the fact that
@code{g77} uses the same run-time library, @code{libf2c}, used by
@code{f2c}.

Other compilers might or might not generate code that
is object-compatible with @code{libf2c} and current @code{g77},
and some might offer such compatibility only when explicitly
selected via a command-line option to the compiler.

@menu
* Dropping f2c Compatibility::  When speed is more important.
* Other Compilers::             Interoperation with code from other compilers.
@end menu

@node Dropping f2c Compatibility
@subsection Dropping f2c Compatibility

Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
some cases, faster code, by not needing to allow to the possibility
of linking with code compiled by @code{f2c}.

For example, this affects how @samp{REAL}, @samp{COMPLEX}, and
@samp{DOUBLE COMPLEX} functions are called.
With @samp{-fno-f2c}, they are
compiled as returning the appropriate @code{gcc} type
(@samp{float}, @samp{__complex__ float}, @samp{__complex__ double},
in many configurations).

With @samp{-ff2c} in force, they
are compiled differently (with perhaps slower run-time performance)
to accommodate the restrictions inherent in @code{f2c}'s use of K&R
C as an intermediate language---@samp{REAL} functions return double,
while @samp{COMPLEX} functions return
@samp{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 @samp{-ff2c} in force
might produce faster code than using @samp{-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 @code{f2c} compatibility is a fairly static target to achieve,
though not necessarily perfectly so, since, like @code{g77}, it is
still being improved.
However, specifying @samp{-fno-f2c} causes @code{g77}
to generate code that will probably be incompatible with code
generated by future versions of @code{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 @code{g77}
or @code{f2c}, especially when using options such as @samp{-fno-f2c}.

Therefore, if you are using @code{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 @code{g77},
you might want to stick with @code{f2c} compatibility for now, and
carefully watch for any announcements about changes to the
@code{f2c}/@code{libf2c} interface that might affect existing programs
(thus requiring recompilation).

It is probable that a future version of @code{g77} will not,
by default, generate object files compatible with @code{f2c} and not
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 either cause @code{g77} to produce compatible code
(at the expense of the availability of some features and
performance), or at the very least trigger
compiler warning messages, in future versions of @code{g77}.

@node Other Compilers
@subsection Other Compilers

On systems with Fortran compilers other than @code{f2c} and @code{g77},
code compiled by @code{g77} is not expected to work
well with code compiled by the native compiler.
(This is true for @code{f2c}-compiled objects as well.)
Libraries compiled with the native compiler probably will have
to be recompiled with @code{g77} to be used with @code{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 @code{g77} to call a procedure the linker @code{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 @code{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 Distensions
@section Distensions
@cindex distensions
@cindex ugly features
@cindex features, ugly

The @samp{-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.

The constructs enabled via @samp{-fugly} include:

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

@item
Use of typeless and Hollerith constants in non-standard places
(the ``standard'' here being the appendix in ANSI FORTRAN 77 and
the descriptions in MIL-STD 1753), plus in places controlled
by @samp{-fugly-args} and @samp{-fugly-init}.

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

@item
Use of a single trailing comma to mean ``pass an extra trailing null
argument'' in a list of actual arguments to a procedure other than a
statement function.

For example, @samp{CALL FOO(,)} means ``pass
two null arguments'' when @samp{-fugly} is used, rather than
``pass one null argument''.
@end itemize

The construct disabled via @samp{-fno-ugly-args} is:

@itemize @bullet
@cindex Hollerith constants
@cindex constants, Hollerith
@item
Passing of typeless and Hollerith constants as actual arguments
in procedure invocations.

For example, @samp{CALL FOO(4HABCD)}.
@end itemize

The constructs disabled by @samp{-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, @samp{DATA} and @samp{PARAMETER} statements, plus
type-declaration statements specifying initial values.

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

@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 to in invocations of
intrinsic procedures and statement functions) that
are treated as assignments to known types (the dummy
arguments, in these cases).
@end itemize

@include install.texi

@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 @code{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 @code{g77}-compiled code generally
requires some understanding of the way @code{g77} compiles code for
various constructs.

Similarly, using a debugger to debug @code{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
@code{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 @code{g77}, sometimes even to using certain compiler options
with @code{g77} (such as @samp{-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 @code{g77}.
This information
is provided primarily to make debugging of code generated by this
particular release of @code{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 @code{g77} as they
are installed, because new versions can change the behaviors
described in this section.

@menu
* Names::              Naming of user-defined variables, procedures, etc.
* Main Program Unit::  How @code{g77} compiles a main program unit.
* Arrays::             Dealing with (possibly multi-dimensional) arrays.
* Procedures::         How @code{g77} constructs parameter lists
                       for procedures.
* Adjustable Arrays::  Special consideration for adjustable arrays.
* Alternate Returns::  How @code{g77} handles alternate returns.
* Functions::          Functions returning floating-point or character data.
* Common Blocks::      Accessing common variables while debugging.
* Local Equivalence Areas::  Accessing @samp{EQUIVALENCE} while debugging.
* Alternate Entry Points::  How @code{g77} implements alternate @samp{ENTRY}.
* Assigned Statement Labels::  How @code{g77} handles @samp{ASSIGN}.
@end menu

@node Names
@section Names
@cindex symbol names
@cindex transformation of 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 @code{g77}, to generate code that is compatible with 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 @samp{-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.

When @samp{-funderscoring} is in force, any name (external or local)
that already has at least one underscore in it is
implemented by @code{g77} by appending two underscores.
External names are changed this way for @code{f2c} compatibility.
Local names are changed this way to avoid collisions with external names
that are different in the source code---@code{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

@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 @code{g77} in this regard in the future---don't
write scripts depending on this behavior!
Also, consider experimenting with the @samp{-fno-underscoring}
option to try out debugging without having to massage names by
hand like this.)

@code{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 = 3.14159
@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 @code{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, @code{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 @samp{-fno-underscoring} option
could be used to inhibit the appending of the underscore to the name.

@node Main Program Unit
@section Main Program Unit (PROGRAM)
@cindex PROGRAM statement
@cindex statements, PROGRAM

When @code{g77} compiles a main program unit, it gives it the public
procedure name @samp{MAIN__}.
The @code{libf2c} library has the actual @samp{main()} procedure
as is typical of C-based environments, and
it is this procedure that performs some initial start-up
activity and then calls @samp{MAIN__}.

Generally, @code{g77} and @code{libf2c} 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 @code{g77-0.5.16}
includes a bug fix for @code{libf2c} that solved a problem with using the
@samp{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 @code{g77} (or @code{f2c}) to compile
your main program unit---that is, if you intend to compile a @samp{main()}
procedure using some other language---you should carefully
examine the code for @samp{main()} in @code{libf2c}, found in the source
file @file{gcc/f/runtime/libF77/main.c}, to see what kinds of things
might need to be done by your @samp{main()} in order to provide the
Fortran environment your Fortran code is expecting.

@cindex IARGC() intrinsic
@cindex intrinsics, IARGC()
@cindex GETARG() intrinsic
@cindex intrinsics, GETARG()
For example, @code{libf2c}'s @samp{main()} sets up the information used by
the @samp{IARGC} and @samp{GETARG} intrinsics.
Bypassing @code{libf2c}'s @samp{main()}
without providing a substitute for this activity would mean
that invoking @samp{IARGC} and @samp{GETARG} would produce undefined
results.

@cindex debugging
@cindex main program unit, debugging
@cindex main()
@cindex MAIN__()
When debugging, one implication of the fact that @samp{main()}, which
is the place where the debugged program ``starts'' from the
debugger's point of view, is in @code{libf2c} 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 @samp{MAIN__}, and then run the program.

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 @samp{MAIN__},
that should work fine.

@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 @code{f2c}, @code{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
non-zero 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 Procedures
@section Procedures (SUBROUTINE and FUNCTION)
@cindex procedures
@cindex SUBROUTINE statement
@cindex statements, SUBROUTINE
@cindex FUNCTION statement
@cindex statements, FUNCTION
@cindex signature of procedures

Procedures that accept @samp{CHARACTER} arguments are implemented by
@code{g77} so that each @samp{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 @samp{ftnlen}
(see @file{gcc/f/runtime/f2c.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
@samp{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 @samp{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 @samp{CHARACTER} argument is present in the argument
list, the length arguments are appended in the order
the orginal arguments appear.
So @samp{CALL FOO('HI','THERE')} is implemented in
C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
does not provide the trailing null bytes on the constant
strings (@code{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 @samp{CHARACTER} variables and
arrays @strong{only}.
It does @strong{not} apply to external @samp{CHARACTER}
functions or to intrinsic @samp{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 @samp{CHARACTER}, subtle
symptoms might appear.

@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 @code{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, @code{g77} generates code that executes before any user
code (and before the internally generated computed @samp{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 @samp{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 @samp{NULL} pointer where a pointer to that
adjustable array would be expected.
The @code{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 @samp{NULL} at run time in
such cases.
(Don't depend on this particular implementation
by writing code that purposely passes @samp{NULL} pointers where the
callee expects adjustable arrays, even if you know the callee
won't reference the arrays---nor should you pass @samp{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 @code{g77} implements these things might
change in the future!)

@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 @code{g77} as functions returning
the C @samp{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-@samp{GOTO} statement, as in @samp{GOTO (50), X()} in the
example above (where @samp{X} is quietly declared as an @samp{INTEGER}
function), and the callee just returns whatever integer
is specified in the @samp{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 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

@code{g77} handles in a special way functions that return the following
types:

@itemize @bullet
@item
@samp{CHARACTER}
@item
@samp{COMPLEX} (and @samp{DOUBLE COMPLEX})
@item
@samp{REAL}
@end itemize

For @samp{CHARACTER}, @code{g77} implements a subroutine (a C function
returning @samp{void})
with two arguments prepended: @samp{__g77_result}, which the caller passes
as a pointer to a @samp{char} array expected to hold the return value,
and @samp{__g77_length}, which the caller passes as an @samp{ftnlen} value
specifying the length of the return value as declared in the calling
program.
For @samp{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 @samp{COMPLEX} and @samp{DOUBLE COMPLEX}, when @samp{-ff2c} is in
force, @code{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 @samp{-fno-f2c} is in force,
@code{g77} implements a @samp{COMPLEX} function as @code{gcc}'s
@samp{__complex__ float} function,
returning the result of the function in the same way as @code{gcc} would,
and implements a @samp{DOUBLE COMPLEX} function similarly.

For @samp{REAL}, when @samp{-ff2c} is in force, @code{g77} implements
a function that actually returns @samp{DOUBLE PRECISION} (usually
C's @samp{double} type).
When @samp{-fno-f2c} is in force, @samp{REAL} functions return @samp{float}.

@node Common Blocks
@section Common Blocks (COMMON)
@cindex common blocks
@cindex COMMON statement
@cindex statements, COMMON

@code{g77} names and lays out @samp{COMMON} areas the same way f2c does,
for compatibility with f2c.

Currently, @code{g77} does not emit any debugging information for
items in a @samp{COMMON} area, due to an apparent bug in the GBE.

Moreover, @code{g77} currently implements a @samp{COMMON} area such that its
type is an array of the C @samp{char} data type.

So, when debugging, you must know the offset into a @samp{COMMON} area
for a particular item in that area, and you have to take into
account the appropriate multiplier for the respective sizes
of the types (as declared in your code) for the items preceding
the item in question as compared to the size of the @samp{char} type.

For example, using default implicit typing, the statement

@example
COMMON I(15), R(20), T
@end example

@noindent
results in a public 144-byte @samp{char} array named @samp{_BLNK__}
with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
and @samp{T} at @samp{_BLNK__[140]}.
(This is assuming that the target machine for
the compilation has 4-byte @samp{INTEGER} and @samp{REAL} types.)

@node Local Equivalence Areas
@section Local Equivalence Areas (EQUIVALENCE)
@cindex equivalence areas
@cindex local equivalence areas
@cindex EQUIVALENCE statement
@cindex statements, EQUIVALENCE

@code{g77} treats storage-associated areas involving a @samp{COMMON}
block as explained in the section on common blocks.

A local @samp{EQUIVALENCE} area is a collection of variables and arrays
connected to each other in any way via @samp{EQUIVALENCE}, none of which are
listed in a @samp{COMMON} statement.

Currently, @code{g77} does not emit any debugging information for
items in a local @samp{EQUIVALENCE} area, due to an apparent bug in the GBE.

Moreover, @code{g77} implements a local @samp{EQUIVALENCE} area such that its
type is an array of the C @samp{char} data type.

The name @code{g77} gives this array of @samp{char} type is @samp{__g77_equiv_@var{x}},
where @var{x} is the name of the first item listed in the @samp{EQUIVALENCE}
statements for that area that is placed at the beginning (offset 0)
of this array.

When debugging, you must therefore access members of @samp{EQUIVALENCE}
areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
array section with the appropriate offset.
See the explanation of debugging @samp{COMMON} blocks
for info applicable to debugging local @samp{EQUIVALENCE} areas.

(Note: @code{g77} version 0.5.16 fixed a bug in how certain
@samp{EQUIVALENCE} cases were handled.
The bug caused the debugger to not know the size of the
array if any variable or array in the @samp{EQUIVALENCE} was given an initial
value via @samp{DATA} or similar.)

@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.
@code{g77} gets around this by using an approach to compiling procedures
having at least one @samp{ENTRY} statement that is almost identical to the
approach used by @code{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 @code{g77} implements @samp{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.

@code{g77} compiles exactly one public procedure for the primary entry
point of a procedure plus each @samp{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 @samp{ENTRY}
statement, @code{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 @code{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 @samp{ENTRY} statement encountered), 2 for
the second entry point, and so on.

It also contains, for functions returning @samp{CHARACTER} and
(when @samp{-ff2c} is in effect) @samp{COMPLEX} functions,
and for functions returning different types among the
@samp{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 @samp{CHARACTER} functions, this
storage area is an array of the appropriate number of characters;
for @samp{COMPLEX} functions, it is the appropriate area for the return
type (currently either @samp{COMPLEX} or @samp{DOUBLE COMPLEX}); for multiple-
return-type functions, it is a union of all the supported return
types (which cannot include @samp{CHARACTER}, since combining @samp{CHARACTER}
and non-@samp{CHARACTER} return types via @samp{ENTRY} in a single function
is not supported by @code{g77}).

For @samp{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 @samp{CHARACTER*(*)} functions and entry points actually
make use of this argument, even though it is always passed by
all callers of public @samp{CHARACTER} functions (since the caller does not
generally know whether such a function is @samp{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.
@samp{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 @code{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 @samp{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 @samp{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 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 @code{g77} implements @samp{ASSIGN} and its cousin, the assigned
@samp{GOTO}) is wider (bitwise) than an @samp{INTEGER}, @code{g77} does not
necessarily use
the same memory location to hold the @samp{ASSIGN}ed value of a variable
as it does the numerical value in that variable, unless the
variable is wide enough (can hold enough bits).

In particular, while @code{g77} implements

@example
I = 10
@end example

@noindent
as, in C notation, @samp{i = 10;}, it might implement

@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; @code{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 @samp{ASSIGN} statement might not
overwrite the numeric contents of its target variable, @emph{do not}
write any code depending on this feature.
@code{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 @code{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 @code{g77} has decided it can store the pointer to the label directly
into @samp{I} itself.

(Currently, @code{g77} always chooses to make the separate variable,
to improve the likelihood that @samp{-O -Wuninitialized} will
diagnose failures to do things like @samp{GOTO I} without
@samp{ASSIGN 10 TO I} despite doing @samp{I=5}.)

@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 @code{g77} can be divided into two camps:

@itemize @bullet
@item
Those writing new Fortran code to be compiled by @code{g77}.

@item
Those using @code{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 @samp{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 @code{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
* Overly Convenient Options::  Temptations to avoid, habits to not form.
* Block Data and Libraries::   How @code{g77} solves a common problem.
* Faster Programs::            Everybody wants these, but at what cost?
* Working Programs::           Getting programs to work should be done first.
* Loops::                      Fortran @samp{DO} loops surprise many people.
* Advantages Over f2c::        If @code{f2c} is so great, why @code{g77}?
@end menu

@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 @samp{DATA}, so that
@samp{-finit-local-zero} is not needed.

Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
find likely candidates, but
do not specify @samp{-finit-local-zero} or @samp{-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 @samp{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 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 @samp{SAVE}
statements to some or all program unit sources, as appropriate.
Consider using @samp{-Wuninitialized} (which requires @samp{-O})
to find likely candidates, but
do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
or this technique won't work.

The default is @samp{-fautomatic}, which tells @code{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 -fugly option
@cindex options, -fugly
@item -fugly
Fix the source code so that @samp{-fno-ugly} will work.
Note that, for many programs, it is difficult to practically
avoid using the features enabled via @samp{-fugly-init}, and these
features pose the lowest risk of writing nonportable code, among the
various ``ugly'' features.

@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 @samp{EXTERNAL} for any external procedure
that might be the name of an intrinsic.
It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
@end table

@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

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 @samp{BLOCK DATA}.
@code{g77} currently compiles a @samp{BLOCK DATA} as if it were a
@samp{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, @code{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, @code{g77} outputs in the data section a static pointer to the
external name @samp{FOO}.)

The implementation @code{g77} currently uses to make this work is
one of the few things not compatible with @code{f2c} as currently
shipped.
@code{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}, f2c doesn't generate a dummy procedure with the
name @samp{FOO}.
The upshot is that you shouldn't mix @samp{f2c} and @code{g77} in
this particular case.
If you use f2c to compile @samp{BLOCK DATA FOO},
then any @code{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 @code{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.

@node Faster Programs
@section Faster Programs
@cindex speeding up programs
@cindex programs, speeding up

Aside from the usual @samp{gcc} options, such as @samp{-O},
@samp{-ffast-math}, and so on, consider trying:

@table @code
@cindex -fno-f2c option
@cindex options, -fno-f2c
@item -fno-f2c
@cindex f2c compatibility
@cindex compatibility
Use this if you aren't linking with any code compiled using
@code{f2c}.
(Note that @code{libf2c} is @emph{not} an example of code
that is compiled using @code{f2c}---it is compiled by a C
compiler, usually @code{gcc}.)
@end table

If you're using @samp{-fno-automatic} already, you probably
should change your code to allow compilation with @samp{-fautomatic}
(the default), to allow the program to run faster.

Similarly, you should be able to use @samp{-fno-init-local-zero}
(the default) instead of @samp{-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, @samp{-fno-automatic}, which effectively @samp{SAVE}s
every local variable and array, affects even things like @samp{DO} iteration
variables, which rarely need to be @samp{SAVE}d, and this often reduces
run-time performances.
Similarly, @samp{-fno-init-local-zero} forces such
variables to be initialized to zero---when @samp{SAVE}d (such as when
@samp{-fno-automatic}), this by itself generally affects only
startup time for a program, but when not @samp{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 @samp{-fno-automatic} and
@samp{-finit-local-zero} options and how to convert
their use into selective changes in your own code.

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

@code{g77} offers some options that might be useful for
tracking down bugs in such programs.
@xref{Option Summary}, for a summary of these and other
options, and cross-references for each such option to
the pertinent material in this manual.

@table @code
@item -finit-local-zero
A program that works better when compiled with this option
is 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.

@item -fno-automatic
A program that works better when compiled with this option
is depending on not having to use the @samp{SAVE} statement
as required by the Fortran standard.
It might be worthwhile finding such cases and fixing them.

@item -Wimplicit
This 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.

@item -Wunused
This can find bugs involving implicitly typing, sometimes
more easily than using -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.

@item -Wuninitialized
This can find bugs involving uninitialized variables, which
can in turn result from misspellings in declaration statements.

@item -Wsurprising
This can find bugs involving expression evaluation or in
the way @samp{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 @code{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 @code{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.

@item -W
It is possible that the ``extra'' warnings enabled by this
option could expose bugs in the code.
@end table

@node Loops
@section Loops
@cindex DO statement
@cindex statements, DO
@cindex trips, number of
@cindex number of trips

The meaning of a @samp{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 @samp{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:

@example
DO @var{iter} = @var{start}, @var{end}, @var{increment}
@end example

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
the same type as @var{iter}, but the final
calculation, and thus the type of the trip
count itself, always is @samp{INTEGER}.
@end itemize

These two items mean that there are loops that cannot
be written in straightforward fashion using the Fortran @samp{DO}.

For example, on a system with the canonical 32-bit two's-complement
implementation of @samp{INTEGER}, the following loop will not work:

@example
DO I = -2000000000, 2000000000
@end example

@noindent
Although the @var{start} and @var{end} values are well within
the range of @samp{INTEGER}, the @emph{trip count} is not.
The expected trip count is 40000000001, which is outside
the range of @samp{INTEGER} on many systems.

Instead, the above loop should be constructed this way:

@example
I = -2000000000
DO
  IF (I .GT. 2000000000) EXIT
  @dots{}
  I = I + 1
END DO
@end example

@noindent
The simple @samp{DO} construct and the @samp{EXIT} statement
(used to leave the innermost loop)
are F90 features that @code{g77} supports.

Some Fortran compilers have buggy implementations of @samp{DO},
in that they don't follow the standard.
They implement @samp{DO} as a straightforward translation
to what, in C, would be a @samp{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:

@example
DO I = 2147483600, 2147483647
@end example

@noindent
A loop started by the above statement will work as implemented
by @code{g77}, but the use, by some compilers, of a
more C-like implementation akin to

@example
for (i = 2147483600; i <= 2147483647; ++i)
@end example

@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 @samp{DO} involves
using a nonintegral iteration variable @var{iter}, such as
a @samp{REAL} or @samp{DOUBLE PRECISION} 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 @samp{DO} would hold that the two ``exclamatory''
@samp{PRINT} are never executed.
However, this is the output of running the above program
as compiled by @code{g77} on a 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 @code{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 Linux
ix86 are used.
On other systems, an apparently more accurate trip count
of 31 might result, but, nevertheless, @code{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 @samp{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 @samp{DO} by standard-conforming
compilers such as @code{g77}, use of @samp{DO} loops
with @samp{REAL} or @samp{DOUBLE PRECISION} iteration
variables is not recommended.
Such use can be caught by specifying @samp{-Wsurprising}.
@xref{Warning Options}, for more information on this
option.

@node Advantages Over f2c
@section Advantages Over f2c

Without @code{f2c}, @code{g77} would have taken much longer to
do and probably not been as good for quite a while.
Sometimes people who notice how much @code{g77} depends on, and
documents encouragement to use, @code{f2c} ask why @code{g77}
was created if @code{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.
* Compiler Options::     Features helpful during development.
* 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

@code{g77} offers several extensions to the Fortran language that @code{f2c}
doesn't.

However, @code{f2c} offers a few that @code{g77} doesn't, like
fairly complete support for @samp{INTEGER*2}.
It is expected that @code{g77} will offer some or all of these missing
features at some time in the future.
(Version 0.5.18 of @code{g77} offers some rudimentary support for some
of these features.)

@node Compiler Options
@subsection Compiler Options

@code{g77} offers a whole bunch of compiler options that @code{f2c} doesn't.

However, @code{f2c} offers a few that @code{g77} doesn't, like an
option to generate code to check array subscripts at run time.
It is expected that @code{g77} will offer some or all of these
missing options 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 @code{g77} should be able to compile code much faster than using
@code{f2c} in conjunction with the equivalent invocation of @code{gcc}.

However, due to @code{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, @code{g77}
is noticably faster compiling many Fortran source files than using
@code{f2c} in conjunction with @code{gcc}.

@node Program Speed
@subsection Program Speed

@code{g77} has the potential to better optimize code than @code{f2c},
even when @code{gcc} is used to compile the output of @code{f2c},
because @code{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 @code{g77} can gather, preserve, and transmit that information directly
to the GBE.

For example, @code{g77} implements @samp{ASSIGN} and assigned
@samp{GOTO} using direct assignment of pointers to labels and direct
jumps to labels, whereas @code{f2c} maps the assigned labels to
integer values and then uses a C @samp{switch} statement to encode
the assigned @samp{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 @code{f2c} plus @code{gcc}
can generate code that is faster than @code{g77}.

It is hoped that version 0.5.18 of @code{g77} will offer default
settings and options that allow for better program speed, though
it is not yet known whether these same options, when applied to
a @code{gcc} compilation of @code{f2c} output, will improve the
speed of programs compiled using that method as well.

@node Ease of Debugging
@subsection Ease of Debugging

Because @code{g77} compiles directly to assembler code like @code{gcc},
instead of translating to an intermediate language (C) as does @code{f2c},
support for debugging can be better for @code{g77} than @code{f2c}.

However, although @code{g77} might be somewhat more ``native'' in terms of
debugging support than @code{f2c} plus @code{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, @code{g77} doesn't have to worry about reserved names
like @code{f2c} does.
Given @samp{FOR = WHILE}, @code{f2c} must necessarily
translate this to something @emph{other} than
@samp{for = while;}, because C reserves those words.

However, @code{g77} does still uses things like an extra level of indirection
for @samp{ENTRY}-laden procedures---in this case, because the back end doesn't
yet support multiple entry points.

Another example is that, given

@example
COMMON A, B
EQUIVALENCE (B, C)
@end example

@noindent
the @code{g77} user should be able to access the variables directly, by name,
without having to traverse C-like structures and unions, while @code{f2c}
is unlikely to ever offer this ability (due to limitations in the
C language).

However, due to apparent bugs in the back end, @code{g77} currently doesn't
take advantage of this facility at all---it doesn't emit any debugging
information for @samp{COMMON} and @samp{EQUIVALENCE} areas,
other than information
on the array of @samp{char} it creates (and, in the case
of local @samp{EQUIVALENCE}, names) for each such area.

Yet another example is arrays.
@code{g77} represents them to the debugger
using the same ``dimensionality'' as in the source code, while @code{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 @code{g77} can vary widely.
In some cases, it can actually
be an advantage that @code{f2c} converts everything to widely supported
C semantics.

In fairness, @code{g77} could do many of the things @code{f2c} does
to get things working at least as well as @code{f2c}---for now,
the maintainers have tended to prefer making @code{g77} work the
way they think it is supposed to, and find help improving the
other products (the GBE of @code{gcc}; @code{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,
@code{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.

@code{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 @code{g77} simply asks for fewer zeros from the operating
system than @code{f2c}.

@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 may 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.

Information on bugs that show up when configuring, porting, building,
or installing @code{g77} is not provided here.
@xref{Problems Installing}.

(Note that some of this portion of the manual is lifted
directly from the @code{gcc} manual, with minor modifications
to tailor it to users of @code{g77}.
Anytime a bug seems to have more to do with the @code{gcc}
portion of @code{g77},
@xref{Trouble,,Known Causes of Trouble with GNU CC,
gcc,Using and Porting GNU CC}.)

@menu
* But-bugs::         Bugs really in other programs.
* Actual Bugs::      Bugs and misfeatures we will fix later.
* 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 @code{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 @code{g77} is installed or is being used;
some just cannot be addressed at this time until more
is known about the problem.

Please don't re-report these bugs to the @code{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 @code{g77} maintainers have their hands full working on
just fixing and improving @code{g77}, without serving as a
clearinghouse for all bugs that happen to affect @code{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.

@itemize @bullet
@item
@cindex common blocks, large
@cindex large common blocks
@cindex linker errors
@cindex ld errors
@cindex errors, linker
On some older 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 @code{ld}, fixed in
more recent versions of @code{binutils}, such as version 2.6.

@cindex @code{gdb} support
@cindex support, @code{gdb}
@item
There are some known problems when using @code{gdb} on code
compiled by @code{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 @samp{COMPLEX*16} dummy array, on at least some Linux machines, plus
some others.

@item
@cindex unresolved reference (various)
@cindex linking error for user code
@cindex code, user
@cindex ld error for user code
@cindex ld can't find strange names
On some systems, perhaps just those with out-of-date (shared?)
libraries, unresolved-reference errors happen when linking @code{g77}-compiled
programs (which should be done using @code{g77}).

If this happens to you, try appending @samp{-lc} to the command you
use to link the program, e.g. @samp{g77 foo.f -lc}.
@code{g77} already specifies @samp{-lf2c -lm} when it calls the linker,
but it cannot also specify @samp{-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{-lf2c -lm} is insufficient to resolve code produced
by @code{g77}.

@item
@cindex undefined reference (_main)
@cindex linking error for user code
@cindex ld error for user code
@cindex code, user
@cindex ld can't find _main
If your program doesn't link, due to unresolved references to names
like @samp{_main}, make sure you're using the @code{g77} command to do the
link, since this command ensures that the necessary libraries are
loaded by specifying @samp{-lf2c -lm} when it invokes the @code{gcc}
command to do the actual link.
(Use the @samp{-v} option to discover
more about what actually happens when you use the @code{g77} and @code{gcc}
commands.)

Also, try specifying @samp{-lc} as the last item on the @code{g77}
command line, because some systems need it and @code{g77} doesn't do it
automatically.

@item
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 @code{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{gcc/f/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
(@code{toon@@moene.indiv.nluug.nl}).)

@item
@code{g77} rejects some particularly nonportable,
silent data-type conversions such as @samp{LOGICAL}
to @samp{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
is type @samp{REAL}), that other compilers might
quietly accept.

Some of these conversions are accepted by @code{g77}
when the @samp{-fugly} option is specified.
@end itemize

@include bugs.texi

@node Missing Features
@section Missing Features

This section lists features we know are missing from @code{g77},
and which we want to add someday.
(There is no priority implied in the ordering below.)

@itemize @bullet
@item
@cindex Fortran 90 support
@cindex support, Fortran 90
@code{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 listed here, 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 @code{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 listed here,
because no attempt has been made to research each and
every feature and assess its viability in @code{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.

@item
@cindex AND intrinsic
@cindex intrinsics, AND
@cindex OR intrinsic
@cindex intrinsics, OR
@cindex SHIFT intrinsic
@cindex intrinsics, SHIFT
@code{g77} does not allow @samp{REAL} and other non-integral types for
arguments to intrinsics like @samp{AND}, @samp{OR}, and @samp{SHIFT}.

@item
@cindex INTEGER*2 support
@cindex LOGICAL*1 support
@code{g77} doesn't support @samp{INTEGER*2}, @samp{LOGICAL*1}, and similar.
Version 0.6 will provide full support for this extremely
important set of features.
In the meantime, version 0.5.18 provides rudimentary support
for them.

@item
@code{g77} rejects things other compilers accept,
like @samp{INTRINSIC SIN,SIN}.
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 @code{g77} (though @samp{-fpedantic} should
trigger warnings about such non-standard constructs).

In the meantime, 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 @samp{INCLUDE} file that
defines a common block, it might be appropriate to
include a @samp{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 @samp{SAVE} statements in an @samp{INCLUDE}
file would prevent otherwise standard-conforming code
from also specifying the @samp{SAVE} statement, by itself,
to indicate that all local variables and arrays are to
have the @samp{SAVE} attribute.

For this reason, @code{g77} already has been changed to
allow this combination, because although the general
problem of gratuitously rejecting unambiguous and
``safe'' constructs still exists in @code{g77}, this
particular construct was deemed useful enough that
it was worth fixing @code{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 @code{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 @code{g77} just for cases like yours.

@item
@cindex PARAMETER statement
@cindex statements, PARAMETER
@code{g77} doesn't accept @samp{PARAMETER I=1}.
Supporting this obsolete form of
the @samp{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 @samp{PARAMETER} statement as well,
otherwise, in the obsolete form of @samp{PARAMETER}, the
type of the variable is set from the type of the constant being
assigned to it).

@item
@cindex POINTER statement
@cindex statements, POINTER
@cindex Cray pointers
@code{g77} doesn't support pointers or allocatable objects.
This set of features is
probably considered just behind @samp{INTEGER*2} and intrinsics
in @samp{PARAMETER} statements on the list of large,
important things to add to @code{g77}.

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

@cindex STRUCTURE statement
@cindex statements, STRUCTURE
@cindex UNION statement
@cindex statements, UNION
@cindex RECORD statement
@cindex statements, RECORD
@cindex MAP statement
@cindex statements, MAP
@item
@code{g77} doesn't support @samp{STRUCTURE}, @samp{UNION}, @samp{RECORD},
@samp{MAP}.
This set of extensions is quite a bit
lower on the list of large, important things to add to @code{g77}, partly
because it requires a great deal of work either upgrading or
replacing @code{libf2c}.

@cindex disposition of files
@cindex OPEN statement
@cindex statements, OPEN
@cindex CLOSE statement
@cindex statements, CLOSE
@cindex INQUIRE statement
@cindex statements, INQUIRE
@item
There is no support for keywords such as @samp{DISP='DELETE'} in
the @samp{OPEN}, @samp{CLOSE}, and @samp{INQUIRE} statements.
These extensions are easy to add to @code{g77} itself, but
require much more work on @code{libf2c}.

@cindex PARAMETER statement
@cindex statements, PARAMETER
@item
@code{g77} doesn't allow intrinsics in @samp{PARAMETER} statements.
This feature is considered to be absolutely vital, even though it
is not standard-conforming, and is scheduled for version 0.6.

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

@cindex FORMAT statement
@cindex statements, FORMAT
@item
@code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
Supporting this requires a significant redesign or replacement
of @code{libf2c}.

@item
Need option to suppress information messages (notes).
@samp{-w} does this but also suppresses warnings.
The default should be to suppress info messages.

@item
Provide some way, a la @code{gcc}, for @code{g77} code to specify assembler
code.

@item
Support @samp{INTEGER}, @samp{REAL}, and @samp{COMPLEX} equivalents
for all applicable back-end-supported types (@samp{char}, @samp{short int},
@samp{int}, @samp{long int}, @samp{long long int}, and @samp{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 @samp{INTEGER*1},
@samp{INTEGER*2}, @samp{INTEGER*8}, and so on.
This is scheduled for version 0.6.

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

That is, 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.

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, @code{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.

@item
Support more general expressions to dimension
arrays, such as array element references, function
references, etc.

@item
A @samp{FLUSH} statement that does what many systems provide via
@samp{CALL FLUSH},
but that supports @samp{*} as the unit designator (same unit as for
@samp{PRINT}).

@item
Finish support for old-style @samp{PARAMETER} statement (like F77
@samp{PARAMETER}, but type of destination is set from type of
source expression).

@item
Character-type selector/cases for @samp{SELECT CASE}.

@item
Option to initialize everything not explicitly initialized to ``weird''
(machine-dependent) values, e.g. NANs, bad (non-@samp{NULL}) pointers, and
largest-magnitude integers.

@item
Add run-time bounds-checking of array/subscript references a la @code{f2c}.

@item
Output 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.

@item
Support the POSIX standard for Fortran.

@item
Support Digital-style lossage of virtual blanks at end of source line
if some command-line option 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:

@example
10    PRINT *,'HOW MANY
     1 SPACES?'
@end example

@code{g77}, and many other compilers, virtually extend
the continued line through column 72 with blanks 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.
@code{g77} should return the favor by offering conformance
to Digital's approach to handling the above example.

@item
Consider a preprocessor designed specifically for Fortran to replace
@samp{cpp -traditional}.
There are several out there worth evaluating, at least.

@item
Have @samp{-Wunused} warn about unused labels.

@item
Warn about assigned @samp{GOTO}/@samp{FORMAT} usage without any
@samp{ASSIGN} to variable.
(Actually, use of @samp{-O -Wuninitialized} should
take care of most of these.)

@item
Add @samp{-Wintrinsics} to warn about use of
non-standard intrinsics without explicit @samp{INTRINSIC} statements for them
(to help find code that might fail silently when ported to another
compiler).

@item
Support @samp{-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 @samp{COMMON} (F77 does not allow it to be
placed in @samp{COMMON} via @samp{EQUIVALENCE}); if specification statements
follow statement-function-definition statements; about all sorts of
syntactic extensions.

@item
Warn about modifying @samp{DO} variables via @samp{EQUIVALENCE}.
(This test might 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.)

@item
Add @samp{-Wpromotions} to warn if source code appears
to expect automatic, silent, and
somewhat dangerous compiler-assisted conversion of @samp{REAL}
constants to @samp{DOUBLE PRECISION} based on context.

For example, warn about cases like this:

@example
DOUBLE PRECISION FOO
PARAMETER (PI = 3.14159)
FOO = PI * 3D0
@end example

@item
Generally continue processing for warnings and recoverable (user)
errors whenever possible---don't gratuitously make bad code.

For example:

@example
INTRINSIC ZABS
CALL FOO(ZABS)
END
@end example

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

@item
If @samp{-fno-ugly}, reject badly designed trailing-radix quoted (typeless)
numbers, such as @samp{'123'O}.

@item
Add @samp{-Wugly*}, @samp{-Wautomatic}, @samp{-Wvxt-not-f90}, @samp{-Wf90},
and so on.
These would warn about places in the user's source where ambiguities
are found.

One especially interesting case that @samp{-Wf90} would catch
is use of @samp{REAL(Z)}, where @samp{Z} is @samp{DOUBLE COMPLEX}.
Apparently, traditional extended F77 compilers treat this as
what all compilers should agree is @samp{REAL(REAL(Z))}, while
F90 compilers are required to treat @samp{REAL(Z)} as the same
as @samp{DBLE(Z)}, returning a @samp{DOUBLE PRECISION} result
rather than a @samp{REAL} result.

@item
@samp{-Wconversion} and related should flag places where non-standard
conversions are found.
Perhaps much of this would be part of @samp{-Wugly*}.

@item
Complain when list of dummies containing an adjustable dummy array does
not also contain every variable listed in the dimension list of the
adjustable array.

Currently, @code{g77} does complain about a variable that
dimensions an array but doesn't appear in any dummy list or @samp{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.

@item
Make sure things like @samp{RETURN 2HAB} are invalid in both source forms
(must be @samp{RETURN (2HAB)},
which probably still makes no sense but at least can
be reliably parsed).
Fixed form rejects it, but not free form, except
in a way that is a bit difficult to understand.

@item
The sort of routines usually found in the BSD-ish @code{libU77} should be
provided in addition to the few utility routines in @code{libf2c}.
Much of this work has already been done, and is awaiting
integration into @code{g77}.
@end itemize

@node Disappointments
@section Disappointments and Misunderstandings

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

@itemize @bullet
@item
@cindex IMPLICIT CHARACTER*(*) statement
@cindex statements, IMPLICIT CHARACTER*(*)
@code{g77} disallows @samp{IMPLICIT CHARACTER*(*)}.
This is not standard-conforming,
and there are some very good reasons for that.
When I next remember any, I'll try to write them down.

@cindex block data
@cindex BLOCK DATA statement
@cindex statements, BLOCK DATA
@cindex COMMON statement
@cindex statements, COMMON
@cindex naming conflicts
@item
@code{g77} doesn't allow a common block and an external procedure or
@samp{BLOCK DATA} to have the same name.
Some systems allow this, but @code{g77} does not,
to be compatible with @code{f2c}.

@code{g77} could special-case the way it handles
@samp{BLOCK DATA}, since it is not compatible with @code{f2c} in this
particular area (necessarily, since @code{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 @code{g77} would treat these references as requests to
force-load BLOCK DATA program units.

In that case, if @code{g77} modified
names of @samp{BLOCK DATA} so they could have the same names as
@samp{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,
@code{g77} could emit a null-but-externally-satisfying definition of
@samp{FOO} with its name transformed as if it had been a
@samp{BLOCK DATA}, but that probably invites more trouble than it's
worth.)

@item
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.
@end itemize

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

@itemize @bullet
@cindex backslash
@cindex f77 support
@cindex support, f77
@item
@samp{-fno-backslash} should be the default, not @samp{-fbackslash}.

First of all, you  can always specify
@samp{-fno-backslash} to turn off this processing.

Despite not being within the spirit (though apparently within the
letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
@samp{-fbackslash} because that is what most UNIX @code{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 @samp{-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 @samp{-fno-backslash} the default for GNU
Fortran and thus require users of UNIX @code{f77} and @code{f2c}
to specify @samp{-fbackslash} to get the UNIX behavior.

However, the realization that @code{g77} is intended as
a replacement for @emph{UNIX} @code{f77}, caused the author
to choose to make @code{g77} as compatible with
@code{f77} as feasible, which meant making @samp{-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 @code{f77} to do, by default?''
Although at least one UNIX @code{f77} does not provide
@samp{-fbackslash} as a default, it appears that, by far,
the majority of them do, which suggests that, by far,
the majority of code that is compiled by UNIX @code{f77}
compilers expects @samp{-fbackslash} to be the default.

It is probably the case that more code exists
that would @emph{not} work with @samp{-fbackslash}
in force than code that requires it be in force.

However, most of @emph{that} code is not being compiled
with @code{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
@code{g77}'s default of @samp{-fbackslash} than would
exist for the majority of UNIX @code{f77} users who
would have to modify existing, working build procedures
to explicitly specify @samp{-fbackslash} if that was
not the default.

One suggestion has been to configure the default for
@samp{-fbackslash} (and perhaps other options as well)
based on the configuration of @code{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 @code{gcc}.
To change them for @code{g77}, you must first change them
for @code{gcc}.
Do not ask the maintainers of @code{g77} to do this for you,
or to disassociate @code{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).

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:

@example
CHARACTER BACKSL
PARAMETER (BACKSL = '\\')
@end example

Then, use concatenation of @samp{BACKSL} anyplace a backslash
is desired.
(However, this technique does not work for Hollerith constants---which
is good, since the only generally portable uses for Hollerith
constants are in places where character constants can and should
be used instead, for readability.)

In this way, users can write programs which have the same meaning
in many Fortran dialects.

@item
@code{g77} does not use context to determine the types of
constants or named constants (@samp{PARAMETER}).

For example, consider the following statement:

@example
PRINT *, 3.1415926535 * 2D0
@end example

@code{g77} will interpret the (truncated) constant
@samp{3.1415926535} as a @samp{REAL}, not @samp{DOUBLE PRECISION},
constant, because the suffix @samp{D0} is not specified.

As a result, the output of the above statement when
compiled by @code{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:

@example
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 example

Running the above program should
result in the same value being
printed three times.
With @code{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 (@samp{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.
@code{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
@code{g77} can do to help flag cases of this in such code
could be very helpful.

@item
@code{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 IFIX} is interpreted by @code{g77} first as
a reference to the @samp{IFIX} intrinsic, because the reference
is a procedure invocation (as compared to @samp{J=IFIX}); only
after establishing that, in the program unit being compiled,
@samp{IFIX} is in fact an intrinsic and not a local name that
happens to have the same name as an intrinsic, does @code{g77}
recognize that the form of the reference is invalid for that
particular intrinsic.
At that point, @code{g77} issues a diagnostic.

Some users claim that it is ``obvious'' that @samp{CALL IFIX}
references an external subroutine of their own, not an
intrinsic function.

However, @code{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, @code{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.

Use the @samp{EXTERNAL IFIX} statement in a program unit that calls
a user-written subroutine named @samp{IFIX}.

@item
Allow @samp{DATA VAR/.../} to come before @samp{COMMON /.../ ...,VAR,...}.

It is @emph{possible} @code{g77} will someday allow this.

Then again, maybe it is better to have
@code{g77} always require placement of @samp{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 @samp{COMMON} area following as-yet-uninitialized stuff,
and to do this it cannot be followed by @samp{COMMON A}.

@item
Making side effects happen in the same order as in some other compiler.

@cindex side effects, order of evaluation
@cindex order of evaluation, side effects
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:

@example
J = IFUNC() - IFUNC()
@end example

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).
@end itemize

@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
@samp{-W} options (for instance, @samp{-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 @code{g77} diagnostics.
Probably, as of version 0.6, @code{g77} will
no longer print the text of the source line, instead printing
the column number following the file name and line number in
a form that GNU Emacs recognizes.
This change is expected to speed up and reduce the memory usage
of the @code{g77} compiler.
@c
@c Say this when it is true -- hopefully 0.6, maybe 0.7 or later.  --burley
@c
@c GNU Fortran always tries to compile your program if possible; it never
@c gratuitously rejects a program whose meaning is clear merely because
@c (for instance) it fails to conform to a standard.  In some cases,
@c however, the Fortran standard specifies that certain extensions are
@c forbidden, and a diagnostic @emph{must} be issued by a conforming
@c compiler.  The @samp{-pedantic} option tells GNU Fortran to issue warnings
@c in such cases; @samp{-pedantic-errors} says to make them errors instead.
@c This does not mean that @emph{all} non-ANSI constructs get warnings
@c or errors.

@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{g77} treats constants like @samp{Z'ABCD'} and @samp{'ABCD'Z}
as typeless.
It seems like maybe the prefix-letter form, @samp{Z'ABCD'}, should
be @samp{INTEGER} instead.

You can test for yourself whether a particular compiler treats
the prefix form as @samp{INTEGER} or typeless by running the
following program:

@smallexample
EQUIVALENCE (I, R)
R = Z'ABCD'
J = Z'ABCD'
IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
END
@end smallexample

If you wish to report the results of this test to the
maintainers of @code{g77}, please include full information
on the compiler, system, and version information you're
using.
(We already know how @code{g77} handles it, of course.)

Perhaps this will be changed in version 0.6.

@item
@samp{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.
* Patches: Sending Patches.  How to send a patch for GNU Fortran.
* Known: Trouble.            Known problems.
* Help: Service.             Where to ask for help.
@end menu

@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
(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

@node Bug Lists
@section Where to Report Bugs
@cindex bug report mailing lists
@kindex fortran@@gnu.ai.mit.edu
Send bug reports for GNU Fortran to @samp{fortran@@gnu.ai.mit.edu}.

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 may 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 @code{tar} archive, and, whether you need to
do that, it is acceptable to then compress the single file (@code{tar}
archive or source file)
using @code{gzip} and encode it via @code{uuencode}.
Do not use any MIME stuff---the current maintainer can't decode this.
Using @code{compress} instead of @code{gzip} is acceptable, assuming
you have licensed the use of the patented algorithm in
@code{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 @code{g77} with the @samp{-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
A complete input file that will reproduce the bug.
If the bug is in the compiler proper (@file{f771}) and
you are using the C preprocessor, run your
source file through the C preprocessor by doing @samp{g77 -E
@var{sourcefile} > @var{outfile}}, then include the contents of
@var{outfile} in the bug report.  (When you do this, use the same
@samp{-I}, @samp{-D} or @samp{-U} options 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; and 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
frequently depend on every little detail of the function they happen in.

@item
@cindex included files
@cindex INCLUDE statement
@cindex statements, INCLUDE
Note that you should include with your bug report any files
included by the source file (via the @samp{INCLUDE} statement)
that you send, and any files they @samp{INCLUDE},
and so on.

It is not necessary to replace the @samp{INCLUDE} statements
with the actual files in the version of the source file that
you send, but it might make submitting the bug report easier
on the ends.
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 @samp{-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 @code{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 @samp{-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 @code{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 may 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.

@xref{Sending Patches}, 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 Sending Patches,, Bug Reporting, Bugs
@section Sending Patches for GNU Fortran

If you would like to write bug fixes or improvements for the GNU Fortran
compiler, that is very helpful.
Send suggested fixes to the bug report
mailing list, @code{fortran@@gnu.ai.mit.edu}.

Please follow these guidelines so we can study your patches efficiently.
If you don't follow these guidelines, your information might still be
useful, but using it will take extra work.  Maintaining GNU Fortran is a lot
of work in the best of circumstances, and we can't keep up unless you do
your best to help.

@itemize @bullet
@item
Send an explanation with your changes of what problem they fix or what
improvement they bring about.  For a bug fix, just include a copy of the
bug report, and explain why the change fixes the bug.

(Referring to a bug report is not as good as including it, because then
we will have to look it up, and we have probably already deleted it if
we've already fixed the bug.)

@item
Always include a proper bug report for the problem you think you have
fixed.  We need to convince ourselves that the change is right before
installing it.  Even if it is right, we might have trouble judging it if
we don't have a way to reproduce the problem.

@item
Include all the comments that are appropriate to help people reading the
source in the future understand why this change was needed.

@item
Don't mix together changes made for different reasons.
Send them @emph{individually}.

If you make two changes for separate reasons, then we might not want to
install them both.  We might want to install just one.  If you send them
all jumbled together in a single set of diffs, we have to do extra work
to disentangle them---to figure out which parts of the change serve
which purpose.  If we don't have time for this, we might have to ignore
your changes entirely.

If you send each change as soon as you have written it, with its own
explanation, then the two changes never get tangled up, and we can
consider each one properly without any extra work to disentangle them.

Ideally, each change you send should be impossible to subdivide into
parts that we might want to consider separately, because each of its
parts gets its motivation from the other parts.

@item
Send each change as soon as that change is finished.  Sometimes people
think they are helping us by accumulating many changes to send them all
together.  As explained above, this is absolutely the worst thing you
could do.

Since you should send each change separately, you might as well send it
right away.  That gives us the option of installing it immediately if it
is important.

@item
Use @samp{diff -c} to make your diffs.  Diffs without context are hard
for us to install reliably.  More than that, they make it hard for us to
study the diffs to decide whether we want to install them.  Unidiff
format is better than contextless diffs, but not as easy to read as
@samp{-c} format.

If you have GNU diff, use @samp{diff -cp}, which shows the name of the
function that each change occurs in.
(The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)

@item
Write the change log entries for your changes.  We get lots of changes,
and we don't have time to do all the change log writing ourselves.

Read the @file{ChangeLog} file to see what sorts of information to put
in, and to learn the style that we use.  The purpose of the change log
is to show people where to find what was changed.  So you need to be
specific about what functions you changed; in large functions, it's
often helpful to indicate where within the function the change was.

On the other hand, once you have shown people where to find the change,
you need not explain its purpose.  Thus, if you add a new function, all
you need to say about it is that it is new.  If you feel that the
purpose needs explaining, it probably does---but the explanation will be
much more useful if you put it in comments in the code.

If you would like your name to appear in the header line for who made
the change, send us the header line.

@item
When you write the fix, keep in mind that we can't install a change that
would break other systems.

People often suggest fixing a problem by changing machine-independent
files such as @file{toplev.c} to do something special that a particular
system needs.  Sometimes it is totally obvious that such changes would
break GNU Fortran for almost all users.  We can't possibly make a change like
that.  At best it might tell us how to write another patch that would
solve the problem acceptably.

Sometimes people send fixes that @emph{might} be an improvement in
general---but it is hard to be sure of this.  It's hard to install
such changes because we have to study them very carefully.  Of course,
a good explanation of the reasoning by which you concluded the change
was correct can help convince us.

The safest changes are changes to the configuration files for a
particular machine.  These are safe because they can't create new bugs
on other machines.

Please help us keep up with the workload by designing the patch in a
form that is good to install.
@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 @code{fortran@@gnu.ai.mit.edu}.
@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 @code{g77}, first decide
what kind of option you wish to add.
Search the @code{g77} and @code{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 @code{g77} and @code{gcc}, but
they mean something only when these commands actually
compile 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{gcc/f/lang-options.h},
which is used when during the build of @code{gcc} to
build a list of all options that are accepted by
at last one language's compiler.
This list goes into the @samp{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 @samp{lang_option_decode}, which, for
@code{g77}, is in @file{gcc/f/com.c} and just
calls @samp{ffe_decode_option}.

Even 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 @samp{-fno-asm} option;
even though the @code{f771} version of @samp{lang_decode_option}
rejects @samp{-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 @samp{-fno-asm}---perhaps
a warning about this would be helpful if it were
possible.

Code that processes Fortran options is found in
@file{gcc/f/top.c}, function @samp{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{gcc/f/top.c}.
Some of these defaults are actually macros defined
in @file{gcc/f/target.h}, since they might be
machine-specific, although, in practice, GNU compilers
should behave the same way on all configurations
(especially when it comes to language constructs).

Accessor macros for Fortran options, used by code
in the @code{g77} FFE, are defined in @file{gcc/f/top.h}.

@emph{Compiler options} are listed in @file{gcc/toplev.c}
in the array @samp{f_options}.
An option not listed in @samp{lang_options} is
looked up in @samp{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 way @code{f771} handles the @samp{-fset-g77-defaults}
option, which is always provided as the first option when
called by @code{g77} or @code{gcc}.

This code is in @samp{ffe_decode_options} in @file{gcc/f/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 @samp{-fset-g77-defaults} option is passed to @code{f771}
automatically because of the specification information
kept in @file{gcc/f/lang-specs.h}.
This file tells the @code{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{gcc/f/lang-specs.h} that @samp{-fset-g77-defaults},
@samp{-fversion}, and other options are passed, as appropriate,
even when the user has not explicitly specified them.
Other ``internal'' options such as @samp{-quiet} also
are passed via this mechanism.

@node Projects
@chapter Projects
@cindex projects

If you want to contribute to @code{g77} by doing research,
design, specification, documentation, coding, or testing,
the following information should give you some ideas.

@menu
* Efficiency::               Make @code{g77} itself compile code faster.
* Better Optimization::      Teach @code{g77} to generate faster code.
* Simplify Porting::         Make @code{g77} easier to configure, build,
                             and install.
* More Extensions::          Features many users won't know to ask for.
* Machine Model::            @code{g77} should better leverage @code{gcc}.
* Internals Documentation::  Make maintenance easier.
* Internals Improvements::   Make internals more robust.
* Better Diagnostics::       Make using @code{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 @samp{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,
@samp{COMMON} areas, @samp{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(...)}, where the intrinsic
is not a subroutine intrinsic, would result actual error instead of the
unimplemented-statement catch-all.

@item
Throughout @code{g77}, don't pass line/column pairs where
a simple @samp{ffewhere} type, which points to the error as much as is
desired by the configuration, will do, and don't pass @samp{ffelexToken} types
where a simple @samp{ffewhere} type will do.
Then, allow new default
configuration of @samp{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 @code{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 @samp{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 @code{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
Get the back end to produce at least as good code involving array
references as does @code{f2c} plus @code{gcc}.
(@emph{Note:} 0.5.18, with its improvements to the GBE for
versions 2.7.1 and 2.7.2 of @code{gcc}, should succeed at
doing this.
Please submit any cases where @code{g77} cannot be made to
generate as optimal code as @code{f2c} in combination with
the same version of @code{gcc}, but only for versions 2.7.1 and
greater of @code{gcc}.)

@item
Do the equivalent of the trick of putting @samp{extern inline} in front
of every function definition in @code{libf2c} and #include'ing the resulting
file in @code{f2c}+@code{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 @samp{VAR_DECL},
make @samp{CHAR_VAR}, not a
temporary, be the receiver for @samp{CHAR_FUNC}.
(This is now done for @samp{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{libf2c} would be moved at least to the
@code{g77} compile phase, if not to finer grains (such as choosing how
list-directed I/O formatting is done by default at @samp{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 @samp{COMPLEX} functions return their values in the way
@code{gcc} would if they were declared @samp{__complex__ float},
rather than using
the mechanism currently used by @samp{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 @samp{COMPLEX} functions in some cases once @code{g77} uses
@code{gcc} rather than @code{f2c} calling conventions.)

@item
Do something useful with @samp{doiter} references where possible.
For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
a @samp{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 @code{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{libf2c}) should improve portability as well as
produce more optimal code.
Further, @code{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 @samp{FILE *}
descriptors.

@item
Possibly related to a new library, @code{g77} should produce the equivalent
of a @code{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 @samp{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, @code{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 @code{g77}, and Fortran in
general, in the long run.
Some of these items really pertain to improving @code{g77} internals
so that some popular extensions can be more easily supported.

@itemize @bullet
@item
Consider adding a @samp{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 @samp{PARAMETER} statement
when people
really need typelessness in a maintainable, portable, clearly documented
way.
Maybe @samp{TYPELESS} would include @samp{CHARACTER}, @samp{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(...,KEY=(...),...)}.

@item
@samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
@samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
later @samp{UNIT=} in the first example is invalid.
Make sure this is what users of this feature would expect.

@item
Currently @code{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 @samp{STRUCTURE}, @samp{UNION}, @samp{MAP}, and @samp{RECORD}
fully.
Currently there is no support at all
for @samp{%FILL} in @samp{STRUCTURE} and related syntax,
whereas the rest of the
stuff has at least some parsing support.
This requires either major
changes to @code{libf2c} or its replacement.

@item
F90 and @code{g77} probably disagree about label scoping relative to
@samp{INTERFACE} and @samp{END INTERFACE}, and their contained
procedure interface bodies (blocks?).

@item
@samp{ENTRY} doesn't support F90 @samp{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
@samp{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 @samp{CLOSE}) to assist in making applications port to systems
(some IBM?) that @samp{OPEN} to the end of a file or some such thing.
@end itemize

@node Machine Model
@section Machine Model

This items pertain to generalizing @code{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 @samp{REAL_VALUE_TYPE} to represent floating-point constants
exclusively so the target float format need not be required.
This
means changing the way @code{g77} handles initialization of aggregate areas
having more than one type, such as @samp{REAL} and @samp{INTEGER},
because currently
it initializes them as if they were arrays of @samp{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 @code{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 @code{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 @code{g77} works and how to port it is needed.

@node Internals Improvements
@section Internals Improvements

Some more items that would make @code{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 @samp{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 @samp{-D} to establish requirements
to achieve desired implementation dialect via @file{proj.h}.

@item
Clean up used tokens and @samp{ffewhere}s in @samp{ffeglobal_terminate_1}.

@item
Replace @file{sta.c} @samp{outpooldisp} mechanism with @samp{malloc_pool_use}.

@item
Check for @samp{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 making 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 @code{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 @samp{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...uh...in the code.

@item
Some @samp{ffebld_new} calls (those outside of @file{ffeexpr.c} or
inside but invoked via paths not involving @samp{ffeexpr_lhs} or
@samp{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 @samp{ffebld_list_new} (or whatever) calls might not be matched by
@samp{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 @samp{EQUIVALENCE} something
due to alignment/mismatch or other problems---they end up without
@samp{ffestorag} objects, so maybe the backend (and other parts of the front
end) can notice that and handle like an @samp{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
Implement non-F90 messages (especially avoid mentioning F90 things @code{g77}
doesn't yet support).
Much of this has been done as of 0.5.14.

@item
When @samp{FUNCTION} and @samp{ENTRY} point types disagree (@samp{CHARACTER}
lengths, type classes, and so on),
@samp{ANY}-ize the offending @samp{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:

@example
INTEGER X(20)
CONTINUE
DATA (X(I), J= 1, 20) /20*5/
END
@end example

(The @samp{CONTINUE} statement ensures the @samp{DATA} statement
is processed in the context of executable, not specification,
statements.)
@end itemize
@end ifset

@node Index
@unnumbered Index

@printindex cp
@summarycontents
@contents
@bye