ARM Club 3/TheARMClub_PDCD3.iso/hensa/programming/g77_2/!gcc/docs/fortran/g77

GNU Info File | 1996-11-11 | 382.2 KB | 8,663 lines

This is Info file ^.!gcc.docs.fortran.g77, produced by Makeinfo-1.63
from the input file texi.g77.

   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.

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

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

   Contributed by James Craig Burley (`[e-mail]').
Inspired by a first pass at translating `g77-0.5.16/f/DOC' that was
contributed to Craig by David Ronis (`[e-mail]').


File: ^.!gcc.docs.fortran.g77,  Node: Top,  Next: Copying,  Up: (DIR)

Introduction
************

   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.

* 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".

* Getting Started:: Finding your way around this manual.
* What is GNU Fortran?::  How `g77' fits into the universe.
* G77 and GCC::     You can compile Fortran, C, or other programs.
* Invoking G77::    Command options supported by `g77'.
* News::            News about recent releases of `g77'.
* Changes::         User-visible changes to recent releases of `g77'.
* Language::        The GNU Fortran language.
* Installation::    How to configure, compile and install GNU Fortran.
* Debugging and Interfacing::  How `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.

* Index::        Index of concepts and symbol names.


File: ^.!gcc.docs.fortran.g77,  Node: Copying,  Next: Contributors,  Prev: Top,  Up: Top

GNU GENERAL PUBLIC LICENSE
**************************

                         Version 2, June 1991

     Copyright (C) 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.

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.

    TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

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

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

  2. 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:

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

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

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

     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.

  3. 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:

       a. 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,

       b. 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,

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

     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.

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

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

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

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

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

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

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

                                NO WARRANTY

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

 12. 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 OF TERMS AND CONDITIONS

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.

     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
     Copyright (C) 19YY  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.

   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:

     Gnomovision version 69, Copyright (C) 19YY 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.

   The hypothetical commands `show w' and `show c' should show the
appropriate parts of the General Public License.  Of course, the
commands you use may be called something other than `show w' and `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:

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

     SIGNATURE OF TY COON, 1 April 1989
     Ty Coon, President of Vice

   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.


File: ^.!gcc.docs.fortran.g77,  Node: Contributors,  Next: Funding,  Prev: Copying,  Up: Top

Contributors to GNU Fortran
***************************

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

   * The packaging and compiler portions of GNU Fortran are based
     largely on the GNU CC compiler.  *Note Contributors to GNU CC:
     (gcc)Contributors, for more information.

   * The run-time library used by GNU Fortran is a minor repackaging of
     the `libf2c' library (combined from the `libF77' and `libI77'
     libraries) provided as part of `f2c', available for free from
     `netlib' sites on the Internet.

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

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

          Jonathan Corbet

          Dr. Mark Fernyhough

          Takafumi Hayashi (The University of
          AIzu)--`[e-mail]'

          Kate Hedstrom

          Michel Kern (INRIA and Rice
          University)--`[e-mail]'

          Dr. A. O. V. Le Blanc

          Dave Love

          Rick Lutowski

          Toon Moene

          Rick Niles

          Derk Reefman

          Wayne K. Schroll

          Bill Thorson

          Pedro A. M. Vazquez

          Ian Watson

   * Scott Snyder (`[e-mail]') provided the patch to add
     rudimentary support for `INTEGER*1', `INTEGER*2', and `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.

   * David Ronis (`[e-mail]') inspired and
     encouraged Craig to rewrite the documentation in texinfo format by
     contributing a first pass at a translation of the old
     `g77-0.5.16/f/DOC' file.

   * Toon Moene (`[e-mail]') performed some analysis
     of generated code as part of an overall project to improve `g77'
     code generation to at least be as good as `f2c' used in
     conjunction with `gcc'.  So far, this has resulted in the three,
     somewhat experimental, options added by `g77' to the `gcc'
     compiler and its back end.

   * Many other individuals have helped debug, test, and improve `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.


File: ^.!gcc.docs.fortran.g77,  Node: Funding,  Next: Funding GNU Fortran,  Prev: Contributors,  Up: Top

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.

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


File: ^.!gcc.docs.fortran.g77,  Node: Funding GNU Fortran,  Next: Look and Feel,  Prev: Funding,  Up: Top

Funding GNU Fortran
*******************

   Work on GNU Fortran is still being done mostly by its author, James
Craig Burley (`[e-mail]'), 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.

   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 `[e-mail]' 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--*Note 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
`g77-0.6') that require longer timeframes to complete.  For the latest
information on the status of the author, do `finger -l
[e-mail]', i.e. access `burley''s `.plan' file just as you
would `fortran''s to get `g77' status (except there's no public `ftp'
access to `burley''s `.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 `[e-mail]' to volunteer for this work.

   *Note Funding Free Software: Funding, for more information.


File: ^.!gcc.docs.fortran.g77,  Node: Look and Feel,  Next: Getting Started,  Prev: Funding GNU Fortran,  Up: Top

Protect Your Freedom--Fight "Look And Feel"
*******************************************

   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.

   *Note Protect Your Freedom--Fight "Look And Feel": (gcc)Look and
Feel, for more information.


File: ^.!gcc.docs.fortran.g77,  Node: Getting Started,  Next: What is GNU Fortran?,  Prev: Look and Feel,  Up: Top

Getting Started
***************

   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 *Note 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 `gcc', you should see *Note G77 and
GCC::.

   Everyone except experienced `g77' users should see *Note Invoking
G77::.

   If you're acquainted with previous versions of `g77', you should see
*Note News::.  Further, if you've actually used previous versions of
`g77', especially if you've written or modified Fortran code to be
compiled by previous versions of `g77', you should see *Note 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 *Note Language::.

   If you don't already have `g77' installed on your system, you must
see *Note Installation::.

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

   If you need further help with `g77', or with freely redistributable
software in general, see *Note Service::.

   If you would like to help the `g77' project, see *Note Funding GNU
Fortran::, for information on helping financially, and see *Note
Projects::, for information on helping in other ways.

   If you're generally curious about the future of `g77', see *Note
Projects::.  If you're curious about its past, see *Note Contributors::,
and see *Note Funding GNU Fortran::.

   To see a few of the questions maintainers of `g77' have, and that
you might be able to answer, see *Note Open Questions::.


File: ^.!gcc.docs.fortran.g77,  Node: What is GNU Fortran?,  Next: G77 and GCC,  Prev: Getting Started,  Up: Top

What is GNU Fortran?
********************

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

   `g77' also is designed to fit in well with the other fine GNU
compilers and tools.

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

   As compilers, `g77', `gcc', and `f77' share the following
characteristics:

   * 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 "source code".

   * 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 "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.

   * 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 "debugger", such as `gdb').

   * 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 "libraries" and is located and
     gathered during the "link" phase of the compilation process.
     (Linking often is thought of as a separate step, because it can be
     directly invoked via the `ld' command.  However, the `g77' and
     `gcc' commands, as with most compiler commands, automatically
     perform the linking step by calling on `ld' directly, unless asked
     to not do so by the user.)

   * They attempt to diagnose cases where the user's program contains
     incorrect usages of the language.  The "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.  (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.)

   * 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 "warnings", instead of the "errors" that indicate incorrect
     usage of the language.

   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.

   `g77' consists of several components:

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

   * The `g77' command itself, which also might be installed as the
     system's `f77' command.

   * The `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
     `g77' compilation phase.

   * The compiler itself, internally named `f771'.

     Note that `f771' does not generate machine code directly--it
     generates "assembly code" that is a more readable form of machine
     code, leaving the conversion to actual machine code to an
     "assembler", usually named `as'.

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

   For example, the command `gcc foo.c' "drives" the file `foo.c'
through the preprocessor `cpp', then the C compiler (internally named
`cc1'), then the assembler (usually `as'), then the linker (`ld'),
producing an executable program named `a.out' (on UNIX systems).

   As another example, the command `gcc foo.cc' would do much the same
as `gcc foo.c', but instead of using the C compiler named `cc1', `gcc'
would use the C++ compiler (named `cc1plus').

   In a GNU Fortran installation, `gcc' recognizes Fortran source files
by name just like it does C and C++ source files.  It knows to use the
Fortran compiler named `f771', instead of `cc1' or `cc1plus', to
compile Fortran files.

   Non-Fortran-related operation of `gcc' is generally unaffected by
installing the GNU Fortran version of `gcc'.  However, without the
installed version of `gcc' being the GNU Fortran version, `gcc' will
not be able to compile and link Fortran programs--and since `g77' uses
`gcc' to do most of the actual work, neither will `g77'!

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

   The command `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
`gcc -v' currently does.  (It also produces an error message near the
end of the output, a diagnostic from the linker, usually `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
`GNU Fortran Front End' identifies the version number of GNU Fortran;
immediately preceding that line is a line identifying the version of
`gcc' with which that version of `g77' was built.

   The `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.

   For example, while code generated by `g77' is likely to do
additions, subtractions, and multiplications "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
`f771' compiler (invoked by `g77' when compiling Fortran code) into
machine code that, when run, calls on functions in `libf2c', so
`libf2c' must be linked with almost every useful program having any
component compiled by GNU Fortran.  (As mentioned above, the `g77'
command takes care of all this for you.)

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

   One chunk is the so-called "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 `cc1', `cc1plus',
and `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.

   The other chunk of `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 "Fortran Front End" (FFE).  The `cc1' and `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 `-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).


File: ^.!gcc.docs.fortran.g77,  Node: G77 and GCC,  Next: Invoking G77,  Prev: What is GNU Fortran?,  Up: Top

Compile Fortran, C, or Other Programs
*************************************

   A GNU Fortran installation includes a modified version of the `gcc'
command.

   In a non-Fortran installation, `gcc' recognizes C, C++, and
Objective-C source files.

   In a GNU Fortran installation, `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.

   *Note Compile C; C++; or Objective-C: (gcc)G++ and GCC, for
information on the way different languages are handled by the GNU CC
compiler (`gcc').

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

   Use the `-v' option with `g77' to see what is going on--the first
line of output is the invocation of the `gcc' command.  Use
`--driver=true' to disable actual invocation of `gcc' (this works
because `true' is the name of a UNIX command that simply returns
success status).


File: ^.!gcc.docs.fortran.g77,  Node: Invoking G77,  Next: News,  Prev: G77 and GCC,  Up: Top

GNU Fortran Command Options
***************************

   The `g77' command supports all the options supported by the `gcc'
command.  *Note GNU CC Command Options: (gcc)Invoking GCC, for
information on the non-Fortran-specific aspects of the `gcc' command
(and, therefore, the `g77' command).

   The `g77' command supports one option not supported by the `gcc'
command:

`--driver=COMMAND'
     Specifies that COMMAND, rather than `gcc', is to be invoked by
     `g77' to do its job.  For example, within the gcc build directory
     after building GNU Fortran (but without having to install it),
     `./g77 --driver=./xgcc foo.f -B./'.

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

* Menu:

* Option Summary::    Brief list of all `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.


File: ^.!gcc.docs.fortran.g77,  Node: Option Summary,  Next: Overall Options,  Up: Invoking G77

Option Summary
==============

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

*Overall Options*
     *Note Options Controlling the Kind of Output: Overall Options.
          --driver  -fversion  -fset-g77-defaults

*Fortran Language Options*
     *Note Options Controlling Fortran Dialect: Fortran Dialect Options.
          -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-N  -ffixed-line-length-none

*Warning Options*
     *Note Options to Request or Suppress Warnings: Warning Options.
          -fsyntax-only  -pedantic  -pedantic-errors  -fpedantic
          -fugly  -fno-ugly-args  -fno-ugly-init  -w  -Wimplicit
          -Wunused  -Wuninitialized  -Wall  -Wsurprising  -Werror
          -W

*Debugging Options*
     *Note Options for Debugging Your Program or GCC: Debugging Options.
          -g

*Optimization Options*
     *Note Options that Control Optimization: Optimize Options.
          -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

*Directory Options*
     *Note Options for Directory Search: Directory Options.
          -IDIR  -I-

*Code Generation Options*
     *Note Options for Code Generation Conventions: Code Gen Options.
          -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

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


File: ^.!gcc.docs.fortran.g77,  Node: Overall Options,  Next: Fortran Dialect Options,  Prev: Option Summary,  Up: Invoking G77

Options Controlling the Kind of Output
======================================

   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.

   For any given input file, the file name suffix determines what kind
of compilation is done.  Suffixes specific to GNU Fortran are listed
below.  *Note gcc: (Using and Porting GNU CC)Overall Options, for
information on suffixes recognized by GNU CC.

`FILE.f'
`FILE.for'
     Fortran source code that should not be preprocessed.

`FILE.F'
`FILE.fpp'
     Fortran source code that must be preprocessed (by the C
     preprocessor `cpp', which is part of GNU CC).

   UNIX users typically use the `FILE.f' and `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.for' and `FILE.fpp' nomenclature.

   Use of the preprocessor `cpp' allows use of C-like constructs such
as `#define' and `#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 `#include' and, in conjunction
with `#define', only `#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 `g77' and `gcc' commands in a GNU Fortran installation:

`--driver=COMMAND'
     This works only when invoking the `g77' command, not when invoking
     the `gcc' command.  *Note GNU Fortran Command Options: Invoking
     G77, for information on this option.

`-fversion'
     Ensure that the `g77'-specific version of the compiler phase is
     reported, if run.  (This is supplied automatically when `-v' or
     `--version' is specified as a command-line option for `g77' or
     `gcc' and when the resulting commands compile Fortran source
     files.)

`-fset-g77-defaults'
     Set up whatever `gcc' options are to apply to Fortran compilations.
     For version 0.5.18, this is equivalent to `-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,
     `g77 -v' understand why it is there.  Also, developers who run
     `f771' directly might want to specify it by hand to get the same
     defaults as they would running `f771' via `g77' or `gcc'.)

   *Note Options Controlling the Kind of Output: (gcc)Overall Options,
for information on more options that control the overall operation of
the `gcc' command (and, by extension, the `g77' command).


File: ^.!gcc.docs.fortran.g77,  Node: Fortran Dialect Options,  Next: Warning Options,  Prev: Overall Options,  Up: Invoking G77

Options Controlling Fortran Dialect
===================================

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

`-ffree-form'
`-fno-fixed-form'
     Specify that the source file is written in free form (introduced
     in Fortran 90) instead of the more-traditional fixed form.

`-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 `-fvxt-not-f90',
     `-ff90-intrinsics-enable', and the current level of support for
     Fortran 90.)

     *Note GNU Fortran Extensions: Extensions, for more information.

`-fvxt-not-f90'
`-ff90-not-vxt'
     Specify whether Fortran 90 or other popular extensions are to be
     assumed for ambiguous constructs.  The default is -fvxt-not-f90.

     For example, with `-ff90-not-vxt', `PRINT *,"double-quoted
     string"' is valid, while with `-fvxt-not-f90', `PRINT *,"2000' is
     valid.

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

     *Note GNU Fortran Dialects: Dialects, for more information.

`-fdollar-ok'
     Allow `$' as a valid character in a symbol name.

`-fno-backslash'
     Specify that `\' is not to be specially interpreted in character
     and Hollerith constants a la C and many UNIX Fortran compilers.

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

     Note that `g77' implements a fairly general form of backslash
     processing that is incompatible with the narrower forms supported
     by some other compilers.  For example, `'A\003B'' is a
     three-character string in `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.

     *Note Certain Changes We Don't Want to Make: Non-bugs, for
     information on why `-fbackslash' is the default instead of
     `-fno-backslash'.

`-fintrin-case-initcap'
`-fintrin-case-upper'
`-fintrin-case-lower'
`-fintrin-case-any'
     Specify expected case for intrinsic names.  `-fintrin-case-lower'
     is the default.

`-fmatch-case-initcap'
`-fmatch-case-upper'
`-fmatch-case-lower'
`-fmatch-case-any'
     Specify expected case for keywords.  `-fmatch-case-lower' is the
     default.

`-fsource-case-upper'
`-fsource-case-lower'
`-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.  `-fsource-case-lower' is the default.

`-fsymbol-case-initcap'
`-fsymbol-case-upper'
`-fsymbol-case-lower'
`-fsymbol-case-any'
     Specify valid cases for user-defined symbol names.
     `-fsymbol-case-any' is the default.

`-fcase-strict-upper'
     Same as `-fintrin-case-upper -fmatch-case-upper
     -fsource-case-preserve -fsymbol-case-upper'.  (Requires all
     pertinent source to be in uppercase.)

`-fcase-strict-lower'
     Same as `-fintrin-case-lower -fmatch-case-lower
     -fsource-case-preserve -fsymbol-case-lower'.  (Requires all
     pertinent source to be in lowercase.)

`-fcase-initcap'
     Same as `-fintrin-case-initcap -fmatch-case-initcap
     -fsource-case-preserve -fsymbol-case-initcap'.  (Requires all
     pertinent source to be in initial capitals, as in `Print
     *,SqRt(Value)'.)

`-fcase-upper'
     Same as `-fintrin-case-any -fmatch-case-any -fsource-case-upper
     -fsymbol-case-any'.  (Maps all pertinent source to uppercase.)

`-fcase-lower'
     Same as `-fintrin-case-any -fmatch-case-any -fsource-case-lower
     -fsymbol-case-any'.  (Maps all pertinent source to lowercase.)

`-fcase-preserve'
     Same as `-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, `call Foo(i,I)' would pass two *different* variables
     named `i' and `I' to a procedure named `Foo'.)

`-fdcp-intrinsics-delete'
`-fdcp-intrinsics-hide'
`-fdcp-intrinsics-disable'
`-fdcp-intrinsics-enable'
     Specify status of Digital's COMPLEX-related intrinsics.
     `-fdcp-intrinsics-enable' is the default.

`-ff2c-intrinsics-delete'
`-ff2c-intrinsics-hide'
`-ff2c-intrinsics-disable'
`-ff2c-intrinsics-enable'
     Specify status of f2c-specific intrinsics.
     `-ff2c-intrinsics-enable' is the default.

`-ff90-intrinsics-delete'
`-ff90-intrinsics-hide'
`-ff90-intrinsics-disable'
`-ff90-intrinsics-enable'
     Specify status of F90-specific intrinsics.
     `-ff90-intrinsics-delete' is the default.

`-fmil-intrinsics-delete'
`-fmil-intrinsics-hide'
`-fmil-intrinsics-disable'
`-fmil-intrinsics-enable'
     Specify status of MIL-STD-1753-specific intrinsics.
     `-fmil-intrinsics-enable' is the default.

`-funix-intrinsics-delete'
`-funix-intrinsics-hide'
`-funix-intrinsics-disable'
`-funix-intrinsics-enable'
     Specify status of UNIX intrinsics.  `-funix-intrinsics-enable' is
     the default.

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

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

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

     `EXIT()' accepts an optional single `INTEGER' argument.  If
     omitted, zero is the default (as in `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 `EXIT' with no arguments in your code, and let
     `g77' choose the appropriate default.

`-fvxt-intrinsics-delete'
`-fvxt-intrinsics-hide'
`-fvxt-intrinsics-disable'
`-fvxt-intrinsics-enable'
     Specify status of VXT intrinsics.  `-fvxt-intrinsics-delete' is
     the default.

`-ffixed-line-length-N'
     Set column after which characters are ignored in typical fixed-form
     lines in the source file.

     Popular values for N include 72 (the standard and the default), 80
     (card image), and 132 (corresponds to "extended-source" options in
     some popular compilers).  N may be `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.
     `-ffixed-line-length-0' means the same thing as
     `-ffixed-line-length-none'.


File: ^.!gcc.docs.fortran.g77,  Node: Warning Options,  Next: Debugging Options,  Prev: Fortran Dialect Options,  Up: Invoking G77

Options to Request or Suppress 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 `-W',
for example `-Wimplicit' to request warnings on implicit declarations.
Each of these specific warning options also has a negative form
beginning `-Wno-' to turn off warnings; for example, `-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:

`-fsyntax-only'
     Check the code for syntax errors, but don't do anything beyond
     that.

`-pedantic'
     Issue warnings for uses of extensions to ANSI FORTRAN 77.
     `-pedantic' also applies to C-language constructs where they occur
     in GNU Fortran source files, such as use of `\e' in a character
     constant within a directive like `#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 `-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 `g77' in this area are welcome.

`-pedantic-errors'
     Like `-pedantic', except that errors are produced rather than
     warnings.

`-fpedantic'
     Like `-pedantic', but applies only to Fortran constructs.

`-fugly'
     Specify that certain "ugly" constructs are to be quietly accepted.
     Implies `-fugly-args' and `-fugly-init' as well.

     For example, with `-fno-ugly', `CALL FOO(,)' means to pass one
     null argument, whereas with `-fugly', it means to pass two null
     arguments.

`-fno-ugly-args'
     Disallow passing Hollerith and typeless constants as actual
     arguments (for example, `CALL FOO(4HABCD)').

`-fno-ugly-init'
     Disallow use of Hollerith and typeless constants as initial values
     (in `PARAMETER' and `DATA' statements), and use of character
     constants to initialize numeric types and vice versa.

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

`-w'
     Inhibit all warning messages.

`-Wimplicit'
     Warn whenever a variable, array, or function is implicitly
     declared.  Has an effect similar to using the `IMPLICIT NONE'
     statement in every program unit.  (Some Fortran compilers provide
     this feature by an option named `-u' or `/WARNINGS=DECLARATIONS'.)

`-Wunused'
     Warn whenever a variable is unused aside from its declaration.

`-Wuninitialized'
     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 `-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 `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:

          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

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

          SUBROUTINE MAYBE(FLAG)
          LOGICAL FLAG
          IF (FLAG) VALUE = 3.14
          ...
          IF (FLAG) PRINT *, VALUE
          END

     This has no bug because `VALUE' is used only if it is set.

`-Wall'
     The `-Wunused' and `-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 `g77', some might be added to the list enabled by `-Wall'.)

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

`-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:

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

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

          (The `-fpedantic' option also warns about expressions having
          two arithmetic operators in a row.)

        * Expressions with a unary minus followed by an operand and then
          a binary operator other than plus or minus.  For example,
          `-2**2' produces a warning, because the precedence is
          `-(2**2)', yielding -4, not `(-2)**2', which yields 4, and
          which might represent what a programmer expects.  Even cases
          such as `-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.

        * `DO' loops with `DO' variables that are not of integral
          type--that is, using `REAL' or `DOUBLE PRECISION' variables
          as loop control variables.  Although such loops can be
          written to work in the "obvious" way, the way `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 `DO' loops, but the differences
          are pronounced for non-integral loop control variables.)

          *Note Loops::, for more information.

`-Werror'
     Make all warnings into errors.

`-W'
     Turns on "extra warnings" and the `uninitialized' option.  (This
     might change in future versions of `g77'.)

     "Extra warnings" are issued for:

        * Unused parameters to a procedure (when `-Wunused' also is
          specified).

        * Overflows involving floating-point constants (not available
          for certain configurations?).

   *Note Options to Request or Suppress Warnings: (gcc)Warning Options,
for information on more options offered by the GBE shared by `g77',
`gcc', and other GNU compilers.

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

`-Wcomment'
`-Wformat'
`-Wparentheses'
`-Wswitch'
`-Wtraditional'
`-Wshadow'
`-Wid-clash-LEN'
`-Wlarger-than-LEN'
`-Wconversion'
`-Waggregate-return'
`-Wredundant-decls'
     These options all could have some relevant meaning for GNU Fortran
     programs, but are not yet supported.


File: ^.!gcc.docs.fortran.g77,  Node: Debugging Options,  Next: Optimize Options,  Prev: Warning Options,  Up: Invoking G77

Options for Debugging Your Program or GNU Fortran
=================================================

   GNU Fortran has various special options that are used for debugging
either your program or `g77'.

`-g'
     Produce debugging information in the operating system's native
     format (stabs, COFF, XCOFF, or DWARF).  GDB can work with this
     debugging information.

     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 `EQUIVALENCE' are unavailable to the
     debugger.

   *Note Options for Debugging Your Program or GNU CC: (gcc)Debugging
Options, for more information on debugging options.


File: ^.!gcc.docs.fortran.g77,  Node: Optimize Options,  Next: Preprocessor Options,  Prev: Debugging Options,  Up: Invoking G77

Options That Control Optimization
=================================

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

   The following flags have particular applicability when compiling
Fortran programs:

`-ffloat-store'
     Might help a Fortran program that depends on exact IEEE conformance
     on some machines, but might slow down a program that doesn't.

`-fforce-mem'
`-fforce-addr'
     Might improve optimization of loops.

`-fno-inline'
     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.

`-ffast-math'
     Might allow some programs designed to not be too dependent on IEEE
     behavior for floating-point to run faster, or die trying.

`-fstrength-reduce'
     Might make some loops run faster.

`-frerun-cse-after-loop'
`-fexpensive-optimizations'
`-fdelayed-branch'
`-fschedule-insns'
`-fschedule-insns2'
`-fcaller-saves'
     Might improve performance on some code.

`-funroll-loops'
     Definitely improves performance on some code.

`-funroll-all-loops'
     Definitely improves performance on some code.

`-fno-move-all-movables'
`-fno-reduce-all-givs'
`-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 (`[e-mail]').

     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
     *disabled*, and in non-Fortran code that benefits when they are
     *enabled* via the above `gcc' command-line options.

   *Note Options That Control Optimization: (gcc)Optimize Options, for
more information on options to optimize the generated machine code.


File: ^.!gcc.docs.fortran.g77,  Node: Preprocessor Options,  Next: Directory Options,  Prev: Optimize Options,  Up: Invoking G77

Options Controlling the Preprocessor
====================================

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

   *Note Options Controlling the Preprocessor: (gcc)Preprocessor
Options, for information on C preprocessor options.

   Some of these options also affect how `g77' processes the `INCLUDE'
statement.  Since this statement is processed even when preprocessing
is not requested, it is not described in this section.  *Note Options
for Directory Search: Directory Options, for information on how `g77'
processes the `INCLUDE' statement.


File: ^.!gcc.docs.fortran.g77,  Node: Directory Options,  Next: Code Gen Options,  Prev: Preprocessor Options,  Up: Invoking G77

Options for Directory Search
============================

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

   Some of these options also affect how `g77' searches for files
specified via the `INCLUDE' statement.  These options are:

`-I-'
`-IDIR'
     These affect interpretation of the `INCLUDE' statement (as well as
     of the `#include' directive of the `cpp' preprocessor).

     Note that `-IDIR' must be specified *without* any spaces between
     `-I' and the directory name--that is, `-Ifoo/bar' is valid, but
     `-I foo/bar' is rejected by the `g77' compiler (though the
     preprocessor supports the latter form).  Also note that the
     general behavior of `-I' and `INCLUDE' is pretty much the same as
     of `-I' with `#include' in the `cpp' preprocessor, with regard to
     looking for `header.gcc' files and other such things.

     *Note Options for Directory Search: (gcc)Directory Optoins, for
     information on the `-I' option.


File: ^.!gcc.docs.fortran.g77,  Node: Code Gen Options,  Next: Environment Variables,  Prev: Directory Options,  Up: Invoking G77

Options for Code Generation Conventions
=======================================

   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 `-ffoo' would be `-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 `no-' or adding it.

`-fno-automatic'
     Treat each program unit as if the `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 `-static'.)

`-finit-local-zero'
     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 `SAVE' attribute, it might be a good idea
     to also use `-fno-automatic' with `-finit-local-zero'.

`-fno-f2c'
     Do not generate code designed to be compatible with code generated
     by `f2c'.

     This does not affect the generation of code that interfaces with
     the `libf2c' library.

     *Caution:* If `-fno-f2c' is used when compiling any source file
     used in a program, it must be used when compiling *all* Fortran
     source files used in that program.

`-ff2c-library'
     Specify that use of `libf2c' is required.  This is the default for
     the current version of `g77'.

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

`-fno-underscoring'
     Do not transform names of entities specified in the Fortran source
     file by appending underscores to them.

     With `-funderscoring' in effect, `g77' appends two underscores to
     names with underscores and one underscore to external names with
     no underscores.  (`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 `f2c', which perform the same
     transformations.

     Use of `-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 `-funderscoring', and assuming other defaults
     like `-fcase-lower' and that `j()' and `max_count()' are external
     functions while `my_var' and `lvar' are local variables, a
     statement like

          I = J() + MAX_COUNT (MY_VAR, LVAR)

     is implemented as something akin to:

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

     With `-fno-underscoring', the same statement is implemented as:

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

     Use of `-fno-underscoring' allows direct specification of
     user-defined names while debugging and when interfacing
     `g77'-compiled code with other languages.

     Note that just because the names match does *not* mean that the
     interface implemented by `g77' for an external name matches the
     interface implemented by some other language for that same name.
     That is, getting code produced by `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 `-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 `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.

`-fno-second-underscore'
     Do not append a second underscore to names of entities specified
     in the Fortran source file.

     This option has no effect if `-fno-underscoring' is not in effect.

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

`-fno-ident'
     Ignore the `#ident' directive.

`-fzeros'
     Treat initial values of zero as if they were any other value.

     As of version 0.5.18, `g77' normally treats `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 `-fzeros' to revert to the simpler, slower behavior that can
     catch multiple initializations by keeping track of all
     initializations, zero or otherwise.

     *Caution:* Future versions of `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.

   *Note Options for Code Generation Conventions: (gcc)Code Gen
Options, for information on more options offered by the GBE shared by
`g77', `gcc', and other GNU compilers.

   Some of these do *not* work when compiling programs written in
Fortran:

`-fpcc-struct-return'
`-freg-struct-return'
     You should not use these except strictly the same way as you used
     them to build the version of `libf2c' with which you will be
     linking all code compiled by `g77' with the same option.

`-fshort-double'
     This probably either has no effect on Fortran programs, or makes
     them act loopy.

`-fno-common'
     Do not use this when compiling Fortran programs, or there will be
     Trouble.

`-fpack-struct'
     This probably will break any calls to the `libf2c' library, at the
     very least, even if it is built with the same option.


File: ^.!gcc.docs.fortran.g77,  Node: Environment Variables,  Prev: Code Gen Options,  Up: Invoking G77

Environment Variables Affecting GNU Fortran
===========================================

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

   *Note Environment Variables Affecting GNU CC: (gcc)Environment
Variables, for information on environment variables.


File: ^.!gcc.docs.fortran.g77,  Node: News,  Next: Changes,  Prev: Invoking G77,  Up: Top

News About GNU Fortran
**********************

In 0.5.18:
==========

   * Add some rudimentary support for `INTEGER*1', `INTEGER*2',
     `INTEGER*8', and their `LOGICAL' equivalents.  (This support works
     on most, maybe all, `gcc' targets.)

     Thanks to Scott Snyder (`[e-mail]') for providing
     the patch for this!

     Among the missing elements from the support for these features are
     full intrinsic support and constants.

   * Add some rudimentary support for the `BYTE' and `WORD'
     type-declaration statements.  `BYTE' corresponds to `INTEGER*1',
     while `WORD' corresponds to `INTEGER*2'.

     Thanks to Scott Snyder (`[e-mail]') for providing
     the patch for this!

   * The compiler code handling intrinsics has been largely rewritten
     to accommodate the new types.  No new intrinsics or arguments for
     existing intrinsics have been added, so there is, at this point,
     no intrinsic to convert to `INTEGER*8', for example.

   * Support automatic arrays in procedures.

   * Reduce space/time requirements for handling large *sparsely*
     initialized aggregate arrays.  This improvement applies to only a
     subset of the general problem to be addressed in 0.6.

   * Treat initial values of zero as if they weren't specified (in DATA
     and type-declaration statements).  The initial values will be set
     to zero anyway, but the amount of compile time processing them
     will be reduced, in some cases significantly (though, again, this
     is only a subset of the general problem to be addressed in 0.6).

     A new option, `-fzeros', is introduced to enable the traditional
     treatment of zeros as any other value.

   * With `-ff90' in force, `g77' incorrectly interpreted `REAL(Z)' as
     returning a `REAL' result, instead of as a `DOUBLE PRECISION'
     result.  (Here, `Z' is `DOUBLE COMPLEX'.)

     With `-fno-f90' in force, the interpretation remains unchanged,
     since this appears to be how at least some F77 code using the
     `DOUBLE COMPLEX' extension expected it to work.

     Essentially, `REAL(Z)' in F90 is the same as `DBLE(Z)', while in
     extended F77, it appears to be the same as `REAL(REAL(Z))'.

   * An expression involving exponentiation, where both operands were
     type `INTEGER' and the right-hand operand was negative, was
     erroneously evaluated.

   * Fix bugs involving `DATA' implied-`DO' constructs (these involved
     an errant diagnostic and a crash, both on good code, one involving
     subsequent statement-function definition).

   * Close `INCLUDE' files after processing them, so compiling source
     files with lots of `INCLUDE' statements does not result in being
     unable to open `INCLUDE' files after all the available file
     descriptors are used up.

   * Speed up compiling, especially of larger programs, and perhaps
     slightly reduce memory utilization while compiling (this is *not*
     the improvement planned for 0.6 involving large aggregate
     areas)--these improvements result from simply turning off some
     low-level code to do self-checking that hasn't been triggered in a
     long time.

   * Introduce three new options that implement optimizations in the
     `gcc' back end (GBE).  These options are `-fmove-all-movables',
     `-freduce-all-givs', and `-frerun-loop-opt', which are enabled, by
     default, for Fortran compilations.  These optimizations are
     intended to help toon Fortran programs.

   * Patch the GBE to do a better job optimizing certain kinds of
     references to array elements.

   * Due to patches to the GBE, the version number of `gcc' also is
     patched to make it easier to manage installations, especially
     useful if it turns out a `g77' change to the GBE has a bug.

     The `g77'-modified version number is the `gcc' version number with
     the string `.f.N' appended, where `f' identifies the version as
     enhanced for Fortran, and N is `1' for the first Fortran patch for
     that version of `gcc', `2' for the second, and so on.

     So, this introduces version `2.7.2.f.1' of `gcc'.

   * Make several improvements and fixes to diagnostics, including the
     removal of two that were inappropriate or inadequate.

   * Warning about two successive arithmetic operators, produced by
     `-Wsurprising', now produced *only* when both operators are,
     indeed, arithmetic (not relational/boolean).

   * `-Wsurprising' now warns about the remaining cases of using
     non-integral variables for implied-`DO' loops, instead of these
     being rejected unless `-fpedantic' or `-fugly' specified.

   * Allow `SAVE' of a local variable or array, even after it has been
     given an initial value via `DATA', for example.

   * Introduce an Info version of `g77' documentation, which supercedes
     `gcc/f/CREDITS', `gcc/f/DOC', and `gcc/f/PROJECTS'.  These files
     will be removed in a future release.  The files `gcc/f/BUGS',
     `gcc/f/INSTALL', and `gcc/f/NEWS' now are automatically built from
     the texinfo source when distributions are made.

     This effort was inspired by a first pass at translating
     `g77-0.5.16/f/DOC' that was contributed to Craig by David Ronis
     (`[e-mail]').

   * New `-fno-second-underscore' option to specify that, when
     `-funderscoring' is in effect, a second underscore is not to be
     appended to Fortran names already containing an underscore.

   * Change the way iterative `DO' loops work to follow the F90
     standard.  In particular, calculation of the iteration count is
     still done by converting the start, end, and increment parameters
     to the type of the `DO' variable, but the result of the
     calculation is always converted to the default `INTEGER' type.

     (This should have no effect on existing code compiled by `g77',
     but code written to assume that use of a *wider* type for the `DO'
     variable will result in an iteration count being fully calculated
     using that wider type (wider than default `INTEGER') must be
     rewritten.)

   * Upgrade to `libf2c' as of 1996-03-23, and fix up some of the build
     procedures.

     Note that the email addresses related to `f2c' have changed--the
     distribution site now is named `netlib.bell-labs.com', and the
     maintainer's new address is `[e-mail]'.

In 0.5.17:
==========

   * *Fix serious bug* in `g77 -v' command that can cause removal of a
     system's `/dev/null' special file if run by user `root'.

     *All users* of version 0.5.16 should ensure that they have not
     removed `/dev/null' or replaced it with an ordinary file (e.g. by
     comparing the output of `ls -l /dev/null' with `ls -l /dev/zero'.
     If the output isn't basically the same, contact your system
     administrator about restoring `/dev/null' to its proper status).

     This bug is particularly insidious because removing `/dev/null' as
     a special file can go undetected for quite a while, aside from
     various applications and programs exhibiting sudden, strange
     behaviors.

     I sincerely apologize for not realizing the implications of the
     fact that when `g77 -v' runs the `ld' command with `-o /dev/null'
     that `ld' tries to *remove* the executable it is supposed to build
     (especially if it reports unresolved references, which it should
     in this case)!

   * Fix crash on `CHARACTER*(*) FOO' in a main or block data program
     unit.

   * Fix crash that can occur when diagnostics given outside of any
     program unit (such as when input file contains `@foo').

   * Fix crashes, infinite loops (hangs), and such involving diagnosed
     code.

   * Fix `ASSIGN''ed variables so they can be `SAVE''d or dummy
     arguments, and issue clearer error message in cases where target
     of `ASSIGN' or `ASSIGN'ed `GOTO'/`FORMAT' is too small (which
     should never happen).

   * Make `libf2c' build procedures work on more systems again by
     eliminating unnecessary invocations of `ld -r -x' and `mv'.

   * Fix omission of `-funix-intrinsics-...' options in list of
     permitted options to compiler.

   * Fix failure to always diagnose missing type declaration for
     `IMPLICIT NONE'.

   * Fix compile-time performance problem (which could sometimes crash
     the compiler, cause a hang, or whatever, due to a bug in the back
     end) involving exponentiation with a large `INTEGER' constant for
     the right-hand operator (e.g. `I**32767').

   * Fix build procedures so cross-compiling `g77' (the `fini' utility
     in particular) is properly built using the host compiler.

   * Add new `-Wsurprising' option to warn about constructs that are
     interpreted by the Fortran standard (and `g77') in ways that are
     surprising to many programmers.

   * Add `ERF()' and `ERFC()' as generic intrinsics mapping to existing
     `ERF'/`DERF' and `ERFC'/`DERFC' specific intrinsics.

     *Note:* You should specify `INTRINSIC ERF,ERFC' in any code where
     you might use these as generic intrinsics, to improve likelihood
     of diagnostics (instead of subtle run-time bugs) when using a
     compiler that doesn't support these as intrinsics (e.g. `f2c').

   * Remove from `-fno-pedantic' the diagnostic about `DO' with
     non-`INTEGER' index variable; issue that under `-Wsurprising'
     instead.

   * Clarify some diagnostics that say things like "ignored" when that's
     misleading.

   * Clarify diagnostic on use of `.EQ.'/`.NE.' on `LOGICAL' operands.

   * Minor improvements to code generation for various operations on
     `LOGICAL' operands.

   * Minor improvement to code generation for some `DO' loops on some
     machines.

   * Support `gcc' version 2.7.1.

   * Upgrade to `libf2c' as of 1995-11-15.

In 0.5.16:
==========

   * Fix a code-generation bug involving complicated `EQUIVALENCE'
     statements not involving `COMMON'

   * Fix code-generation bugs involving invoking "gratis" library
     procedures in `libf2c' from code compiled with `-fno-f2c' by
     making these procedures known to `g77' as intrinsics (not affected
     by -fno-f2c).  This is known to fix code invoking `ERF()',
     `ERFC()', `DERF()', and `DERFC()'.

   * Update `libf2c' to include netlib patches through 1995-08-16, and
     `#define' `WANT_LEAD_0' to 1 to make `g77'-compiled code more
     consistent with other Fortran implementations by outputting
     leading zeros in formatted and list-directed output.

   * Fix a code-generation bug involving adjustable dummy arrays with
     high bounds whose primaries are changed during procedure
     execution, and which might well improve code-generation
     performance for such arrays compared to `f2c' plus `gcc' (but
     apparently only when using `gcc-2.7.0' or later).

   * Fix a code-generation bug involving invocation of `COMPLEX' and
     `DOUBLE COMPLEX' `FUNCTION's and doing `COMPLEX' and `DOUBLE
     COMPLEX' divides, when the result of the invocation or divide is
     assigned directly to a variable that overlaps one or more of the
     arguments to the invocation or divide.

   * Fix crash by not generating new optimal code for `X**I' if `I' is
     nonconstant and the expression is used to dimension a dummy array,
     since the `gcc' back end does not support the necessary mechanics
     (and the `gcc' front end rejects the equivalent construct, as it
     turns out).

   * Fix crash on expressions like `COMPLEX**INTEGER'.

   * Fix crash on expressions like `(1D0,2D0)**2', i.e. raising a
     `DOUBLE COMPLEX' constant to an `INTEGER' constant power.

   * Fix crashes and such involving diagnosed code.

   * Diagnose, instead of crashing on, statement function definitions
     having duplicate dummy argument names.

   * Fix bug causing rejection of good code involving statement function
     definitions.

   * Fix bug resulting in debugger not knowing size of local equivalence
     area when any member of area has initial value (via `DATA', for
     example).

   * Fix installation bug that prevented installation of `g77' driver.
     Provide for easy selection of whether to install copy of `g77' as
     `f77' to replace the broken code.

   * Fix `gcc' driver (affects `g77' thereby) to not gratuitously
     invoke the `f771' program (e.g. when `-E' is specified).

   * Fix diagnostic to point to correct source line when it immediately
     follows an `INCLUDE' statement.

   * Support more compiler options in `gcc'/`g77' when compiling
     Fortran files.  These options include `-p', `-pg', `-aux-info',
     `-P', correct setting of version-number macros for preprocessing,
     full recognition of `-O0', and automatic insertion of
     configuration-specific linker specs.

   * Add new intrinsics that interface to existing routines in `libf2c':
     `ABORT', `DERF', `DERFC', `ERF', `ERFC', `EXIT', `FLUSH',
     `GETARG', `GETENV', `IARGC', `SIGNAL', and `SYSTEM'.  Note that
     `ABORT', `EXIT', `FLUSH', `SIGNAL', and `SYSTEM' are intrinsic
     subroutines, not functions (since they have side effects), so to
     get the return values from `SIGNAL' and `SYSTEM', append a final
     argument specifying an `INTEGER' variable or array element (e.g.
     `CALL SYSTEM('rm foo',ISTAT)').

   * Add new intrinsic group named `unix' to contain the new intrinsics,
     and by default enable this new group.

   * Move `LOC()' intrinsic out of the `vxt' group to the new `unix'
     group.

   * Improve `g77' so that `g77 -v' by itself (or with certain other
     options, including `-B', `-b', `-i', `-nostdlib', and `-V')
     reports lots more useful version info, and so that long-form
     options `gcc' accepts are understood by `g77' as well (even in
     truncated, unambiguous forms).

   * Add new `g77' option `--driver=name' to specify driver when
     default, `gcc', isn't appropriate.

   * Add support for `#' directives (as output by the preprocessor) in
     the compiler, and enable generation of those directives by the
     preprocessor (when compiling `.F' files) so diagnostics and
     debugging info are more useful to users of the preprocessor.

   * Produce better diagnostics, more like `gcc', with info such as `In
     function `foo':' and `In file included from...:'.

   * Support `gcc''s `-fident' and `-fno-ident' options.

   * When `-Wunused' in effect, don't warn about local variables used as
     statement-function dummy arguments or `DATA' implied-`DO' iteration
     variables, even though, strictly speaking, these are not uses of
     the variables themselves.

   * When `-W -Wunused' in effect, don't warn about unused dummy
     arguments at all, since there's no way to turn this off for
     individual cases (`g77' might someday start warning about
     these)--applies to `gcc' versions 2.7.0 and later, since earlier
     versions didn't warn about unused dummy arguments.

   * New option `-fno-underscoring' that inhibits transformation of
     names (by appending one or two underscores) so users may experiment
     with implications of such an environment.

   * Minor improvement to `gcc/f/info' module to make it easier to build
     `g77' using the native (non-`gcc') compiler on certain machines
     (but definitely not all machines nor all non-`gcc' compilers).
     Please do not report bugs showing problems compilers have with
     macros defined in `gcc/f/target.h' and used in places like
     `gcc/f/expr.c'.

   * Add warning to be printed for each invocation of the compiler if
     the target machine `INTEGER', REAL, or `LOGICAL' size is not 32
     bits, since `g77' is known to not work well for such cases (to be
     fixed in Version 0.6--*note Actual Bugs We Haven't Fixed Yet:
     Actual Bugs.).

   * Lots of new documentation (though work is still needed to put it
     into canonical GNU format).

   * Build `libf2c' with `-g0', not `-g2', in effect (by default), to
     produce smaller library without lots of debugging clutter.

In 0.5.15:
==========

   * Fix bad code generation involving `X**I' and temporary, internal
     variables generated by `g77' and the back end (such as for `DO'
     loops).

   * Fix crash given `CHARACTER A;DATA A/.TRUE./'.

   * Replace crash with diagnostic given `CHARACTER A;DATA A/1.0/'.

   * Fix crash or other erratic behavior when null character constant
     (`''') is encountered.

   * Fix crash or other erratic behavior involving diagnosed code.

   * Fix code generation for external functions returning type `REAL'
     when the `-ff2c' option is in force (which it is by default) so
     that `f2c' compatibility is indeed provided.

   * Disallow `COMMON I(10)' if `I' has previously been specified with
     an array declarator.

   * New `-ffixed-line-length-N' option, where N is the maximum length
     of a typical fixed-form line, defaulting to 72 columns, such that
     characters beyond column N are ignored, or N is `none', meaning no
     characters are ignored.  does not affect lines with `&' in column
     1, which are always processed as if `-ffixed-line-length-none' was
     in effect.

   * No longer generate better code for some kinds of array references,
     as `gcc' back end is to be fixed to do this even better, and it
     turned out to slow down some code in some cases after all.

   * In `COMMON' and `EQUIVALENCE' areas with any members given initial
     values (e.g. via `DATA'), uninitialized members now always
     initialized to binary zeros (though this is not required by the
     standard, and might not be done in future versions of `g77').
     Previously, in some `COMMON'/`EQUIVALENCE' areas (essentially
     those with members of more than one type), the uninitialized
     members were initialized to spaces, to cater to `CHARACTER' types,
     but it seems no existing code expects that, while much existing
     code expects binary zeros.

In 0.5.14:
==========

   * Don't emit bad code when low bound of adjustable array is
     nonconstant and thus might vary as an expression at run time.

   * Emit correct code for calculation of number of trips in `DO' loops
     for cases where the loop should not execute at all.  (This bug
     affected cases where the difference between the begin and end
     values was less than the step count, though probably not for
     floating-point cases.)

   * Fix crash when extra parentheses surround item in `DATA'
     implied-`DO' list.

   * Fix crash over minor internal inconsistencies in handling
     diagnostics, just substitute dummy strings where necessary.

   * Fix crash on some systems when compiling call to `MVBITS()'
     intrinsic.

   * Fix crash on array assignment `TYPEDDD(...)=...', where DDD is a
     string of one or more digits.

   * Fix crash on `DCMPLX()' with a single `INTEGER' argument.

   * Fix various crashes involving code with diagnosed errors.

   * Support `-I' option for `INCLUDE' statement, plus `gcc''s
     `header.gcc' facility for handling systems like MS-DOS.

   * Allow `INCLUDE' statement to be continued across multiple lines,
     even allow it to coexist with other statements on the same line.

   * Incorporate Bellcore fixes to `libf2c' through 1995-03-15--this
     fixes a bug involving infinite loops reading EOF with empty
     list-directed I/O list.

   * Remove all the `g77'-specific auto-configuration scripts, code,
     and so on, except for temporary substitutes for bsearch() and
     strtoul(), as too many configure/build problems were reported in
     these areas.  People will have to fix their systems' problems
     themselves, or at least somewhere other than `g77', which expects
     a working ANSI C environment (and, for now, a GNU C compiler to
     compile `g77' itself).

   * Complain if initialized common redeclared as larger in subsequent
     program unit.

   * Warn if blank common initialized, since its size can vary and hence
     related warnings that might be helpful won't be seen.

   * New `-fbackslash' option, on by default, that causes `\' within
     `CHARACTER' and Hollerith constants to be interpreted a la GNU C.
     Note that this behavior is somewhat different from `f2c''s, which
     supports only a limited subset of backslash (escape) sequences.

   * Make `-fugly-args' the default.

   * New `-fugly-init' option, on by default, that allows
     typeless/Hollerith to be specified as initial values for variables
     or named constants (`PARAMETER'), and also allows
     character<->numeric conversion in those contexts--turn off via
     `-fno-ugly-init'.

   * New `-finit-local-zero' option to initialize local variables to
     binary zeros.  This does not affect whether they are `SAVE'd, i.e.
     made automatic or static.

   * New `-Wimplicit' option to warn about implicitly typed variables,
     arrays, and functions.  (Basically causes all program units to
     default to `IMPLICIT NONE'.)

   * `-Wall' now implies `-Wuninitialized' as with `gcc' (i.e. unless
     `-O' not specified, since `-Wuninitialized' requires `-O'), and
     implies `-Wunused' as well.

   * `-Wunused' no longer gives spurious messages for unused `EXTERNAL'
     names (since they are assumed to refer to block data program
     units, to make use of libraries more reliable).

   * Support `%LOC()' and `LOC()' of character arguments.

   * Support null (zero-length) character constants and expressions.

   * Support `f2c''s `IMAG()' generic intrinsic.

   * Support `ICHAR()', `IACHAR()', and `LEN()' of character
     expressions that are valid in assignments but not normally as
     actual arguments.

   * Support `f2c'-style `&' in column 1 to mean continuation line.

   * Allow `NAMELIST', `EXTERNAL', `INTRINSIC', and `VOLATILE' in
     `BLOCK DATA', even though these are not allowed by the standard.

   * Allow `RETURN' in main program unit.

   * Changes to Hollerith-constant support to obey Appendix C of the
     standard:

        - Now padded on the right with zeros, not spaces.

        - Hollerith "format specifications" in the form of arrays of
          non-character allowed.

        - Warnings issued when non-blank truncation occurs when
          converting to another type.

        - When specified as actual argument, now passed by reference to
          `INTEGER' (padded on right with spaces if constant too small,
          otherwise fully intact if constant wider the `INTEGER' type)
          instead of by value.

     *Warning:* `f2c' differs on the interpretation of `CALL FOO(1HX)',
     which it treats exactly the same as `CALL FOO('X')', but which the
     standard and `g77' treat as `CALL FOO(%REF('X   '))' (padded with
     as many blanks as necessary to widen to `INTEGER'), essentially.

   * Changes and fixes to typeless-constant support:

        - Now treated as a typeless double-length `INTEGER' value.

        - Warnings issued when overflow occurs.

        - Padded on the left with zeros when converting to a larger
          type.

        - Should be properly aligned and ordered on the target machine
          for whatever type it is turned into.

        - When specified as actual argument, now passed as reference to
          a default `INTEGER' constant.

   * `%DESCR()' of a non-`CHARACTER' expression now passes a pointer to
     the expression plus a length for the expression just as if it were
     a `CHARACTER' expression.  For example, `CALL FOO(%DESCR(D))',
     where `D' is `REAL*8', is the same as `CALL FOO(D,%VAL(8)))'.

   * Name of multi-entrypoint master function changed to incorporate
     the name of the primary entry point instead of a decimal value, so
     the name of the master function for `SUBROUTINE X' with alternate
     entry points is now `__g77_masterfun_x'.

   * Remove redundant message about zero-step-count `DO' loops.

   * Clean up diagnostic messages, shortening many of them.

   * Fix typo in `g77' man page.

   * Clarify implications of constant-handling bugs in `f/BUGS'.

   * Generate better code for `**' operator with a right-hand operand of
     type `INTEGER'.

   * Generate better code for `SQRT()' and `DSQRT()', also when
     `-ffast-math' specified, enable better code generation for `SIN()'
     and `COS()'.

   * Generate better code for some kinds of array references.

   * Speed up lexing somewhat (this makes the compilation phase
     noticably faster).


File: ^.!gcc.docs.fortran.g77,  Node: Changes,  Next: Language,  Prev: News,  Up: Top

User-visible Changes
********************

   To find out about existing bugs and ongoing plans for GNU Fortran,
on Internet do `finger -l [e-mail]' or whatever is the
equivalent on your system.  (You might need to use the address
`[e-mail]' instead, or use `gate-2', `gate-3',
`gate-4', and so on, instead of `gate-1'.)

   Alternatively, retrieve `gnu.ai.mit.edu:/g77.plan' via anonymous
ftp, or if you cannot do that, email `[e-mail]' asking
for a recent copy of the GNU Fortran `.plan' file.  (The `finger'
command shown above obtains the most recent copy of all these methods.)

In 0.5.18:
==========

   * The `BYTE' and `WORD' statements now are supported, to a limited
     extent.

   * `INTEGER*1', `INTEGER*2', `INTEGER*8', and their `LOGICAL'
     equivalents, now are supported to a limited extent.  Among the
     missing elements are complete intrinsic and constant support.

   * Support automatic arrays in procedures.  For example, `REAL A(N)',
     where `A' is not a dummy argument, specifies that `A' is an
     automatic array.  The size of `A' is calculated from the value of
     `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.

   * Add `-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.

   * Introduce three new options that apply to all compilations by
     `g77'-aware GNU compilers--`-fmove-all-movables',
     `-freduce-all-givs', and `-frerun-loop-opt'--which can improve the
     run-time performance of some programs.

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

   * New option `-fno-second-underscore'.

In 0.5.17:
==========

   * The `ERF()' and `ERFC()' intrinsics now are generic intrinsics,
     mapping to `ERF'/`DERF' and `ERFC'/`DERFC', respectively.  *Note:*
     Use `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.

   * New option `-Wsurprising'.

   * DO loops with non-`INTEGER' variables now diagnosed only when
     `-Wsurprising' specified.  Previously, this was diagnosed *unless*
     `-fpedantic' or `-fugly' was specified.

In 0.5.16:
==========

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

   * `libf2c' no longer built with debugging information intact, making
     it much smaller.

   * Automatic installation of the `g77' command now works.

   * Diagnostic messages now more informative, a la `gcc', including
     messages like `In function `foo':' and `In file included from...:'.

   * New group of intrinsics called `unix', including `ABORT', `DERF',
     `DERFC', `ERF', `ERFC', `EXIT', `FLUSH', `GETARG', `GETENV',
     `SIGNAL', and `SYSTEM'.

   * `-funix-intrinsics-{delete,hide,disable,enable}' options added.

   * `-fno-underscoring' option added.

   * `--driver' option added to the `g77' command.

   * Support for the `gcc' options `-fident' and `-fno-ident' added.

   * `g77 -v' returns much more version info, making the submission of
     better bug reports easily.

   * Many improvements to the `g77' command to better fulfill its role
     as a front-end to the `gcc' driver.  For example, `g77' now
     recognizes `--version' as a verbose way of specifying `-v'.

   * Compiling preprocessed (`*.F' and `*.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.

In 0.5.15:
==========

   * `-ffixed-line-length-N' option introduced.

In 0.5.14:
==========

   * Support for gcc's `-I' option added.

   * `-fbackslash' option added.

   * `-fugly-args' option enabled by default (allows `CALL
     FOO(4HABCD)').

   * `-fugly-init' option added.

   * `-finit-local-zero' option added.

   * Support for the `gcc' option `-Wimplicit' added.

   * `-Wall' now implies `-Wunused' and, when `-O' is specified,
     `-Wuninitialized'.

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

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

   * Format specifications of arrays of types other than `CHARACTER' are
     allowed in I/O statements, such as when they contain Hollerith
     data.

   * Typeless constants as actual arguments now are passed by reference
     to an `INTEGER' version of the constant instead of by value.

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

   * `%DESCR()' of a non-`CHARACTER' expression treats the expression
     as if it were `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 `CHARACTER' arguments.

   * The `ICHAR()', `IACHAR()', and `LEN()' intrinsics now accept
     character expressions involving concatenation of assumed-length
     dummy arguments.

   * Block data program units now may contain `NAMELIST', `EXTERNAL',
     `INTRINSIC', and `VOLATILE' statements.

   * Zero-length character expressions now supported.

   * Support for the `f2c' intrinsic `IMAG()' added.

   * `INCLUDE' statement restrictions, such as no continuation lines
     allowed, now lifted.


File: ^.!gcc.docs.fortran.g77,  Node: Language,  Next: Installation,  Prev: Changes,  Up: Top

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 `f77'
and `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 `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 `g77'.
* Distensions::      Misfeatures supported by GNU Fortran.


File: ^.!gcc.docs.fortran.g77,  Node: Standard Support,  Next: Extensions,  Up: Language

ANSI FORTRAN 77 Standard Support
================================

   GNU Fortran supports ANSI FORTRAN 77 with the following caveats:

   * No passing of an external procedure as an actual argument if the
     procedure's type is declared `CHARACTER*(*)'.  For example:

          CHARACTER*(*) CFUNC
          EXTERNAL CFUNC
          CALL FOO(CFUNC)
          END

     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.

   * No passing of a dummy procedure as an actual argument if the
     procedure's type is declared `CHARACTER*(*)'.

          SUBROUTINE BAR(CFUNC)
          CHARACTER*(*) CFUNC
          EXTERNAL CFUNC
          CALL FOO(CFUNC)
          END

     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.

   * The `DO' variable for an implied-`DO' construct in a `DATA'
     statement may not be used as the `DO' variable for an outer
     implied-`DO' construct.  For example, this fragment is disallowed
     by `g77':

          DATA ((A(I, I), I= 1, 10), I= 1, 10)/.../

     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 *very* unlikely that any production Fortran code
     tries to use this unsupported construct.

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

          DATA (A, I= 1, 1)/1./

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Extensions,  Next: Types,  Prev: Standard Support,  Up: Language

GNU Fortran Extensions
======================

   GNU Fortran supports ANSI FORTRAN 77 plus:

   * `LOC()', if `-funix-intrinsics-enable' is in force.

   * `%LOC', `%VAL', `%REF', and `%DESCR'--where `%DESCR' currently
     means the same thing as passing the argument as if it were a
     `CHARACTER' variable (with the phantom length argument appended to
     the argument list).

   * MIL-STD 1753 features (`IAND', `IOR', `MVBITS', `DO WHILE', `END
     DO', and so on).

   * `NAMELIST'.

   * Most `f2c' intrinsics (`AND', `OR', `LSHIFT', `RSHIFT', and so on).

   * `DOUBLE COMPLEX' and related intrinsics (standard and `f2c'
     varieties).

   * Various Fortran 90 features, such as `CYCLE', `EXIT', `SELECT
     CASE' (except for `CHARACTER' types).

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

   * Various `f2c' features.

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

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

   * Use of `&' in column 1 to indicate a continuation line (as
     supported by `f2c').

   * Dollar signs (`$') in identifiers (other than as the first
     character) when the `-fdollar-ok' option is specified.

   When `-ff90' is specified, the language dialect changes as follows:

   * The type of `REAL(Z)', where `Z' is type `DOUBLE COMPLEX', is
     `DOUBLE PRECISION' instead of `REAL'.

   * Zero-length `CHARACTER' entities are accepted, even when
     `-fpedantic' is specified.

   * Zero-size array dimensions (as in `INTEGER I(10,20,4:2)') are
     accepted, although these are not supported by `libf2c', so
     diagnostics are nevertheless produced for `g77'.

   * `DOUBLE COMPLEX' (explicit or implicit) is accepted, even when
     `-fpedantic' is specified.

   * Substrings of constants (as in `'hello'(3:5)') are accepted, even
     when `-fpedantic' is specified.

   * `DATA' statements are allowed to precede executable statements,
     even when `-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 `DATA' or a
     type-declaration statement.  For example, after `DATA I/1/',
     `INTEGER I' is not permitted, but `INTEGER J' is permitted.

   * Use of a semicolon (`;') as a statement separator is accepted,
     even when `-fpedantic' specified (so `CALL FOO; CALL BAR' works).

   * Underscores (`_') 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
     `g77' does not yet support that interpretation).


File: ^.!gcc.docs.fortran.g77,  Node: Types,  Next: Constants,  Prev: Extensions,  Up: Language

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 `LOGICAL', `INTEGER',
`REAL', `DOUBLE PRECISION', `COMPLEX', and `CHARACTER'.  Further, many
compilers offer so-called `*N' notation, but the interpretation of N
varies across compilers and target architectures.

   The standard requires that `LOGICAL', `INTEGER', and `REAL' occupy
the same amount of storage space, and that `COMPLEX' and `DOUBLE
PRECISION' take twice as much storage space as `REAL'.  Further, it
requires that `COMPLEX' entities be ordered such that when a `COMPLEX'
variable is storage-associated (such as via `EQUIVALENCE') with a
two-element `REAL' array named `R', `R(1)' corresponds to the real
element and `R(2)' to the imaginary element of the `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 `CHARACTER' type specified by the standard.

   `g77' follows the above requirements, warning when compiling a
program requires placement of items in memory that contradict the
requirements of the target architecture.  (For example, a program can
require placement of a `DOUBLE PRECISION' on a boundary that is not an
even multiple of its size, but still an even multiple of the size of a
`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 `gcc' and `g77'.  `g77' warns about such situations when it
encounters them.)

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

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

`REAL'
     Same as `float' type.

`DOUBLE PRECISION'
     Same as whatever floating-point type that is twice the size of a
     `float'--usually, this is a `double'.

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

`LOGICAL'
     Same `gcc' type as `INTEGER'.

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

`DOUBLE COMPLEX'
     Two `DOUBLE PRECISION' scalars.

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

`NUMERIC-TYPE(KIND=N)'
     N=1 corresponds to `REAL', `INTEGER', `LOGICAL', `COMPLEX'.  N=2
     corresponds to `DOUBLE PRECISION', `DOUBLE COMPLEX', and, for
     integral types, `char' (usually `INTEGER*1' and `LOGICAL*1').  N=3
     corresponds to `short' for integral types (usually `INTEGER*2' and
     `LOGICAL*2').  N=4 corresponds to `long long' for integral types
     (this usually means `INTEGER*8' and `LOGICAL*8').

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

   For now, `g77' does not support numeric types other than the ones
listed above.  So, on a typical 32-bit machine, only `INTEGER*4',
`REAL*4', `LOGICAL*4', `COMPLEX*8', and so on, will work.  Other types
supported by `g77' are derived from gcc types such as `char', `short',
`int', `long int', `long long int', `long double', and so on.  That is,
whatever types `gcc' already supports, `g77' probably will support in a
future version.  The rules for the `NUMERIC-TYPE*N' notation will apply
to the new types, and new values for `NUMERIC-TYPE(KIND=N)' will be
assigned in a way that encourages clarity, consistency, and portability.


File: ^.!gcc.docs.fortran.g77,  Node: Constants,  Next: Source Form,  Prev: Types,  Up: Language

Constants
=========

   `g77' strictly assigns types to all constants not documented as
"typeless" (the typeless constants include things like `Z'1'').
Context is never a determining factor for the type, and hence the
interpretation, of a typed constant.  Examples: `1' is always type
`INTEGER', `3.141592653545256234' is always type `REAL' (even if the
additional precision specified is lost, and even when used in a `DOUBLE
PRECISION' context), `1E0' is always type `REAL', and `1D0' is always
type `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.  `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 `g77'
might differ from how other compilers assign types to constants.


File: ^.!gcc.docs.fortran.g77,  Node: Source Form,  Next: Pedantic Compilation,  Prev: Constants,  Up: Language

Source Form
===========

   The `-ffree-form' (aka `-fno-fixed-form') and `-ffixed-form' (aka
`-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 `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 (`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 `g77' interprets source lines:

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

   * A source line with a 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 `f2c', which encodes tabs as `\t' (the
     ASCII 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.

     `g77' effectively translates tabs to the appropriate number of
     spaces (a la the default for the UNIX `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).

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

     `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 `-ffixed-line-length-none', for example.


File: ^.!gcc.docs.fortran.g77,  Node: Pedantic Compilation,  Next: Case Sensitivity,  Prev: Source Form,  Up: Language

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

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

   With `-ff90' in force along with `-fpedantic', some constructs are
accepted that result in diagnostics when `-fno-f90' and `-fpedantic'
are both in force.  *Note GNU Fortran Extensions: Extensions, for
information on those constructs.

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

   * Automatic arrays, as in `REAL A(N)', where `A' is not a dummy
     argument.

   * `READ (5), I' and `WRITE (10), J'--the standard disallows the
     comma in each case, while allowing it in `READ 10, I', but many
     compilers (including `f2c') allow the superfluous comma.

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

   * Automatic conversion of numeric expressions to `INTEGER' in
     contexts such as:
        - Array-reference indexes.

        - Alternate-return values.

        - Computed `GOTO'.

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

        - Dimension lists in specification statements.

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

        - Sizes of `CHARACTER' entities in specification statements.

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

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

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

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

   * Null argument passed to statement function (as in `PRINT
     *,FOO(,3)').

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

   * Differences between named-`COMMON'-block sizes between program
     units.

   * Specification statements following first `DATA' statement (normally
     `DATA I/1/' may be followed by `INTEGER J', though not `INTEGER
     I', but `-fpedantic' disables use of both cases.

   * Semicolon as statement separator (as in `CALL FOO; CALL BAR').

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

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

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

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

   * Use of semicolons on line with INCLUDE statement.


File: ^.!gcc.docs.fortran.g77,  Node: Case Sensitivity,  Next: Intrinsics,  Prev: Pedantic Compilation,  Up: Language

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

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

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

   Low-level switches are identified in this discussion thusly:

     A Source Case Conversion
          0 Preserve (see Note 1)

          1 Convert to Upper Case

          2 Convert to Lower Case

     B Built-in Keyword Matching:
          0 Match Any Case (per-character basis)

          1 Match Upper Case Only

          2 Match Lower Case Only

          3 Match InitialCaps Only (see tables for spellings)

     C Built-in Intrinsic Matching:
          0 Match Any Case (per-character basis)

          1 Match Upper Case Only

          2 Match Lower Case Only

          3 Match InitialCaps Only (see tables for spellings)

     D User-defined Symbol Possibilities (warnings only)
          0 Allow Any Case (per-character basis)

          1 Allow Upper Case Only

          2 Allow Lower Case Only

          3 Allow InitialCaps Only (see Note 2)

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

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

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

   Note 2: Rules for InitialCaps names are:
   - Must be a single uppercase letter, *or*

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

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

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

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

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

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

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

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

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

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

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

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

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

   There are a few nearly useless combinations:

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

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Intrinsics,  Next: Dialects,  Prev: Case Sensitivity,  Up: Language

Intrinsics
==========

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

Deleted
     No intrinsics are recognized as belonging to that group.

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

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

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

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

     PRINT *, FOO()
     END

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

     EXTERNAL FOO

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

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

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

   The groups are:

`dcp'
     `DOUBLE COMPLEX' intrinsics from the standards (F77, F90).

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

`f90'
     Fortran 90 intrinsics.

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Dialects,  Next: Object Compatibility,  Prev: Intrinsics,  Up: Language

GNU Fortran Dialects
====================

   The `-fvxt-not-f90' and `-ff90-not-vxt' command-line options control
how `g77' interprets certain tokens and constructs that have different
meanings in VAX FORTRAN (circa v4) and Fortran 90.  (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 `g77' someday, and is
considered a VXT extension.)

   When `-ff90-not-vxt' is specified, the following interpretations are
made (and, when `-fvxt-not-f90' is in effect, the opposite
interpretations are made):

   * Double-quote character (`"') delimits character constant just as
     does apostrophe (`''), rather than beginning an octal constant of
     `INTEGER' type.

   * An exclamation point (`!') 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).

   * `TYPE FOO' and `TYPE (FOO), BAR' statements are recognized as the
     Fortran 90 variety, not I/O statements.  (However, the F90 variety
     is *not* supported, so this really just ensures that `g77' will
     produce a diagnostic instead of trying to implement the VXT `TYPE'
     statement--which currently is not supported either.)


File: ^.!gcc.docs.fortran.g77,  Node: Object Compatibility,  Next: Distensions,  Prev: Dialects,  Up: Language

Object Compatibility
====================

   An individual Fortran source file can be compiled to an object
(`*.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 "object compatibility" across the
various object files (and libraries, or `*.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 `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, `g77' generates code that is object-compatible with code
generated by a version of `f2c' configured (with, for example, `f2c.h'
definitions) to be generally compatible with `g77' as built by `gcc'.
(Normally, `f2c' will, by default, conform to the appropriate
configuration, but it is possible that older or perhaps even newer
versions of `f2c', or versions having certain configuration changes to
`f2c' internals, will produce object files that are incompatible with
`g77'.)

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

   Much of this compatibility results from the fact that `g77' uses the
same run-time library, `libf2c', used by `f2c'.

   Other compilers might or might not generate code that is
object-compatible with `libf2c' and current `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.


File: ^.!gcc.docs.fortran.g77,  Node: Dropping f2c Compatibility,  Next: Other Compilers,  Up: Object Compatibility

Dropping f2c Compatibility
--------------------------

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

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

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

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

   It is probable that a future version of `g77' will not, by default,
generate object files compatible with `f2c' and not use `libf2c'.  If
you expect to depend on this compatibility in the long term, use the
options `-ff2c -ff2c-library' when compiling all of the applicable code.
This should either cause `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
`g77'.


File: ^.!gcc.docs.fortran.g77,  Node: Other Compilers,  Prev: Dropping f2c Compatibility,  Up: Object Compatibility

Other Compilers
---------------

   On systems with Fortran compilers other than `f2c' and `g77', code
compiled by `g77' is not expected to work well with code compiled by
the native compiler.  (This is true for `f2c'-compiled objects as well.)
Libraries compiled with the native compiler probably will have to be
recompiled with `g77' to be used with `g77'-compiled code.

   Reasons for such incompatibilities include:

   * 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 `CALL FOO' might be compiled by `g77' to
     call a procedure the linker `ld' sees given the name `_foo_',
     while the apparently corresponding statement `SUBROUTINE FOO'
     might be compiled by the native compiler to define the
     linker-visible name `_foo', or `_FOO_', and so on.

   * There might be subtle type mismatches which cause subroutine
     arguments and function return values to get corrupted.

     This is why simply getting `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.

   * 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 `-L/usr/lang/SCx.x
     -lF77 -lV77' to the link command.


File: ^.!gcc.docs.fortran.g77,  Node: Distensions,  Prev: Object Compatibility,  Up: Language

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

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

   The constructs enabled via `-fugly' include:

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

   * Use of 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
     `-fugly-args' and `-fugly-init'.

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

   * 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, `CALL FOO(,)' means "pass two null arguments" when
     `-fugly' is used, rather than "pass one null argument".

   The construct disabled via `-fno-ugly-args' is:

   * Passing of typeless and Hollerith constants as actual arguments in
     procedure invocations.

     For example, `CALL FOO(4HABCD)'.

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

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

   * In the same contexts as above, use of character constants to
     initialize numeric items and vice versa (one constant per 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).


File: ^.!gcc.docs.fortran.g77,  Node: Installation,  Next: Debugging and Interfacing,  Prev: Language,  Up: Top

Installing GNU Fortran
**********************

* Menu:

* Prerequisites::          Make sure your system is ready for `g77'.
* Problems Installing::    Known trouble areas.
* Quick Start::            The easier procedure for non-experts.
* Complete Installation::  For experts, or those who want to be: the details.
* Distributing Binaries::  If you plan on distributing your `g77'.
* Settings::               Some notes on `g77' internals.

   The following information describes how to install `g77'.

   The information in this file generally pertains to dealing with
*source* distributions of `g77' and `gcc'.  It is possible that some of
this information will be applicable to some *binary* distributions of
these products--however, since these distributions are not made by the
maintainers of `g77', responsibility for binary distributions rests with
whoever built and first distributed them.

   Nevertheless, efforts to make `g77' easier to both build and install
from source and package up as a binary distribution are ongoing.


File: ^.!gcc.docs.fortran.g77,  Node: Prerequisites,  Next: Problems Installing,  Up: Installation

Prerequisites
=============

   The procedures described to unpack, configure, build, and install
`g77' assume your system has certain programs already installed.

   The following prerequisites should be met by your system before you
follow the `g77' installation instructions:

`gzip'
     To unpack the `gcc' and `g77' distributions, you'll need the
     `gunzip' utility in the `gzip' distribution.  Most UNIX systems
     already have `gzip' installed.  If yours doesn't, you can get it
     from the FSF.

     Note that you'll need `tar' and other utilities as well, but all
     UNIX systems have these.  There are GNU versions of all these
     available--in fact, a complete GNU UNIX system can be put together
     on most systems, if desired.

`gcc-2.7.2.tar.gz'
     You need to have this, or some other applicable, version of `gcc'
     on your system.  The version should be an exact copy of a
     distribution from the FSF.  It is approximately 7MB large.

     If you've already unpacked `gcc-2.7.2.tar.gz' into a directory
     (named `gcc-2.7.2') called the "source tree" for `gcc', you can
     delete the distribution itself, but you'll need to remember to
     skip any instructions to unpack this distribution.

     Without an applicable `gcc' source tree, you cannot build `g77'.
     You can obtain an FSF distribution of `gcc' from the FSF.

`g77-0.5.18.tar.gz'
     You probably have already unpacked this distribution, or you are
     reading an advanced copy of this manual, which is contained in
     this distribution.  This distribution approximately 1MB large.

     You can obtain an FSF distribution of `g77' from the FSF, the same
     way you obtained `gcc'.

100MB disk space
     For a complete "bootstrap" build, about 100MB of disk space is
     required for `g77' by the author's current Linux system.

     Some juggling can reduce the amount of space needed; during the
     bootstrap process, once Stage 3 starts, during which the version
     of `gcc' that has been copied into the `stage2/' directory is used
     to rebuild the system, you can delete the `stage1/' directory to
     free up some space.

     It is likely that many systems don't require the complete
     bootstrap build, as they already have a recent version of `gcc'
     installed.  Such systems might be able to build `g77' with only
     about 75MB of free space.

`patch'
     Although you can do everything `patch' does yourself, by hand,
     without much trouble, having `patch' installed makes installation
     of new versions of GNU utilities such as `g77' so much easier that
     it is worth getting.  You can obtain `patch' the same way you
     obtained `gcc' and `g77'.

     In any case, you can apply patches by hand--patch files are
     designed for humans to read them.

`make'
     Your system must have `make', and you will probably save yourself
     a lot of trouble if it is GNU `make' (sometimes referred to as
     `gmake').

`cc'
     Your system must have a working C compiler.

     *Note Installing GNU CC: (gcc)Installation, for more information
     on prerequisites for installing `gcc'.

`bison'
     If you do not have `bison' installed, you can usually work around
     any need for it, since `g77' itself does not use it, and `gcc'
     normally includes all files generated by running it in its
     distribution.  You can obtain `bison' the same way you obtained
     `gcc' and `g77'.

     *Note Missing bison?::, for information on how to work around not
     having `bison'.

`makeinfo'
     If you are missing `makeinfo', you can usually work around any
     need for it.  You can obtain `makeinfo' the same way you obtained
     `gcc' and `g77'.

     *Note Missing makeinfo?::, for information on getting around the
     lack of `makeinfo'.

`root' access
     To perform the complete installation procedures on a system, you
     need to have `root' access to that system, or equivalent access.

     Portions of the procedure (such as configuring and building `g77')
     can be performed by any user with enough disk space and virtual
     memory.

     However, these instructions are oriented towards less-experienced
     users who want to install `g77' on their own personal systems.

     System administrators with more experience will want to determine
     for themselves how they want to modify the procedures described
     below to suit the needs of their installation.


File: ^.!gcc.docs.fortran.g77,  Node: Problems Installing,  Next: Quick Start,  Prev: Prerequisites,  Up: Installation

Problems Installing
===================

   This is a list of problems (and some apparent problems which don't
really mean anything is wrong) that show up when configuring, building,
installing, or porting GNU Fortran.

   *Note Installation Problems: (gcc)Installation Problems, for more
information on installation problems that can afflict either `gcc' or
`g77'.

* Menu:

* General Problems::         Problems afflicting most or all systems.
* Cross-compiler Problems::  Problems afflicting cross-compilation setups.


File: ^.!gcc.docs.fortran.g77,  Node: General Problems,  Next: Cross-compiler Problems,  Up: Problems Installing

General Problems
----------------

   * On SunOS systems, linking the `f771' program produces an error
     message concerning an undefined symbol named `_strtoul'.

     This is not a `g77' bug.  *Note Patching GNU Fortran::, for
     information on a workaround provided by `g77'.

     The proper fix is either to upgrade your system to one that
     provides a complete ANSI C environment, or improve `gcc' so that
     it provides one for all the languages and configurations it
     supports.

     *Note:* In earlier versions of `g77', an automated workaround for
     this problem was attempted.  It worked for systems without
     `_strtoul', substituting the incomplete-yet-sufficient version
     supplied with `g77' for those systems.  However, the automated
     workaround failed mysteriously for systems that appeared to have
     conforming ANSI C environments, and it was decided that, lacking
     resources to more fully investigate the problem, it was better to
     not punish users of those systems either by requiring them to work
     around the problem by hand or by always substituting an incomplete
     `strtoul()' implementation when their systems had a complete,
     working one.  Unfortunately, this meant inconveniencing users of
     systems not having `strtoul()', but they're using obsolete (and
     generally unsupported) systems anyway.

   * It'd be helpful if `g77''s `Makefile.in' or `Make-lang.in' would
     create the various `stageN' directories and their subdirectories,
     so expert installers wouldn't have to reconfigure after cleaning
     up.

   * Improvements to the way `libf2c' is built could make building
     `g77' as a cross-compiler easier--for example, passing and using
     `LD' and `AR' in the appropriate ways.

   * `g77' currently requires application of a patch file to the gcc
     compiler tree (at least up through gcc version 2.7.0).  The
     necessary patches should be folded in to the mainline gcc
     distribution.

     (Some combinations of versions of `g77' and `gcc' might actually
     *require* no patches, but the patch files will be provided anyway
     as long as there are more changes expected in subsequent releases.
     These patch files might contain unnecessary, but possibly helpful,
     patches.  As a result, it is possible this issue might never be
     resolved, except by eliminating the need for the person
     configuring `g77' to apply a patch by hand, by going to a more
     automated approach (such as configure-time patching).

   * It should be possible to build the runtime without building `cc1'
     and other non-Fortran items, but, for now, an easy way to do that
     is not yet established.

   * Compiling `g77' requires GNU C, not just ANSI C.  Fixing this
     wouldn't be very hard (just tedious), but the code using GNU
     extensions to the C language is expected to be rewritten for 0.6
     anyway, so there are no plans for an interim fix.


File: ^.!gcc.docs.fortran.g77,  Node: Cross-compiler Problems,  Prev: General Problems,  Up: Problems Installing

Cross-compiler Problems
-----------------------

   `g77' has been in alpha testing since September of 1992, and in
public beta testing since February of 1995.  Alpha testing was done by
a small number of people worldwide on a fairly wide variety of
machines, involving self-compilation in most or all cases.  Beta
testing has been done primarily via self-compilation, but in more and
more cases, cross-compilation (and "criss-cross compilation", where a
version of a compiler is built on one machine to run on a second and
generate code that runs on a third) has been tried and has succeeded,
to varying extents.

   Generally, `g77' can be ported to any configuration to which `gcc',
`f2c', and `libf2c' can be ported and made to work together, aside from
the known problems described in this manual.  If you want to port `g77'
to a particular configuration, you should first make sure `gcc' and
`libf2c' can be ported to that configuration before focusing on `g77',
because `g77' is so dependent on them.

   Even for cases where `gcc' and `libf2c' work, you might run into
problems with cross-compilation on certain machines, for several
reasons.

   * There is one known bug (a design bug to be fixed in 0.6) that
     prevents configuration of `g77' as a cross-compiler in some cases,
     though there are assumptions made during configuration that
     probably make doing non-self-hosting builds a hassle, requiring
     manual intervention.

   * `gcc' might still have some trouble being configured for certain
     combinations of machines.  For example, it might not know how to
     handle floating-point constants.

   * There are still some challenges putting together the right
     run-time libraries (needed by `libf2c') for a target system,
     depending on the systems involved in the configuration.  (This is
     a general problem with cross-compilation, and with `gcc' in
     particular.)


File: ^.!gcc.docs.fortran.g77,  Node: Quick Start,  Next: Complete Installation,  Prev: Problems Installing,  Up: Installation

Quick Start
===========

   This procedure configures, builds, and installs `g77' "out of the
box" and works on most UNIX systems.  Each command is identified by a
unique number, used in the explanatory text that follows.  For the most
part, the output of each command is not shown, though indications of
the types of responses are given in a few cases.

   To perform this procedure, the installer must be logged in as user
`root'.  Much of it can be done while not logged in as `root', and
users experienced with UNIX administration should be able to modify the
procedure properly to do so.

   Following traditional UNIX conventions, it is assumed that the
source trees for `g77' and `gcc' will be placed in `/usr/src'.  It also
is assumed that the source distributions themselves already reside in
`/usr/FSF', a naming convention used by the author of `g77' on his own
system:

     /usr/FSF/gcc-2.7.2.tar.gz
     /usr/FSF/g77-0.5.18.tar.gz

   Users of the following systems should not blindly follow these
quick-start instructions, because of problems their systems have coping
with straightforward installation of `g77':

   * SunOS

   * Alpha

   Instead, see *Note Complete Installation::, for detailed information
on how to configure, build, and install `g77' for your particular
system.  Also, see *Note Known Causes of Trouble with GNU Fortran:
Trouble, for information on bugs and other problems known to afflict the
installation process, and how to report newly discovered ones.

   If your system is *not* on the above list, and *is* a UNIX system or
one of its variants, you should be able to follow the instructions
below.  If you vary *any* of the steps below, you might run into
trouble, including possibly breaking existing programs for other users
of your system.  Before doing so, it is wise to review the explanations
of some of the steps.  These explanations follow this list of steps.

     sh[ 1]# `cd /usr/src'

     sh[ 2]# `gunzip -c < /usr/FSF/gcc-2.7.2.tar.gz | tar xf -'

     [Might say "Broken pipe"...that is normal on some systems.]
     sh[ 3]# `gunzip -c < /usr/FSF/g77-0.5.18.tar.gz | tar xf -'

     ["Broken pipe" again possible.]
     sh[ 4]# `ln -s gcc-2.7.2 gcc'

     sh[ 5]# `ln -s g77-0.5.18 g77'

     sh[ 6]# `mv -i g77/* gcc'

     [No questions should be asked by mv here; or, you made a mistake.]
     sh[ 7]# `patch -p1 -V t -d gcc-2.7.2 < gcc-2.7.2/f/gbe/2.7.2.diff'

     [Unless patch complains about rejected patches, this step worked.]
     sh[ 8]# `cd gcc'
     sh[ 9]# `touch f77-install-ok'

     [Do not do the above if your system already has an f77
     command, unless you've checked that overwriting it
     is okay.]
     sh[10]# `touch f2c-install-ok'

     [Do not do the above if your system already has an f2c
     command, unless you've checked that overwriting it
     is okay.  Else, `touch f2c-exists-ok'.]
     sh[11]# `./configure --prefix=/usr'

     [Do not do the above if gcc is not installed in /usr/bin.
     You might need a different `--prefix=...', as
     described below.]
     sh[12]# `make bootstrap'

     [This takes a long time, and is where most problems occur.]
     sh[13]# `rm -fr stage1'

     sh[14]# `make -k install'

     [The actual installation.]
     sh[15]# `g77 -v'

     [Verify that g77 is installed, obtain version info.]
     sh[16]#

   *Note Updating Your Info Directory: Updating Documentation, for
information on how to update your system's top-level `info' directory
to contain a reference to this manual, so that users of `g77' can
easily find documentation instead of having to ask you for it.

   Elaborations of many of the above steps follows:

Step 1: `cd /usr/src'
     You can build `g77' pretty much anyplace.  By convention, this
     manual assumes `/usr/src'.  It might be helpful if other users on
     your system knew where to look for the source code for the
     installed version of `g77' and `gcc' in any case.

Step 4: `ln -s gcc-2.7.2 gcc'
Step 5: `ln -s g77-0.5.18 g77'
     These commands mainly help reduce typing, and help reduce visual
     clutter in examples in this manual showing what to type to install
     `g77'.

     *Note Unpacking::, for information on using distributions of `g77'
     made by organizations other than the FSF.

Step 6: `mv -i g77/* gcc'
     After doing this, you can, if you like, type `rm g77' and `rmdir
     g77-0.5.18' to remove the empty directory and the symbol link to
     it.  But, it might be helpful to leave them around as quick
     reminders of which version(s) of `g77' are installed on your
     system.

     *Note Unpacking::, for information on the contents of the `g77'
     directory (as merged into the `gcc' directory).

Step 7: `patch -p1 ...'
     This can produce a wide variety of printed output, from `Hmm, I
     can't seem to find a patch in there anywhere...' to long lists of
     messages indicated that patches are being found, applied
     successfully, and so on.

     If messages about "fuzz", "offset", or especially "reject files"
     are printed, it might mean you applied the wrong patch file.  If
     you believe this is the case, it is best to restart the sequence
     after deleting (or at least renaming to unused names) the
     top-level directories for `g77' and `gcc' and their symbolic links.

     After this command finishes, the `gcc' directory might have old
     versions of several files as saved by `patch'.  To remove these,
     after `cd gcc', type `rm -i *.~*~'.

     *Note Merging Distributions::, for more information.

Step 9: `touch f77-install-ok'
     Don't do this if you don't want to overwrite an existing version
     of `f77' (such as a native compiler, or a script that invokes
     `f2c').  Otherwise, installation will overwrite the `f77' command
     and the `f77' man pages with copies of the corresponding `g77'
     material.

     *Note Installing `f77': Installing f77, for more information.

Step 10: `touch f2c-install-ok'
     Don't do this if you don't want to overwrite an existing
     installation of `libf2c' (though, chances are, you do).  Instead,
     `touch f2c-exists-ok' to allow the installation to continue
     without any error messages about `/usr/lib/libf2c.a' already
     existing.

     *Note Installing `f2c': Installing f2c, for more information.

Step 11: `./configure --prefix=/usr'
     This is where you specify that the `g77' executable is to be
     installed in `/usr/bin/', the `libf2c.a' library is to be
     installed in `/usr/lib/', and so on.

     You should ensure that any existing installation of the `gcc'
     executable is in `/usr/bin/'.  Otherwise, installing `g77' so that
     it does not fully replace the existing installation of `gcc' is
     likely to result in the inability to compile Fortran programs.

     *Note Where in the World Does Fortran (and GNU C) Go?: Where to
     Install, for more information on determining where to install
     `g77'.  *Note Configuring gcc::, for more information on the
     configuration process triggered by invoking the `./configure'
     script.

Step 12: `make bootstrap'
     *Note Installing GNU CC: (gcc)Installation, for information on the
     kinds of diagnostics you should expect during this procedure.

     *Note Building gcc::, for complete `g77'-specific information on
     this step.

Step 13: `rm -fr stage1'
     You don't need to do this, but it frees up disk space.

Step 14: `make -k install'
     If this doesn't seem to work, try:

          make -k install install-libf77 install-f2c-all

     *Note Installation of Binaries::, for more information.

     *Note Updating Your Info Directory: Updating Documentation, for
     information on entering this manual into your system's list of
     texinfo manuals.


File: ^.!gcc.docs.fortran.g77,  Node: Complete Installation,  Next: Distributing Binaries,  Prev: Quick Start,  Up: Installation

Complete Installation
=====================

   Here is the complete `g77'-specific information on how to configure,
build, and install `g77'.

* Menu:

* Unpacking::
* Merging Distributions::
* f77: Installing f77.
* f2c: Installing f2c.
* Patching GNU Fortran::
* Where to Install::
* Configuring gcc::
* Building gcc::
* Pre-installation Checks::
* Installation of Binaries::
* Updating Documentation::
* bison: Missing bison?.
* makeinfo: Missing makeinfo?.


File: ^.!gcc.docs.fortran.g77,  Node: Unpacking,  Next: Merging Distributions,  Up: Complete Installation

Unpacking
---------

   The `gcc' source distribution is a stand-alone distribution.  It is
designed to be unpacked (producing the `gcc' source tree) and built as
is, assuming certain prerequisites are met (including the availability
of compatible UNIX programs such as `make', `cc', and so on).

   However, before building `gcc', you will want to unpack and merge
the `g77' distribution in with it, so that you build a Fortran-capable
version of `gcc', which includes the `g77' command, the necessary
run-time libraries, and this manual.

   Unlike `gcc', the `g77' source distribution is *not* a stand-alone
distribution.  It is designed to be unpacked and, afterwards,
immediately merged into an applicable `gcc' source tree.  That is, the
`g77' distribution *augments* a `gcc' distribution--without `gcc',
generally only the documentation is immediately usable.

   A sequence of commands typically used to unpack `gcc' and `g77' is:

     sh# `cd /usr/src'
     sh# `gunzip -d < /usr/FSF/gcc-2.7.2.tar.gz | tar xf -'
     sh# `gunzip -d < /usr/FSF/g77-0.5.18.tar.gz | tar xf -'
     sh# `ln -s gcc-2.7.2 gcc'
     sh# `ln -s g77-0.5.18 g77'
     sh# `mv -i g77/* gcc'

   *Notes:* The commands beginning with `gunzip...' might print `Broken
pipe...' as they complete.  That is nothing to worry about, unless you
actually *hear* a pipe breaking.  The `ln' commands are helpful in
reducing typing and clutter in installation examples in this manual.
Hereafter, the top level of `gcc' source tree is referred to as `gcc',
and the top level of just the `g77' source tree (prior to issuing the
`mv' command, above) is referred to as `g77'.

   There are three top-level names in a `g77' distribution:

     g77/COPYING.g77
     g77/README.g77
     g77/f

   All three entries should be moved (or copied) into a `gcc' source
tree (typically named after its version number and as it appears in the
FSF distributions--e.g. `gcc-2.7.2').

   `g77/f' is the subdirectory containing all of the code,
documentation, and other information that is specific to `g77'.  The
other two files exist to provide information on `g77' to someone
encountering a `gcc' source tree with `g77' already present, who has
not yet read these installation instructions and thus needs help
understanding that the source tree they are looking at does not come
from a single FSF distribution.  They also help people encountering an
unmerged `g77' source tree for the first time.

   *Note:* Please use *only* `gcc' and `g77' source trees as
distributed by the FSF.  Use of modified versions, such as the
Pentium-specific-optimization port of `gcc', is likely to result in
problems that appear to be in the `g77' code but, in fact, are not.  Do
not use such modified versions unless you understand all the
differences between them and the versions the FSF distributes--in which
case you should be able to modify the `g77' (or `gcc') source trees
appropriately so `g77' and `gcc' can coexist as they do in the stock
FSF distributions.


File: ^.!gcc.docs.fortran.g77,  Node: Merging Distributions,  Next: Installing f77,  Prev: Unpacking,  Up: Complete Installation

Merging Distributions
---------------------

   After merging the `g77' source tree into the `gcc' source tree, the
final merge step is done by applying the pertinent patches the `g77'
distribution provides for the `gcc' source tree.

   Read the file `gcc/f/gbe/README', and apply the appropriate patch
file for the version of the GNU CC compiler you have, if that exists.
If the directory exists but the appropriate file does not exist, you
are using either an old, unsupported version, or a release one that is
newer than the newest `gcc' version supported by the version of `g77'
you have.

   GNU version numbers make it easy to figure out whether a particular
version of a distribution is newer or older than some other version of
that distribution.  The format is, generally, MAJOR.MINOR.PATCH, with
each field being a decimal number.  (You can safely ignore leading
zeros; for example, 1.5.3 is the same as 1.5.03.) The MAJOR field only
increases with time.  The other two fields are reset to 0 when the
field to their left is incremented; otherwise, they, too, only increase
with time.  So, version 2.6.2 is newer than version 2.5.8, and version
3.0 is newer than both.  (Trailing `.0' fields often are omitted in
announcements and in names for distributions and the directories they
create.)

   If your version of `gcc' is older than the oldest version supported
by `g77' (as casually determined by listing the contents of
`gcc/f/gbe/'), you should obtain a newer, supported version of `gcc'.
(You could instead obtain an older version of `g77', or try and get
your `g77' to work with the old `gcc', but neither approach is
recommended, and you shouldn't bother reporting any bugs you find if you
take either approach, because they're probably already fixed in the
newer versions you're not using.)

   If your version of `gcc' is newer than the newest version supported
by `g77', it is possible that your `g77' will work with it anyway.  If
the version number for `gcc' differs only in the PATCH field, you might
as well try applying the `g77' patch that is for the newest version of
`gcc' having the same MAJOR and MINOR fields, as this is likely to work.

   So, for example, if `g77' has support for versions 2.7.0 and 2.7.1,
it is likely that `gcc-2.7.2' would work well with `g77' by using the
`2.7.1.diff' patch file provided with `g77' (aside from some offsets
reported by `patch', which usually are harmless).

   However, `gcc-2.8.0' would almost certainly not work with that
version of `g77' no matter which patch file was used, so a new version
of `g77' would be needed (and you should wait for it rather than
bothering the maintainers--*note User-Visible Changes: Changes.).

   This complexity is the result of `gcc' and `g77' being separate
distributions.  By keeping them separate, each product is able to be
independently improved and distributed to its user base more frequently.

   However, `g77' often requires changes to contemporary versions of
`gcc'.  Also, the GBE interface defined by `gcc' typically undergoes
some incompatible changes at least every time the MINOR field of the
version number is incremented, and such changes require corresponding
changes to the `g77' front end (FFE).

   It is hoped that the GBE interface, and the `gcc' and `g77' products
in general, will stabilize sufficiently for the need for hand-patching
to disappear.

   Invoking `patch' as described in `gcc/f/gbe/README' can produce a
wide variety of printed output, from `Hmm, I can't seem to find a patch
in there anywhere...' to long lists of messages indicated that patches
are being found, applied successfully, and so on.

   If messages about "fuzz", "offset", or especially "reject files" are
printed, it might mean you applied the wrong patch file.  If you
believe this is the case, it is best to restart the sequence after
deleting (or at least renaming to unused names) the top-level
directories for `g77' and `gcc' and their symbolic links.  That is
because `patch' might have partially patched some `gcc' source files,
so reapplying the correct patch file might result in the correct
patches being applied incorrectly (due to the way `patch' necessarily
works).

   After `patch' finishes, the `gcc' directory might have old versions
of several files as saved by `patch'.  To remove these, after `cd gcc',
type `rm -i *.~*~'.

   *Note:* `g77''s configuration file `gcc/f/config-lang.in' ensures
that the source code for the version of `gcc' being configured has at
least one GBE function required specifically by `g77'.  This function
was added to `gcc-2.7.1', making the patch file
`g77-0.5.17/f/gbe/2.7.1.diff' empty of actual patches.

   For `gcc-2.7.0' and earlier, this configuration-time checking should
catch failure to apply the correct patch and, if so caught, it should
abort the configuration with an explanation.  *Please* do not try to
disable the check, otherwise `g77' might well appear to build and
install correctly, and even appear to compile correctly, but could
easily produce broken code.

   `diff -rcp2N' is used to create the patch files in `gcc/f/gbe/'.


File: ^.!gcc.docs.fortran.g77,  Node: Installing f77,  Next: Installing f2c,  Prev: Merging Distributions,  Up: Complete Installation

Installing `f77'
----------------

   You should decide whether you want installation of `g77' to also
install an `f77' command.  On systems with a native `f77', this is not
normally desired, so `g77' does not do this by default.

   If you want `f77' installed, create the file `f77-install-ok' (e.g.
via the UNIX command `touch f77-install-ok') in the source or build
top-level directory (the same directory in which the `g77' `f'
directory resides, not the `f' directory itself), or edit
`gcc/f/Make-lang.in' and change the definition of the
`F77_INSTALL_FLAG' macro appropriately.

   Usually, this means that, after typing `cd gcc', you would type
`touch f77-install-ok'.

   When you enable installation of `f77', either a link to or a direct
copy of the `g77' command is made.  Similarly, `f77.1' is installed as
a man page.

   (The `uninstall' target in the `gcc/Makefile' also tests this macro
and file, when invoked, to determine whether to delete the installed
copies of `f77' and `f77.1'.)

   *Note:* No attempt is yet made to install a program (like a shell
script) that provides compatibility with any other `f77' programs.
Only the most rudimentary invocations of `f77' will work the same way
with `g77'.


File: ^.!gcc.docs.fortran.g77,  Node: Installing f2c,  Next: Patching GNU Fortran,  Prev: Installing f77,  Up: Complete Installation

Installing `f2c'
----------------

   Currently, `g77' does not include `f2c' itself in its distribution.
However, it does include a modified version of the `libf2c'.  This
version is normally compatible with `f2c', but has been modified to
meet the needs of `g77' in ways that might possibly be incompatible
with some versions or configurations of `f2c'.

   Decide how installation of `g77' should affect any existing
installation of `f2c' on your system.

   If you do not have `f2c' on your system (e.g. no `/usr/bin/f2c', no
`/usr/include/f2c.h', and no `/usr/lib/libf2c.a', `/usr/lib/libF77.a',
or `/usr/lib/libI77.a'), you don't need to be concerned with this item.

   If you do have `f2c' on your system, you need to decide how users of
`f2c' will be affected by your installing `g77'.  Since `g77' is
currently designed to be object-code-compatible with `f2c' (with very
few, clear exceptions), users of `f2c' might want to combine
`f2c'-compiled object files with `g77'-compiled object files in a
single executable.

   To do this, users of `f2c' should use the same copies of `f2c.h' and
`libf2c.a' that `g77' uses (and that get built as part of `g77').

   If you do nothing here, the `g77' installation process will not
overwrite the `include/f2c.h' and `lib/libf2c.a' files with its own
versions, and in fact will not even install `libf2c.a' for use with the
newly installed versions of `gcc' and `g77' if it sees that
`lib/libf2c.a' exists--instead, it will print an explanatory message
and skip this part of the installation.

   To install `g77''s versions of `f2c.h' and `libf2c.a' in the
appropriate places, create the file `f2c-install-ok' (e.g. via the UNIX
command `touch f2c-install-ok') in the source or build top-level
directory (the same directory in which the `g77' `f' directory resides,
not the `f' directory itself), or edit `gcc/f/Make-lang.in' and change
the definition of the `F2C_INSTALL_FLAG' macro appropriately.

   Usually, this means that, after typing `cd gcc', you would type
`touch f2c-install-ok'.

   Make sure that when you enable the overwriting of `f2c.h' and
`libf2c.a' as used by `f2c', you have a recent and properly configured
version of `bin/f2c' so that it generates code that is compatible with
`g77'.

   If you don't want installation of `g77' to overwrite `f2c''s existing
installation, but you do want `g77' installation to proceed with
installation of its own versions of `f2c.h' and `libf2c.a' in places
where `g77' will pick them up (even when linking `f2c'-compiled object
files--which might lead to incompatibilities), create the file
`f2c-exists-ok' (e.g. via the UNIX command `touch f2c-exists-ok') in
the source or build top-level directory, or edit `gcc/f/Make-lang.in'
and change the definition of the `F2CLIBOK' macro appropriately.


File: ^.!gcc.docs.fortran.g77,  Node: Patching GNU Fortran,  Next: Where to Install,  Prev: Installing f2c,  Up: Complete Installation

Patching GNU Fortran
--------------------

   If you're using a SunOS system, you'll need to make the following
change to `gcc/f/proj.h': edit the line reading

     #define FFEPROJ_STRTOUL 1  ...

by replacing the `1' with `0'.

   This causes a minimal version of `strtoul()' provided as part of the
`g77' distribution to be compiled and linked into whatever `g77'
programs need it, since some systems (like SunOS) do not provide this
function in their system libraries.

   Similarly, a minimal version of `bsearch()' is available and can be
enabled by editing a line similar to the one for `strtoul()' above in
`gcc/f/proj.h', if your system libraries lack `bsearch()'.

   These are not problems with `g77', which requires an ANSI C
environment.  You should upgrade your system to one that provides a
full ANSI C environment, or encourage the maintainers of `gcc' to
provide one to all `gcc'-based compilers in future `gcc' distributions.

   *Note Problems Installing::, for more information on why `strtoul()'
comes up missing and on approaches to dealing with this problem that
have already been tried.


File: ^.!gcc.docs.fortran.g77,  Node: Where to Install,  Next: Configuring gcc,  Prev: Patching GNU Fortran,  Up: Complete Installation

Where in the World Does Fortran (and GNU C) Go?
-----------------------------------------------

   Before configuring, you should make sure you know where you want the
`g77' and `gcc' binaries to be installed after they're built, because
this information is given to the configuration tool and used during the
build itself.

   A `g77' installation necessarily requires installation of a
`g77'-aware version of `gcc', so that the `gcc' command recognizes
Fortran source files and knows how to compile them.

   For this to work, the version of `gcc' that you will be building as
part of `g77' *must* be installed as the "active" version of `gcc' on
the system.

   Sometimes people make the mistake of installing `gcc' as
`/usr/local/bin/gcc', leaving an older, non-Fortran-aware version in
`/usr/bin/gcc'.  (Or, the opposite happens.) This can result in `g77'
being unable to compile Fortran source files, because when it calls on
`gcc' to do the actual compilation, `gcc' complains that it does not
recognize the language, or the file name suffix.

   So, determine whether `gcc' already is installed on your system,
and, if so, *where* it is installed, and prepare to configure the new
version of `gcc' you'll be building so that it installs over the
existing version of `gcc'.

   You might want to back up your existing copy of `bin/gcc', and the
entire `lib/' directory, before you perform the actual installation (as
described in this manual).

   Existing `gcc' installations typically are found in `/usr' or
`/usr/local'.  If you aren't certain where the currently installed
version of `gcc' and its related programs reside, look at the output of
this command:

     gcc -v -o /tmp/delete-me -xc /dev/null -xnone

   All sorts of interesting information on the locations of various
`gcc'-related programs and data files should be visible in the output
of the above command.  However, you do have to sift through it
yourself; `gcc' currently provides no easy way to ask it where it is
installed and where it looks for the various programs and data files it
calls on to do its work.

   Just *building* `g77' should not overwrite any installed
programs--but, usually, after you build `g77', you will want to install
it, so backing up anything it might overwrite is a good idea.  (This is
true for any package, not just `g77', though in this case it is
intentional that `g77' overwrites `gcc' if it is already installed--it
is unusual that the installation process for one distribution
intentionally overwrites a program or file installed by another
distribution.)

   Another reason to back up the existing version first, or make sure
you can restore it easily, is that it might be an older version on
which other users have come to depend for certain behaviors.  However,
even the new version of `gcc' you install will offer users the ability
to specify an older version of the actual compilation programs if
desired, and these older versions need not include any `g77' components.
*Note Specifying Target Machine and Compiler Version: (gcc)Target
Options, for information on the `-V' option of `gcc'.


File: ^.!gcc.docs.fortran.g77,  Node: Configuring gcc,  Next: Building gcc,  Prev: Where to Install,  Up: Complete Installation

Configuring GNU CC
------------------

   `g77' is configured automatically when you configure `gcc'.  There
are two parts of `g77' that are configured in two different
ways--`g77', which "camps on" to the `gcc' configuration mechanism, and
`libf2c', which uses a variation of the GNU `autoconf' configuration
system.

   Generally, you shouldn't have to be concerned with either `g77' or
`libf2c' configuration, unless you're configuring `g77' as a
cross-compiler.  In this case, the `libf2c' configuration, and possibly
the `g77' and `gcc' configurations as well, might need special
attention.  (This also might be the case if you're porting `gcc' to a
whole new system--even if it is just a new operating system on an
existing, supported CPU.)

   To configure the system, see *Note Installing GNU CC:
(gcc)Installation, following the instructions for running `./configure'.
Pay special attention to the `--prefix=' option, which you almost
certainly will need to specify.

   (Note that `gcc' installation information is provided as a straight
text file in `gcc/INSTALL'.)

   The information printed by the invocation of `./configure' should
show that the `f' directory (the Fortran language) has been configured.
If it does not, there is a problem.

   *Note:* Configuring with the `--srcdir' argument is known to work
with GNU `make', but it is not known to work with other variants of
`make'.  Irix5.2 and SunOS4.1 versions of `make' definitely won't work
outside the source directory at present.  `g77''s portion of the
`configure' script issues a warning message about this when you
configure for building binaries outside the source directory.


File: ^.!gcc.docs.fortran.g77,  Node: Building gcc,  Next: Pre-installation Checks,  Prev: Configuring gcc,  Up: Complete Installation

Building GNU CC
---------------

   Building `g77' requires building enough of `gcc' that these
instructions assume you're going to build all of `gcc', including
`g++', `protoize', and so on.  You can save a little time and disk
space by changes the `LANGUAGES' macro definition in `gcc/Makefile.in'
or `gcc/Makefile', but if you do that, you're on your own.  One change
is almost *certainly* going to cause failures: removing `c' or `f77'
from the definition of the `LANGUAGES' macro.

   After configuring `gcc', which configures `g77' and `libf2c'
automatically, you're ready to start the actual build by invoking
`make'.

   *Note:* You *must* have run `./configure' before you run `make',
even if you're using an already existing `gcc' development directory,
because `./configure' does the work to recognize that you've added
`g77' to the configuration.

   There are two general approaches to building GNU CC from scratch:

"bootstrap"
     This method uses minimal native system facilities to build a
     barebones, unoptimized `gcc', that is then used to compile
     ("bootstrap") the entire system.

"straight"
     This method assumes a more complete native system exists, and uses
     that just once to build the entire system.

   On all systems without a recent version of `gcc' already installed,
the bootstrap method must be used.  In particular, `g77' uses
extensions to the C language offered, apparently, only by `gcc'.

   On most systems with a recent version of `gcc' already installed,
the straight method can be used.  This is an advantage, because it
takes less CPU time and disk space for the build.  However, it does
require that the system have fairly recent versions of many GNU
programs and other programs, which are not enumerated here.

* Menu:

* Bootstrap Build::  For all systems.
* Straight Build::   For systems with a recent version of `gcc'.


File: ^.!gcc.docs.fortran.g77,  Node: Bootstrap Build,  Next: Straight Build,  Up: Building gcc

Bootstrap Build
...............

   A complete bootstrap build is done by issuing a command beginning
with `make bootstrap ...', as described in *Note Installing GNU CC:
(gcc)Installation.  This is the most reliable form of build, but it
does require the most disk space and CPU time, since the complete system
is built twice (in Stages 2 and 3), after an initial build (during
Stage 1) of a minimal `gcc' compiler using the native compiler and
libraries.

   You might have to, or want to, control the way a bootstrap build is
done by entering the `make' commands to build each stage one at a time,
as described in the `gcc' manual.  For example, to save time or disk
space, you might want to not bother doing the Stage 3 build, in which
case you are assuming that the `gcc' compiler you have built is
basically sound (because you are giving up the opportunity to compare a
large number of object files to ensure they're identical).

   To save some disk space during installation, after Stage 2 is built,
you can type `rm -fr stage1' to remove the binaries built during Stage
1.

   *Note:* If you do build Stage 3 and you compare the object files
produced by various stages, the file `gcc/f/zzz.o' *will* be different.
That is because it contains a string with an expansion of the
`__TIME__' macro, which expands to the current time of day.  It is
nothing to worry about, since `gcc/f/zzz.c' doesn't contain any actual
code.  It does allow you to override its use of `__DATE__' and
`__TIME__' by defining macros for the compilation--see the source code
for details.

   *Note Installing GNU CC: (gcc)Installation, for important
information on building `gcc' that is not described in this `g77'
manual.  For example, explanations of diagnostic messages and whether
they're expected, or indicate trouble, are found there.


File: ^.!gcc.docs.fortran.g77,  Node: Straight Build,  Prev: Bootstrap Build,  Up: Building gcc

Straight Build
..............

   If you have a recent version of `gcc' already installed on your
system, and if you're reasonably certain it produces code that is
object-compatible with the version of `gcc' you want to build as part
of building `g77', you can save time and disk space by doing a straight
build.

   To build just the C and Fortran compilers and the necessary run-time
libraries, issue the following command:

     make -k CC=gcc LANGUAGES=f77 all g77

   (The `g77' target is necessary because the `gcc' build procedures
apparently do not automatically build command drivers for languages in
subdirectories.  It's the `all' target that triggers building
everything except, apparently, the `g77' command itself.)

   If you run into problems using this method, you have two options:

   * Abandon this approach and do a bootstrap build.

   * Try to make this approach work by diagnosing the problems you're
     running into and retrying.

   Especially if you do the latter, you might consider submitting any
solutions as bug/fix reports.  *Note Known Causes of Trouble with GNU
Fortran: Trouble.

   However, understand that many problems preventing a straight build
from working are not `g77' problems, and, in such cases, are not likely
to be addressed in future versions of `g77'.


File: ^.!gcc.docs.fortran.g77,  Node: Pre-installation Checks,  Next: Installation of Binaries,  Prev: Building gcc,  Up: Complete Installation

Pre-installation Checks
-----------------------

   Before installing the system, which includes installing `gcc', you
might want to do some minimum checking to ensure that some basic things
work.

   Here are some commands you can try, and output typically printed by
them when they work:

     sh# `cd /usr/src/gcc'
     sh# `./g77 --driver=./xgcc -B./ -v'
      ./xgcc -B./ -v -fnull-version -o /tmp/gfa03648 ...
     Reading specs from ./specs
     gcc version 2.7.1
      ./cpp -lang-c -v -isystem ./include -undef ...
     GNU CPP version 2.7.1 (80386, BSD syntax)
     #include "..." search starts here:
     #include <...> search starts here:
      ./include
      /usr/include
      /usr/i486-unknown-linuxaout/include
      /usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include
      /usr/include
     End of search list.
      ./f771 /tmp/cca03648.i -quiet -dumpbase null.F -version ...
     GNU F77 version 2.7.1 (80386, BSD syntax) compiled ...
     GNU Fortran Front End version 0.5.18 compiled: ...
      as -o /tmp/cca036481.o /tmp/cca03648.s
      ld -m i386linux -o /tmp/gfa03648 /usr/lib/crt0.o -L. ...
     /usr/lib/crt0.o(.text+0x35): undefined reference to `main'
     sh# `./xgcc -B./ -v -o /tmp/delete-me -xc /dev/null -xnone'
     Reading specs from ./specs
     gcc version 2.7.1
      ./cpp -lang-c -v -isystem ./include -undef ...
     GNU CPP version 2.7.1 (80386, BSD syntax)
     #include "..." search starts here:
     #include <...> search starts here:
      ./include
      /usr/include
      /usr/i486-unknown-linuxaout/include
      /usr/lib/gcc-lib/i486-unknown-linuxaout/2.7.1/include
      /usr/include
     End of search list.
      ./cc1 /tmp/cca03659.i -quiet -dumpbase null.c -version ...
     GNU C version 2.7.1 (80386, BSD syntax) compiled ...
      as -o /tmp/cca036591.o /tmp/cca03659.s
      ld -m i386linux -o /tmp/delete-me /usr/lib/crt0.o -L. ...
     /usr/lib/crt0.o(.text+0x35): undefined reference to `main'
     sh#

   (Note that long lines have been truncated, and `...' used to
indicate such truncations.)

   The above two commands test whether `g77' and `gcc', respectively,
are able to compile empty (null) source files, whether invocation of
the C preprocessor works, whether libraries can be linked (even though
there is an undefined reference due to there being no main program
unit), and so on.

   If the output you get from either of the above two commands is
noticably different, especially if it is shorter or longer in ways that
do not look consistent with the above sample output, you probably
should not install `gcc' and `g77' until you have investigated further.

   For example, you could try compiling actual applications and seeing
how that works.  (You might want to do that anyway, even if the above
tests work.)

   To compile using the not-yet-installed versions of `gcc' and `g77',
use the following commands to invoke them.

   To invoke `g77', type:

     /usr/src/gcc/g77 --driver=/usr/src/gcc/xgcc -B/usr/src/gcc/ ...

   To invoke `gcc', type:

     /usr/src/gcc/xgcc -B/usr/src/gcc/ ...


File: ^.!gcc.docs.fortran.g77,  Node: Installation of Binaries,  Next: Updating Documentation,  Prev: Pre-installation Checks,  Up: Complete Installation

Installation of Binaries
------------------------

   After configuring, building, and testing `g77' and `gcc', when you
are ready to install them on your system, type:

     make -k CC=gcc LANGUAGES=f77 install

   As described in *Note Installing GNU CC: (gcc)Installation, the
values for the `CC' and `LANGUAGES' macros should be the same as those
you supplied for the build itself.

   So, the details of the above command might vary if you used a
bootstrap build (where you might be able to omit both definitions, or
might have to supply the same definitions you used when building the
final stage) or if you deviated from the instructions for a straight
build.

   If the above command does not install `libf2c.a' as expected, try
this:

     make -k ... install install-libf77 install-f2c-all

   We don't know why some non-GNU versions of `make' sometimes require
this alternate command, but they do.  (Remember to supply the
appropriate definitions for `CC' and `LANGUAGES' where you see `...' in
the above command.)

   Note that using the `-k' option tells `make' to continue after some
installation problems, like not having `makeinfo' installed on your
system.  It might not be necessary.


File: ^.!gcc.docs.fortran.g77,  Node: Updating Documentation,  Next: Missing bison?,  Prev: Installation of Binaries,  Up: Complete Installation

Updating Your Info Directory
----------------------------

   As part of installing `g77', you should make sure users of `info'
can easily access this manual on-line.  Do this by making sure a line
such as the following exists in `/usr/info/dir', or in whatever file is
the top-level file in the `info' directory on your system (perhaps
`/usr/local/info/dir':

     * g77: (g77).           The GNU Fortran programming language.

   If the menu in `dir' is organized into sections, `g77' probably
belongs in a section with a name such as the following:

   * Writing Programs

   * Programming Languages

   * Languages Other Than C

   * Scientific/Engineering Tools

   * GNU Compilers


File: ^.!gcc.docs.fortran.g77,  Node: Missing bison?,  Next: Missing makeinfo?,  Prev: Updating Documentation,  Up: Complete Installation

Missing `bison'?
----------------

   If you cannot install `bison', make sure you have started with a
*fresh* distribution of `gcc', do *not* do `make maintainer-clean' (in
other versions of `gcc', this was called `make realclean'), and, to
ensure that `bison' is not invoked by `make' during the build, type
these commands:

     sh# `cd gcc'
     sh# `touch bi-parser.c bi-parser.h c-parse.c c-parse.h cexp.c'
     sh# `touch cp/parse.c cp/parse.h objc-parse.c'
     sh#

   These commands update the date-time-modified information for all the
files produced by the various invocations of `bison' in the current
versions of `gcc', so that `make' no longer believes it needs to update
them.  All of these files should already exist in a `gcc' distribution,
but the application of patches to upgrade to a newer version can leave
the modification information set such that the `bison' input files look
more "recent" than the corresponding output files.

   *Note:* New versions of `gcc' might change the set of files it
generates by invoking `bison'--if you cannot figure out for yourself
how to handle such a situation, try an older version of `gcc' until you
find someone who can (or until you obtain and install `bison').


File: ^.!gcc.docs.fortran.g77,  Node: Missing makeinfo?,  Prev: Missing bison?,  Up: Complete Installation

Missing `makeinfo'?
-------------------

   If you cannot install `makeinfo', either use the `-k' option when
invoking make to specify any of the `install' or related targets, or
specify `MAKEINFO=echo' on the `make' command line.

   If you fail to do one of these things, some files, like `libf2c.a',
might not be installed, because the failed attempt by `make' to invoke
`makeinfo' causes it to cancel any further processing.


File: ^.!gcc.docs.fortran.g77,  Node: Distributing Binaries,  Next: Settings,  Prev: Complete Installation,  Up: Installation

Distributing Binaries
=====================

   If you are building `g77' for distribution to others in binary form,
first make sure you are aware of your legal responsibilities (read the
file `gcc/COPYING' thoroughly).

   Then, consider your target audience and decide where `g77' should be
installed.

   For systems like Linux that have no native Fortran compiler (or
where `g77' could be considered the native compiler for Fortran and
`gcc' for C, etc.), you should definitely configure `g77' for
installation in `/usr/bin' instead of `/usr/local/bin'.  Specify the
`--prefix=/usr' option when running `./configure'.  You might also want
to set up the distribution so the `f77' command is a link to
`g77'--just make an empty file named `f77-install-ok' in the source or
build directory (the one in which the `f' directory resides, not the
`f' directory itself) when you specify one of the `install' or
`uninstall' targets in a `make' command.

   For a system that might already have `f2c' installed, you definitely
will want to make another empty file (in the same directory) named
either `f2c-exists-ok' or `f2c-install-ok'.  Use the former if you
don't want your distribution to overwrite `f2c'-related files in
existing systems; use the latter if you want to improve the likelihood
that users will be able to use both `f2c' and `g77' to compile code for
a single program without encountering link-time or run-time
incompatibilities.

   (Make sure you clearly document, in the "advertising" for your
distribution, how installation of your distribution will affect
existing installations of `gcc', `f2c', `f77', `libf2c.a', and so on.
Similarly, you should clearly document any requirements you assume are
met by users of your distribution.)

   For other systems with native `f77' (and `cc') compilers, configure
`g77' as you (or most of your audience) would configure `gcc' for their
installations.  Typically this is for installation in `/usr/local', and
would not include a copy of `g77' named `f77', so users could still use
the native `f77'.

   In any case, for `g77' to work properly, you *must* ensure that the
binaries you distribute include:

`bin/g77'
     This is the command most users use to compile Fortran.

`bin/gcc'
     This is the command all users use to compile Fortran, either
     directly or indirectly via the `g77' command.  The `bin/gcc'
     executable file must have been built from a `gcc' source tree into
     which a `g77' source tree was merged and configured, or it will
     not know how to compile Fortran programs.

`bin/f77'
     In installations with no non-GNU native Fortran compiler, this is
     the same as `bin/g77'.  Otherwise, it should be omitted from the
     distribution, so the one on already on a particular system does
     not get overwritten.

`info/g77.info*'
     This is the documentation for `g77'.

     Please edit this documentation (by editing `gcc/f/*.texi' and
     doing `make doc' from the `/usr/src/gcc' directory) to reflect any
     changes you've made to `g77', or at least to encourage users of
     your binary distribution to report bugs to you first.

     Also, whether you distribute binaries or install `g77' on your own
     system, it might be helpful for everyone to add a line listing
     this manual by name and topic to the top-level `info' node in
     `/usr/info/dir'.  That way, users can find `g77' documentation more
     easily.  *Note Updating Your Info Directory: Updating
     Documentation.

`man/man1/g77.1'
     This is the short man page for `g77'.

`man/man1/f77.1'
     In installations where `f77' is the same as `g77', this is the
     same as `man/man1/g77.1'.  Otherwise, it should be omitted from
     the distribution, so the one already on a particular system does
     not get overwritten.

`lib/gcc-lib/.../f771'
     This is the actual Fortran compiler.

`lib/gcc-lib/.../libf2c.a'
     This is the run-time library for `g77'-compiled programs.

   Whether you want to include the slightly updated (and possibly
improved) versions of `cc1', `cc1plus', and whatever other binaries get
rebuilt with the changes the GNU Fortran distribution makes to the GNU
back end, is up to you.  These changes are highly unlikely to break any
compilers, and it is possible they'll fix back-end bugs that can be
demonstrated using front ends other than GNU Fortran's.

   Please assure users that unless they have a specific need for their
existing, older versions of `gcc' command, they are unlikely to
experience any problems by overwriting it with your version--though
they could certainly protect themselves by making backup copies first!
Otherwise, users might try and install your binaries in a "safe" place,
find they cannot compile Fortran programs with your distribution
(because, perhaps, they're picking up their old version of the `gcc'
command, which does not recognize Fortran programs), and assume that
your binaries (or, more generally, GNU Fortran distributions in
general) are broken, at least for their system.

   Finally, *please* ask for bug reports to go to you first, at least
until you're sure your distribution is widely used and has been well
tested.  This especially goes for those of you making any changes to
the `g77' sources to port `g77', e.g. to OS/2.
`[e-mail]' has received a fair amount of bug reports that
turned out to be problems with other peoples' ports and distributions,
about which nothing could be done for the user.  Once you are quite
certain a bug report does not involve your efforts, you can forward it
to us.


File: ^.!gcc.docs.fortran.g77,  Node: Settings,  Prev: Distributing Binaries,  Up: Installation

Changing Settings Before Building
=================================

   Here are some internal `g77' settings that can be changed by editing
source files in `gcc/f/' before building.

   This information, and perhaps even these settings, represent
stop-gap solutions to problems people doing various ports of `g77' have
encountered.  As such, none of the following information is expected to
be pertinent in future versions of `g77'.

* Menu:

* Maximum Stackable Size::       Large arrays are forced off the stack frame.
* Floating-point Bit Patterns::  Possible programs building cross-compiler.
* Large Initialization::         Large arrays with `DATA' initialization.
* Alpha Problems::               Problems with 64-bit systems like Alphas.


File: ^.!gcc.docs.fortran.g77,  Node: Maximum Stackable Size,  Next: Floating-point Bit Patterns,  Up: Settings

Maximum Stackable Size
----------------------

   `g77', on most machines, puts many variables and arrays on the stack
where possible, and can be configured (by changing
`FFECOM_sizeMAXSTACKITEM' in `gcc/f/com.c') to force smaller-sized
entities into static storage (saving on stack space) or permit
larger-sized entities to be put on the stack (which can improve
run-time performance, as it presents more opportunities for the GBE to
optimize the generated code).


File: ^.!gcc.docs.fortran.g77,  Node: Floating-point Bit Patterns,  Next: Large Initialization,  Prev: Maximum Stackable Size,  Up: Settings

Floating-point Bit Patterns
---------------------------

   The `g77' build will crash if an attempt is made to build it as a
cross-compiler for a target when `g77' cannot reliably determine the
bit pattern of floating-point constants for the target.  Planned
improvements for g77-0.6 will give it the capabilities it needs to not
have to crash the build but rather generate correct code for the target.
(Currently, `g77' would generate bad code under such circumstances if
it didn't crash during the build, e.g. when compiling a source file
that does something like `EQUIVALENCE (I,R)' and `DATA
R/3.1415926535/'.)


File: ^.!gcc.docs.fortran.g77,  Node: Large Initialization,  Next: Alpha Problems,  Prev: Floating-point Bit Patterns,  Up: Settings

Initialization of Large Aggregate Areas
---------------------------------------

   A warning message is issued when `g77' sees code that provides
initial values (e.g. via `DATA') to an aggregate area (`COMMON' or
`EQUIVALENCE', or even a large enough array or `CHARACTER' variable)
that is large enough to increase `g77''s compile time by roughly a
factor of 10.

   This size currently is quite small, since `g77' currently has a
known bug requiring too much memory and time to handle such cases.  In
`gcc/f/data.c', the macro `FFEDATA_sizeTOO_BIG_INIT_' is defined to the
minimum size for the warning to appear.  The size is specified in
storage units, which can be bytes, words, or whatever, on a
case-by-case basis.

   After changing this macro definition, you must (of course) rebuild
and reinstall `g77' for the change to take effect.

   Note that, as of version 0.5.18, improvements have reduced the scope
of the problem for *sparse* initialization of large arrays, especially
those with large, contiguous uninitialized areas.  However, the warning
is issued at a point prior to when `g77' knows whether the
initialization is sparse, and delaying the warning could mean it is
produced too late to be helpful.

   Therefore, the macro definition should not be adjusted to reflect
sparse cases.  Instead, adjust it to generate the warning when densely
initialized arrays begin to cause responses noticably slower than
linear performance would suggest.


File: ^.!gcc.docs.fortran.g77,  Node: Alpha Problems,  Prev: Large Initialization,  Up: Settings

Alpha Problems
--------------

   `g77' might warn when it is used to compile Fortran code for a
target configuration that is not basically a 32-bit machine (such as an
Alpha, which is a 64-bit machine, especially if it has a 64-bit
operating system running on it).  This is because `g77' is known to not
work properly on such configurations, although the reasons for this are
not fully explored.  This is expected to be fixed at 0.6, at which
point the warning would be dropped.  (The reason the unexplored
problems are expected to be fixed at 0.6 is because some known internal
design problems `g77' has, which reduce portability and the ability to
configure it as a cross-compiler, are presumed to be at least partly
responsible for the problems being encountered on the Alpha.  The
problems remain unexplored partly because the known problems exist and
are scheduled to be addressed anyway.  Plus, the `g77' maintainer does
not yet possess an Alpha workstation of his own.)


File: ^.!gcc.docs.fortran.g77,  Node: Debugging and Interfacing,  Next: Collected Fortran Wisdom,  Prev: Installation,  Up: Top

Debugging and Interfacing
*************************

   GNU Fortran currently generates code that is object-compatible with
the `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 `g77'-compiled code generally
requires some understanding of the way `g77' compiles code for various
constructs.

   Similarly, using a debugger to debug `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 `g77'
compiles code for constructs involving interfaces to other languages
and to debuggers.

   *Caution:* Much or all of this information pertains to only the
current release of `g77', sometimes even to using certain compiler
options with `g77' (such as `-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 `g77'.  This
information is provided primarily to make debugging of code generated
by this particular release of `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 `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 `g77' compiles a main program unit.
* Arrays::             Dealing with (possibly multi-dimensional) arrays.
* Procedures::         How `g77' constructs parameter lists
                       for procedures.
* Adjustable Arrays::  Special consideration for adjustable arrays.
* Alternate Returns::  How `g77' handles alternate returns.
* Functions::          Functions returning floating-point or character data.
* Common Blocks::      Accessing common variables while debugging.
* Local Equivalence Areas::  Accessing `EQUIVALENCE' while debugging.
* Alternate Entry Points::  How `g77' implements alternate `ENTRY'.
* Assigned Statement Labels::  How `g77' handles `ASSIGN'.


File: ^.!gcc.docs.fortran.g77,  Node: Names,  Next: Main Program Unit,  Up: Debugging and Interfacing

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 (`_') appended
by `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 `-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 `-funderscoring' is in force, any name (external or local) that
already has at least one underscore in it is implemented by `g77' by
appending two underscores.  External names are changed this way for
`f2c' compatibility.  Local names are changed this way to avoid
collisions with external names that are different in the source
code--`f2c' does the same thing, but there's no compatibility issue
there except for user expectations while debugging.

   For example:

     Max_Cost = 0

Here, a user would, in the debugger, refer to this variable using the
name `max_cost__' (or `MAX_COST__' or `Max_Cost__', as described below).
(We hope to improve `g77' in this regard in the future--don't write
scripts depending on this behavior!  Also, consider experimenting with
the `-fno-underscoring' option to try out debugging without having to
massage names by hand like this.)

   `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:

     Foo = 3.14159

Here, it is normally the case that the variable assigned will be named
`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 `g77' might instead be `FOO' or even `Foo', thus
affecting how debugging is done.

   Also:

     Call Foo

This would normally call a procedure that, if it were in a separate C
program, be defined starting with the line:

     void foo_()

However, `g77' command-line options could be used to change the casing
of names, resulting in the name `FOO_' or `Foo_' being given to the
procedure instead of `foo_', and the `-fno-underscoring' option could
be used to inhibit the appending of the underscore to the name.


File: ^.!gcc.docs.fortran.g77,  Node: Main Program Unit,  Next: Arrays,  Prev: Names,  Up: Debugging and Interfacing

Main Program Unit (PROGRAM)
===========================

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

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

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

   When debugging, one implication of the fact that `main()', which is
the place where the debugged program "starts" from the debugger's point
of view, is in `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
`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 `MAIN__', that should work fine.


File: ^.!gcc.docs.fortran.g77,  Node: Arrays,  Next: Procedures,  Prev: Main Program Unit,  Up: Debugging and Interfacing

Arrays (DIMENSION)
==================

   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 *first* subscript instead of the last;
`A(5,10,20)' immediately follows `A(4,10,20)', whereas with row-major
ordering it would follow `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 `A(5,10,20)' is easy enough
in Fortran (use `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 `A(5,10,20)' would be, and these calculations require knowing the
dimensions of `A'.

   For `DIMENSION A(2:11,21,0:29)', the calculation of the offset of
`A(5,10,20)' would be:

       (5-2)
     + (10-1)*(11-2+1)
     + (20-0)*(11-2+1)*(21-1+1)
     = 4293

So the C equivalent in this case would be `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 `f2c', `g77' does inform
the GBE that a multi-dimensional array (like `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 `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 `(5-2)' substitute `(5)', for `(10-1)' substitute `(10)', and
for `(20-0)' substitute `(20)'.  Actually, the implication of this can
be that the expression `*(&a[2][1][0] + 4293)' works fine, but that
`a[20][10][5]' produces the equivalent of `*(&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 `a', leaving `&a' set lower, in this case, than
`&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.


File: ^.!gcc.docs.fortran.g77,  Node: Procedures,  Next: Adjustable Arrays,  Prev: Arrays,  Up: Debugging and Interfacing

Procedures (SUBROUTINE and FUNCTION)
====================================

   Procedures that accept `CHARACTER' arguments are implemented by
`g77' so that each `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 `__g77_length_X', where X is the
user-specified name.  This argument is of the C type `ftnlen' (see
`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 `X' is not declared
`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 `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 `CHARACTER' argument is present in the argument
list, the length arguments are appended in the order the orginal
arguments appear.  So `CALL FOO('HI','THERE')' is implemented in C as
`foo("hi","there",2,5);', ignoring the fact that `g77' does not provide
the trailing null bytes on the constant strings (`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 `CHARACTER' variables and
arrays *only*.  It does *not* apply to external `CHARACTER' functions
or to intrinsic `CHARACTER' functions.  That is, no second length
argument is passed to `FOO' in this case:

     CHARACTER X
     EXTERNAL X
     CALL FOO(X)

Nor does `FOO' expect such an argument in this case:

     SUBROUTINE FOO(X)
     CHARACTER X
     EXTERNAL X

   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 `CHARACTER', subtle symptoms might
appear.


File: ^.!gcc.docs.fortran.g77,  Node: Adjustable Arrays,  Next: Alternate Returns,  Prev: Procedures,  Up: Debugging and Interfacing

Adjustable Arrays (DIMENSION)
=============================

   Adjustable and automatic arrays in Fortran require the implementation
(in this case, the `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:

     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

Here, the implementation should, when running the program, print
something like:

     20   2.  2.  2.  2.  2.

Note that this shows that while the value of `N' was successfully
changed, the size of the `A' array remained at 5 elements.

   To support this, `g77' generates code that executes before any user
code (and before the internally generated computed `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 `X' is first invoked, code is
executed that copies the value of `N' to a temporary.  And that same
temporary serves as the actual high bound for the single dimension of
the `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 `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 `NULL' pointer where a pointer to that adjustable array would be
expected.  The `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 `NULL' at run time in such cases.  (Don't depend on this
particular implementation by writing code that purposely passes `NULL'
pointers where the callee expects adjustable arrays, even if you know
the callee won't reference the arrays--nor should you pass `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 `g77' implements these things might change in
the future!)


File: ^.!gcc.docs.fortran.g77,  Node: Alternate Returns,  Next: Functions,  Prev: Adjustable Arrays,  Up: Debugging and Interfacing

Alternate Returns (SUBROUTINE and RETURN)
=========================================

   Subroutines with alternate returns (e.g. `SUBROUTINE X(*)' and `CALL
X(*50)') are implemented by `g77' as functions returning the C `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-`GOTO' statement, as in `GOTO
(50), X()' in the example above (where `X' is quietly declared as an
`INTEGER' function), and the callee just returns whatever integer is
specified in the `RETURN' statement for the subroutine For example,
`RETURN 1' is implemented as `X = 1' followed by `RETURN' in C, and
`RETURN' by itself is `X = 0' and `RETURN').


File: ^.!gcc.docs.fortran.g77,  Node: Functions,  Next: Common Blocks,  Prev: Alternate Returns,  Up: Debugging and Interfacing

Functions (FUNCTION and RETURN)
===============================

   `g77' handles in a special way functions that return the following
types:

   * `CHARACTER'

   * `COMPLEX' (and `DOUBLE COMPLEX')

   * `REAL'

   For `CHARACTER', `g77' implements a subroutine (a C function
returning `void') with two arguments prepended: `__g77_result', which
the caller passes as a pointer to a `char' array expected to hold the
return value, and `__g77_length', which the caller passes as an
`ftnlen' value specifying the length of the return value as declared in
the calling program.  For `CHARACTER'*(*), the called function uses
`__g77_length' to determine the size of the array that `__g77_result'
points to; otherwise, it ignores that argument.

   For `COMPLEX' and `DOUBLE COMPLEX', when `-ff2c' is in force, `g77'
implements a subroutine with one argument prepended: `__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 `-fno-f2c'
is in force, `g77' implements a `COMPLEX' function as `gcc''s
`__complex__ float' function, returning the result of the function in
the same way as `gcc' would, and implements a `DOUBLE COMPLEX' function
similarly.

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


File: ^.!gcc.docs.fortran.g77,  Node: Common Blocks,  Next: Local Equivalence Areas,  Prev: Functions,  Up: Debugging and Interfacing

Common Blocks (COMMON)
======================

   `g77' names and lays out `COMMON' areas the same way f2c does, for
compatibility with f2c.

   Currently, `g77' does not emit any debugging information for items
in a `COMMON' area, due to an apparent bug in the GBE.

   Moreover, `g77' currently implements a `COMMON' area such that its
type is an array of the C `char' data type.

   So, when debugging, you must know the offset into a `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 `char' type.

   For example, using default implicit typing, the statement

     COMMON I(15), R(20), T

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


File: ^.!gcc.docs.fortran.g77,  Node: Local Equivalence Areas,  Next: Alternate Entry Points,  Prev: Common Blocks,  Up: Debugging and Interfacing

Local Equivalence Areas (EQUIVALENCE)
=====================================

   `g77' treats storage-associated areas involving a `COMMON' block as
explained in the section on common blocks.

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

   Currently, `g77' does not emit any debugging information for items
in a local `EQUIVALENCE' area, due to an apparent bug in the GBE.

   Moreover, `g77' implements a local `EQUIVALENCE' area such that its
type is an array of the C `char' data type.

   The name `g77' gives this array of `char' type is `__g77_equiv_X',
where X is the name of the first item listed in the `EQUIVALENCE'
statements for that area that is placed at the beginning (offset 0) of
this array.

   When debugging, you must therefore access members of `EQUIVALENCE'
areas by specifying the appropriate `__g77_equiv_X' array section with
the appropriate offset.  See the explanation of debugging `COMMON'
blocks for info applicable to debugging local `EQUIVALENCE' areas.

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


File: ^.!gcc.docs.fortran.g77,  Node: Alternate Entry Points,  Next: Assigned Statement Labels,  Prev: Local Equivalence Areas,  Up: Debugging and Interfacing

Alternate Entry Points (ENTRY)
==============================

   The GBE does not understand the general concept of alternate entry
points as Fortran provides via the ENTRY statement.  `g77' gets around
this by using an approach to compiling procedures having at least one
`ENTRY' statement that is almost identical to the approach used by
`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 `g77' implements `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.

   `g77' compiles exactly one public procedure for the primary entry
point of a procedure plus each `ENTRY' point it specifies, as usual.
That is, in terms of the public interface, there is no difference
between

     SUBROUTINE X
     END
     SUBROUTINE Y
     END

and:

     SUBROUTINE X
     ENTRY Y
     END

   The difference between the above two cases lies in the code compiled
for the `X' and `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 `ENTRY' statement,
`g77' compiles an extra procedure named `__g77_masterfun_X', where X is
the name of the primary entry point (which, in the above case, using
the standard compiler options, would be `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 `g77'.  It
contains a single integer argument named `__g77_which_entrypoint',
passed by value (as in Fortran's `%VAL()' intrinsic), specifying the
entry point index--0 for the primary entry point, 1 for the first entry
point (the first `ENTRY' statement encountered), 2 for the second entry
point, and so on.

   It also contains, for functions returning `CHARACTER' and (when
`-ff2c' is in effect) `COMPLEX' functions, and for functions returning
different types among the `ENTRY' statements (e.g. `REAL FUNCTION R()'
containing `ENTRY I()'), an argument named `__g77_result' that is
expected at run time to contain a pointer to where to store the result
of the entry point.  For `CHARACTER' functions, this storage area is an
array of the appropriate number of characters; for `COMPLEX' functions,
it is the appropriate area for the return type (currently either
`COMPLEX' or `DOUBLE COMPLEX'); for multiple- return-type functions, it
is a union of all the supported return types (which cannot include
`CHARACTER', since combining `CHARACTER' and non-`CHARACTER' return
types via `ENTRY' in a single function is not supported by `g77').

   For `CHARACTER' functions, the `__g77_result' argument is followed
by yet another argument named `__g77_length' that, at run time,
specifies the caller's expected length of the returned value.  Note
that only `CHARACTER*(*)' functions and entry points actually make use
of this argument, even though it is always passed by all callers of
public `CHARACTER' functions (since the caller does not generally know
whether such a function is `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.
`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:

            GOTO (100000,100001,100002), __g77_which_entrypoint
     100000 ...code for primary entry point...
     100001 ...code immediately following first ENTRY statement...
     100002 ...code immediately following second ENTRY statement...

(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 `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 (`x' and `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
`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
`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 `X' or `Y') or on the private procedure that contains
most of the pertinent code (e.g. `__g77_masterfun_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.


File: ^.!gcc.docs.fortran.g77,  Node: Assigned Statement Labels,  Prev: Alternate Entry Points,  Up: Debugging and Interfacing

Assigned Statement Labels (ASSIGN and GOTO)
===========================================

   For portability to machines where a pointer (such as to a label,
which is how `g77' implements `ASSIGN' and its cousin, the assigned
`GOTO') is wider (bitwise) than an `INTEGER', `g77' does not
necessarily use the same memory location to hold the `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 `g77' implements

     I = 10

as, in C notation, `i = 10;', it might implement

     ASSIGN 10 TO I

as, in GNU's extended C notation (for the label syntax),
`__g77_ASSIGN_I = &&L10;' (where `L10' is just a massaging of the
Fortran label `10' to make the syntax C-like; `g77' doesn't actually
generate the name `L10' or any other name like that, since debuggers
cannot access labels anyway).

   While this currently means that an `ASSIGN' statement might not
overwrite the numeric contents of its target variable, *do not* write
any code depending on this feature.  `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 `g77' somewhat easier.  If there's
no debugger-visible variable named `__g77_ASSIGN_I' in a program unit
that does `ASSIGN 10 TO I', that probably means `g77' has decided it
can store the pointer to the label directly into `I' itself.

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


File: ^.!gcc.docs.fortran.g77,  Node: Collected Fortran Wisdom,  Next: Trouble,  Prev: Debugging and Interfacing,  Up: Top

Collected Fortran Wisdom
************************

   Most users of `g77' can be divided into two camps:

   * Those writing new Fortran code to be compiled by `g77'.

   * Those using `g77' to compile existing, "legacy" code.

   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 `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 `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 `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 `DO' loops surprise many people.
* Advantages Over f2c::        If `f2c' is so great, why `g77'?


File: ^.!gcc.docs.fortran.g77,  Node: Overly Convenient Options,  Next: Block Data and Libraries,  Up: Collected Fortran Wisdom

Overly Convenient Command-line Options
======================================

   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:

`-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 `DATA', so that `-finit-local-zero' is not
     needed.

     Consider using `-Wuninitialized' (which requires `-O') to find
     likely candidates, but do not specify `-finit-local-zero' or
     `-fno-automatic', or this technique won't work.

`-fno-automatic'
     (This option specifies that all local variables and arrays are to
     be treated as if they were named in `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 `SAVE' statements to
     some or all program unit sources, as appropriate.  Consider using
     `-Wuninitialized' (which requires `-O') to find likely candidates,
     but do not specify `-finit-local-zero' or `-fno-automatic', or
     this technique won't work.

     The default is `-fautomatic', which tells `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.

`-fugly'
     Fix the source code so that `-fno-ugly' will work.  Note that, for
     many programs, it is difficult to practically avoid using the
     features enabled via `-fugly-init', and these features pose the
     lowest risk of writing nonportable code, among the various "ugly"
     features.

`-fGROUP-intrinsics-hide'
     Change the source code to use `EXTERNAL' for any external procedure
     that might be the name of an intrinsic.  It is easy to find these
     using `-fGROUP-intrinsics-disable'.


File: ^.!gcc.docs.fortran.g77,  Node: Block Data and Libraries,  Next: Faster Programs,  Prev: Overly Convenient Options,  Up: Collected Fortran Wisdom

Block Data and Libraries
========================

   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
`BLOCK DATA FOO') and make sure there is an `EXTERNAL FOO' statement in
every program unit that uses any common block initialized by the
corresponding `BLOCK DATA'.  `g77' currently compiles a `BLOCK DATA' as
if it were a `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 `EXTERNAL FOO', where
`FOO' is not otherwise referenced in the same program unit, `g77'
assumes there exists a `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, `g77' outputs in the data section a static
pointer to the external name `FOO'.)

   The implementation `g77' currently uses to make this work is one of
the few things not compatible with `f2c' as currently shipped.  `f2c'
currently does nothing with `EXTERNAL FOO' except issue a warning that
`FOO' is not otherwise referenced, and for `BLOCK DATA FOO', f2c
doesn't generate a dummy procedure with the name `FOO'.  The upshot is
that you shouldn't mix `f2c' and `g77' in this particular case.  If you
use f2c to compile `BLOCK DATA FOO', then any `g77'-compiled program
unit that says `EXTERNAL FOO' will result in an unresolved reference
when linked.  If you do the opposite, then `FOO' might not be linked in
under various circumstances (such as when `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 `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 `EXTERNAL FOO' when `FOO' is a block data program
unit), and of the ones that might not link `BLOCK DATA FOO' under some
circumstances, most of them appear to do so once `EXTERNAL FOO' is
present in the appropriate program units.


File: ^.!gcc.docs.fortran.g77,  Node: Faster Programs,  Next: Working Programs,  Prev: Block Data and Libraries,  Up: Collected Fortran Wisdom

Faster Programs
===============

   Aside from the usual `gcc' options, such as `-O', `-ffast-math', and
so on, consider trying:

`-fno-f2c'
     Use this if you aren't linking with any code compiled using `f2c'.
     (Note that `libf2c' is *not* an example of code that is compiled
     using `f2c'--it is compiled by a C compiler, usually `gcc'.)

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

   Similarly, you should be able to use `-fno-init-local-zero' (the
default) instead of `-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, `-fno-automatic', which effectively `SAVE's every local
variable and array, affects even things like `DO' iteration variables,
which rarely need to be `SAVE'd, and this often reduces run-time
performances.  Similarly, `-fno-init-local-zero' forces such variables
to be initialized to zero--when `SAVE'd (such as when
`-fno-automatic'), this by itself generally affects only startup time
for a program, but when not `SAVE'd, it can slow down the procedure
every time it is called.

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


File: ^.!gcc.docs.fortran.g77,  Node: Working Programs,  Next: Loops,  Prev: Faster Programs,  Up: Collected Fortran Wisdom

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.

   `g77' offers some options that might be useful for tracking down
bugs in such programs.  *Note Option Summary::, for a summary of these
and other options, and cross-references for each such option to the
pertinent material in this manual.

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

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

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

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

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

`-Wsurprising'
     This can find bugs involving expression evaluation or in the way
     `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 `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 `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.

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


File: ^.!gcc.docs.fortran.g77,  Node: Loops,  Next: Advantages Over f2c,  Prev: Working Programs,  Up: Collected Fortran Wisdom

Loops
=====

   The meaning of a `DO' loop in Fortran is precisely specified in the
Fortran standard...and is quite different from what many programmers
might expect.

   In particular, Fortran `DO' loops are implemented as if the number
of trips through the loop is calculated *before* the loop is entered.

   The number of trips for a loop is calculated from the START, END,
and INCREMENT values specified in a statement such as:

     DO ITER = START, END, INCREMENT

   The trip count is evaluated using a fairly simple formula based on
the three values following the `=' 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 ITER are not related to determining whether to
terminate the loop.

   There are two important things to remember about the trip count:

   * It can be *negative*, in which case it is treated as if it was
     zero--meaning the loop is not executed at all.

   * The type used to *calculate* the trip count the same type as ITER,
     but the final calculation, and thus the type of the trip count
     itself, always is `INTEGER'.

   These two items mean that there are loops that cannot be written in
straightforward fashion using the Fortran `DO'.

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

     DO I = -2000000000, 2000000000

Although the START and END values are well within the range of
`INTEGER', the *trip count* is not.  The expected trip count is
40000000001, which is outside the range of `INTEGER' on many systems.

   Instead, the above loop should be constructed this way:

     I = -2000000000
     DO
       IF (I .GT. 2000000000) EXIT
       ...
       I = I + 1
     END DO

The simple `DO' construct and the `EXIT' statement (used to leave the
innermost loop) are F90 features that `g77' supports.

   Some Fortran compilers have buggy implementations of `DO', in that
they don't follow the standard.  They implement `DO' as a
straightforward translation to what, in C, would be a `for' statement.
Instead of creating a temporary variable to hold the trip count as
calculated at run time, these compilers use the iteration variable 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 ITER, but the magnitude of `ABS(END) +
ABS(INCR)' exceeds that range.  For example:

     DO I = 2147483600, 2147483647

A loop started by the above statement will work as implemented by
`g77', but the use, by some compilers, of a more C-like implementation
akin to

     for (i = 2147483600; i <= 2147483647; ++i)

produces a loop that does not terminate, because `i' can never be
greater than 2147483647, since incrementing it beyond that value
overflows `i', setting it to -2147483648.  This is a large, negative
number that still is less than 2147483647.

   Another example of unexpected behavior of `DO' involves using a
nonintegral iteration variable ITER, such as a `REAL' or `DOUBLE
PRECISION' variable.  Consider the following program:

           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

A C-like view of `DO' would hold that the two "exclamatory" `PRINT' are
never executed.  However, this is the output of running the above
program as compiled by `g77' on a Linux ix86 system:

      .100000001
      .107000001
      .114
      .120999999
      ...
      .289000005
      .296000004
      .303000003
     LAST =   .310000002
      .310000002 .LE.   .310000002!!

   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 `g77', in that it has 30 iterations.  This trip count of
30 is correct when evaluated using the floating-point representations
for the BEGIN, END, and 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, `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 `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
`DO' by standard-conforming compilers such as `g77', use of `DO' loops
with `REAL' or `DOUBLE PRECISION' iteration variables is not
recommended.  Such use can be caught by specifying `-Wsurprising'.
*Note Warning Options::, for more information on this option.


File: ^.!gcc.docs.fortran.g77,  Node: Advantages Over f2c,  Prev: Loops,  Up: Collected Fortran Wisdom

Advantages Over f2c
===================

   Without `f2c', `g77' would have taken much longer to do and probably
not been as good for quite a while.  Sometimes people who notice how
much `g77' depends on, and documents encouragement to use, `f2c' ask
why `g77' was created if `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.


File: ^.!gcc.docs.fortran.g77,  Node: Language Extensions,  Next: Compiler Options,  Up: Advantages Over f2c

Language Extensions
-------------------

   `g77' offers several extensions to the Fortran language that `f2c'
doesn't.

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


File: ^.!gcc.docs.fortran.g77,  Node: Compiler Options,  Next: Compiler Speed,  Prev: Language Extensions,  Up: Advantages Over f2c

Compiler Options
----------------

   `g77' offers a whole bunch of compiler options that `f2c' doesn't.

   However, `f2c' offers a few that `g77' doesn't, like an option to
generate code to check array subscripts at run time.  It is expected
that `g77' will offer some or all of these missing options at some time
in the future.


File: ^.!gcc.docs.fortran.g77,  Node: Compiler Speed,  Next: Program Speed,  Prev: Compiler Options,  Up: Advantages Over f2c

Compiler Speed
--------------

   Saving the steps of writing and then rereading C code is a big reason
why `g77' should be able to compile code much faster than using `f2c'
in conjunction with the equivalent invocation of `gcc'.

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


File: ^.!gcc.docs.fortran.g77,  Node: Program Speed,  Next: Ease of Debugging,  Prev: Compiler Speed,  Up: Advantages Over f2c

Program Speed
-------------

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

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

   It is hoped that version 0.5.18 of `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 `gcc' compilation
of `f2c' output, will improve the speed of programs compiled using that
method as well.


File: ^.!gcc.docs.fortran.g77,  Node: Ease of Debugging,  Next: Character and Hollerith Constants,  Prev: Program Speed,  Up: Advantages Over f2c

Ease of Debugging
-----------------

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

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

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

   Another example is that, given

     COMMON A, B
     EQUIVALENCE (B, C)

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

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

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

   In fairness, `g77' could do many of the things `f2c' does to get
things working at least as well as `f2c'--for now, the maintainers have
tended to prefer making `g77' work the way they think it is supposed
to, and find help improving the other products (the GBE of `gcc';
`gdb'; and so on) to get things working properly.


File: ^.!gcc.docs.fortran.g77,  Node: Character and Hollerith Constants,  Prev: Ease of Debugging,  Up: Advantages Over f2c

Character and Hollerith Constants
---------------------------------

   To avoid the extensive hassle that would be needed to avoid this,
`f2c' uses C character constants to encode character and Hollerith
constants.  That means a constant like `'HELLO'' is translated to
`"hello"' in C, which further means that an extra null byte is present
at the end of the constant.  This null byte is superfluous.

   `g77' does not generate such null bytes.  This represents significant
savings of resources, such as on systems where `/dev/null' or
`/dev/zero' represent bottlenecks in the systems' performance, because
`g77' simply asks for fewer zeros from the operating system than `f2c'.


File: ^.!gcc.docs.fortran.g77,  Node: Trouble,  Next: Open Questions,  Prev: Collected Fortran Wisdom,  Up: Top

Known Causes of Trouble with GNU Fortran
****************************************

   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 `g77' is not provided here.  *Note Problems Installing::.

   (Note that some of this portion of the manual is lifted directly
from the `gcc' manual, with minor modifications to tailor it to users
of `g77'.  Anytime a bug seems to have more to do with the `gcc'
portion of `g77', *Note Known Causes of Trouble with GNU CC:
(gcc)Trouble.)

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


File: ^.!gcc.docs.fortran.g77,  Node: But-bugs,  Next: Actual Bugs,  Up: Trouble

Bugs Not In GNU Fortran
=======================

   These are bugs to which the maintainers often have to reply, "but
that isn't a bug in `g77'...".  Some of these already are fixed in new
versions of other software; some still need to be fixed; some are
problems with how `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 `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 `g77' maintainers have their hands full working on
just fixing and improving `g77', without serving as a clearinghouse for
all bugs that happen to affect `g77' users.

   *Note Collected Fortran Wisdom::, for information on behavior of
Fortran programs, and the programs that compile them, that might be
*thought* to indicate bugs.

   * 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 `ld', fixed in more recent
     versions of `binutils', such as version 2.6.

   * There are some known problems when using `gdb' on code compiled by
     `g77'.  Inadequate investigation as of the release of 0.5.16
     results in not knowing which products are the culprit, but
     `gdb-4.14' definitely crashes when, for example, an attempt is
     made to print the contents of a `COMPLEX*16' dummy array, on at
     least some Linux machines, plus some others.

   * On some systems, perhaps just those with out-of-date (shared?)
     libraries, unresolved-reference errors happen when linking
     `g77'-compiled programs (which should be done using `g77').

     If this happens to you, try appending `-lc' to the command you use
     to link the program, e.g. `g77 foo.f -lc'.  `g77' already
     specifies `-lf2c -lm' when it calls the linker, but it cannot also
     specify `-lc' because not all systems have a file named `libc.a'.

     It is unclear at this point whether there are legitimately
     installed systems where `-lf2c -lm' is insufficient to resolve
     code produced by `g77'.

   * If your program doesn't link, due to unresolved references to names
     like `_main', make sure you're using the `g77' command to do the
     link, since this command ensures that the necessary libraries are
     loaded by specifying `-lf2c -lm' when it invokes the `gcc' command
     to do the actual link.  (Use the `-v' option to discover more
     about what actually happens when you use the `g77' and `gcc'
     commands.)

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

   * 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 (`/bin/ld') lays out data
     structures in virtual memory, it is very easy to create an
     executable wherein the `__DATA' segment overlaps (has addresses in
     common) with the `UNIX STACK' segment.

     This leads to all sorts of trouble, from the executable simply not
     executing, to bus errors.  The NeXTStep command line tool
     `ebadexec' points to the problem as follows:

          % `/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

     (In the above case, it is the `__LINKEDIT' segment that overlaps
     the stack segment.)

     This can be cured by assigning the `__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]:

          % `g77 -segaddr __DATA 6000000 test.f'
          % `ebadexec a.out'
          ebadexec: file: a.out appears to be executable
          %

     Browsing through `gcc/f/Makefile.in', you will find that the
     `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
     (`[e-mail]').)

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

     Some of these conversions are accepted by `g77' when the `-fugly'
     option is specified.


File: ^.!gcc.docs.fortran.g77,  Node: GPC Bugs

Known bugs and how to report bugs
*********************************

   If you encounter a bug with GPC, please check whether it is one of
the known bugs.  If not, report it to the GNU Pascal mailing list
`[e-mail]'.  (But always report it if you solve the problem! ;-)

Known bugs
==========

   The GPC compiler does not yet implement the whole ISO 7185 Pascal
standard, so please take this into account when you consider using this
for any purpose.

   See the file `version.c' to find out the version number of this GPC
(or run `gpc -v')

   Problems in this GPC version:

   * High optimization levels do not work properly on the Alpha.  Some
     conformance tests FAIL when compiled with -O6 flag, which means
     that the compiler generates invalid code. Don't use this flag in
     the alpha before the problem gets fixed.  It might have something
     to do with automatic inlining, but I have not yet looked at this.
     -O flag should be ok.  (Also take care when using explicit inline
     functions)

   * For some reason the pascal main program does not get lineno stabs
     -> It is hard to debug it with gdb...

   * The modules export everything, not just the stuff in the export
     interfaces. However, the unexported variables and functions are
     invisible to modules in other files.

   * type checking is mostly what C does, not what Pascal requires, so
     GPC does not yet implement a strongly typed language.  Although
     correct programs compile, incorrect ones compile also.

   * run time errors are not checked.

   * the inline set operations have some problems with operations on
     two sets if the sets do not contain equally many segments.

   * In addition, the set code generated in the alpha causes runtime
     runtime errors in the generated code.

   * Conformant arrays don't yet work (in general).  Until they do,
     this is a LEVEL-0 compiler.

Inconveniences
==============

   * NEW & DISPOSE optional tag field arguments are ignored (warning
     given, code works)

   * GDB does not yet understand pascal sets, files or subranges.  Now
     GDB allows you to debug these things, even though it does not yet
     understand some stabs.

   * PACKED does not pack. (implementation dependent, warning given,
     code works)

   * Files of integer subranges that would fit in a byte do not;
     instead they are handled as files of integer.  This is especially
     annoying with "file of 0..255".

Notes for debugging
===================

   * Forward referencing pointers generate DBX style debugging symbols
     by outputting the `.stabs' as an unknown pointer and later it just
     outputs the same `.stabs' again, but this time it also tells what
     type the pointer points to.  This seems to work for gdb. As of
     this writing I have not checked what happens with SDB type
     debugging info.  It might be that the pointer is left to be a
     `(void *)' pointer, so you have to cast it in order to output the
     object the pointer points to.

     Also, I have not tried any other debugger than gdb.  If you do,
     please let me know what happens.

     I think that GDB does not yet support the kind of `.stabs' that
     should be used to do this correctly:

            .stabs ":tANUMBER=BNUMBER", WHATEVER

     where ANUMBER is the unknown pointer type referenced earlier, and
     the BNUMBER is the type which ANUMBER actually is. This construct
     is not required in C.

   * When debugging, please note that the Initial Letter In Each
     Identifier Is In Upper Case And The Rest Are In Lower Case. If
     you wish to call C-routines declare them with the "C" directive,
     as follows:

          Procedure FooBAR(i:integer);c;

     This makes the external name to be `_foobar' (replace `_' with you
     machine prefix.)

          Procedure FooBAR(i:Integer); External;

     Uses external name `_Foobar'.

     It is done like this to reduce name clashes with `libc.a' and
     other possible libraries.

   * All visible GPC runtime system library routines are named `_p_...'.

   * However, the main program name is not capitalized.  (this is a
     kludge -> it may now clash with libc  identifiers. We'll change
     this somehow later)


File: ^.!gcc.docs.fortran.g77,  Node: Missing Features,  Next: Disappointments,  Prev: Actual Bugs,  Up: Trouble

Missing Features
================

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

   * `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 `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 `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.

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

   * `g77' doesn't support `INTEGER*2', `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.

   * `g77' rejects things other compilers accept, like `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 `g77' (though
     `-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 `INCLUDE' file that defines a common
     block, it might be appropriate to include a `SAVE' statement for
     the common block (such as `SAVE /CBLOCK/'), so that variables
     defined in the common block retain their values even when all
     procedures declaring the common block become inactive (return to
     their callers).

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

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

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

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

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

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

   * `g77' doesn't support pointers or allocatable objects.  This set
     of features is probably considered just behind `INTEGER*2' and
     intrinsics in `PARAMETER' statements on the list of large,
     important things to add to `g77'.

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

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

   * There is no support for keywords such as `DISP='DELETE'' in the
     `OPEN', `CLOSE', and `INQUIRE' statements.  These extensions are
     easy to add to `g77' itself, but require much more work on
     `libf2c'.

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

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

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

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

   * Provide some way, a la `gcc', for `g77' code to specify assembler
     code.

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

   * 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, `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.

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

   * A `FLUSH' statement that does what many systems provide via `CALL
     FLUSH', but that supports `*' as the unit designator (same unit as
     for `PRINT').

   * Finish support for old-style `PARAMETER' statement (like F77
     `PARAMETER', but type of destination is set from type of source
     expression).

   * Character-type selector/cases for `SELECT CASE'.

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

   * Add run-time bounds-checking of array/subscript references a la
     `f2c'.

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

   * Support the POSIX standard for Fortran.

   * 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:

          10    PRINT *,'HOW MANY
               1 SPACES?'

     `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 `MANY' and `SPACES?' in the output of the
     above statement.

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

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

   * Have `-Wunused' warn about unused labels.

   * Warn about assigned `GOTO'/`FORMAT' usage without any `ASSIGN' to
     variable.  (Actually, use of `-O -Wuninitialized' should take care
     of most of these.)

   * Add `-Wintrinsics' to warn about use of non-standard intrinsics
     without explicit `INTRINSIC' statements for them (to help find
     code that might fail silently when ported to another compiler).

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

   * Warn about modifying `DO' variables via `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.)

   * Add `-Wpromotions' to warn if source code appears to expect
     automatic, silent, and somewhat dangerous compiler-assisted
     conversion of `REAL' constants to `DOUBLE PRECISION' based on
     context.

     For example, warn about cases like this:

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

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

     For example:

          INTRINSIC ZABS
          CALL FOO(ZABS)
          END

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

   * If `-fno-ugly', reject badly designed trailing-radix quoted
     (typeless) numbers, such as `'123'O'.

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

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

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

   * 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, `g77' does complain about a variable that dimensions an
     array but doesn't appear in any dummy list or `COMMON' area, but
     this needs to be extended to catch cases where it doesn't appear in
     every dummy list that also lists any arrays it dimensions.

   * Make sure things like `RETURN 2HAB' are invalid in both source
     forms (must be `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.

   * The sort of routines usually found in the BSD-ish `libU77' should
     be provided in addition to the few utility routines in `libf2c'.
     Much of this work has already been done, and is awaiting
     integration into `g77'.


File: ^.!gcc.docs.fortran.g77,  Node: Disappointments,  Next: Non-bugs,  Prev: Missing Features,  Up: Trouble

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

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

   * `g77' disallows `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.

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

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

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

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Non-bugs,  Next: Warnings and Errors,  Prev: Disappointments,  Up: Trouble

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

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

   * `-fno-backslash' should be the default, not `-fbackslash'.

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

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

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

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

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

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

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

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

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

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

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

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

     This is why GNU Fortran does and will treat backslashes in the same
     fashion on all types of machines (by default).

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

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

          CHARACTER BACKSL
          PARAMETER (BACKSL = '\\')

     Then, use concatenation of `BACKSL' anyplace a backslash is
     desired.  (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.

   * `g77' does not use context to determine the types of constants or
     named constants (`PARAMETER').

     For example, consider the following statement:

          PRINT *, 3.1415926535 * 2D0

     `g77' will interpret the (truncated) constant `3.1415926535' as a
     `REAL', not `DOUBLE PRECISION', constant, because the suffix `D0'
     is not specified.

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

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

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

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

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

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

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

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

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

     For example, `CALL IFIX' is interpreted by `g77' first as a
     reference to the `IFIX' intrinsic, because the reference is a
     procedure invocation (as compared to `J=IFIX'); only after
     establishing that, in the program unit being compiled, `IFIX' is
     in fact an intrinsic and not a local name that happens to have the
     same name as an intrinsic, does `g77' recognize that the form of
     the reference is invalid for that particular intrinsic.  At that
     point, `g77' issues a diagnostic.

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

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

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

     Use the `EXTERNAL IFIX' statement in a program unit that calls a
     user-written subroutine named `IFIX'.

   * Allow `DATA VAR/.../' to come before `COMMON /.../ ...,VAR,...'.

     It is *possible* `g77' will someday allow this.

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

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

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

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

          J = IFUNC() - IFUNC()

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

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

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

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

        * Updating information in common blocks.

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


File: ^.!gcc.docs.fortran.g77,  Node: Warnings and Errors,  Prev: Non-bugs,  Up: Trouble

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

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

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

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

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Open Questions,  Next: Bugs,  Prev: Trouble,  Up: Top

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

   Please consider offering useful answers to these questions!

   * `g77' treats constants like `Z'ABCD'' and `'ABCD'Z' as typeless.
     It seems like maybe the prefix-letter form, `Z'ABCD'', should be
     `INTEGER' instead.

     You can test for yourself whether a particular compiler treats the
     prefix form as `INTEGER' or typeless by running the following
     program:

          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

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

     Perhaps this will be changed in version 0.6.

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


File: ^.!gcc.docs.fortran.g77,  Node: Bugs,  Next: Service,  Prev: Open Questions,  Up: Top

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

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

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

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

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

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

* Menu:

* Criteria:  Bug Criteria.   Have you really found a bug?
* Where: Bug Lists.         Where to send your bug report.
* Reporting: Bug Reporting.  How to report a bug effectively.
* Patches: Sending Patches.  How to send a patch for GNU Fortran.
* Known: Trouble.            Known problems.
* Help: Service.             Where to ask for help.


File: ^.!gcc.docs.fortran.g77,  Node: Bug Criteria,  Next: Bug Lists,  Up: Bugs

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

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

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

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

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

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

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

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

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

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

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Bug Lists,  Next: Bug Reporting,  Prev: Bug Criteria,  Up: Bugs

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

   Send bug reports for GNU Fortran to `[e-mail]'.

   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:

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


File: ^.!gcc.docs.fortran.g77,  Node: Bug Reporting,  Next: Sending Patches,  Prev: Bug Lists,  Up: Bugs

How to Report Bugs
==================

   The fundamental principle of reporting bugs usefully is this:
*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 `uuencode'.  If you do so it will slow down the processing of
your bug.  If you must submit multiple large files, use `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 `tar'
archive, and, whether you need to do that, it is acceptable to then
compress the single file (`tar' archive or source file) using `gzip'
and encode it via `uuencode'.  Do not use any MIME stuff--the current
maintainer can't decode this.  Using `compress' instead of `gzip' is
acceptable, assuming you have licensed the use of the patented
algorithm in `compress' from Unisys.)

   To enable someone to investigate the bug, you should include all
these things:

   * The version of GNU Fortran.  You can get this by running `g77'
     with the `-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.

   * A complete input file that will reproduce the bug.  If the bug is
     in the compiler proper (`f771') and you are using the C
     preprocessor, run your source file through the C preprocessor by
     doing `g77 -E SOURCEFILE > OUTFILE', then include the contents of
     OUTFILE in the bug report.  (When you do this, use the same `-I',
     `-D' or `-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.

   * Note that you should include with your bug report any files
     included by the source file (via the `INCLUDE' statement) that you
     send, and any files they `INCLUDE', and so on.

     It is not necessary to replace the `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 *reproduce* the bug using the *exact* version
     of the source material you submit, to avoid wild-goose chases.

   * The command arguments you gave GNU Fortran to compile that example
     and observe the bug.  For example, did you use `-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.

   * The type of machine you are using, and the operating system name
     and version number.  (Much of this information is printed by `g77
     -v'--if you include that, send along any additional info you have
     that you don't see clearly represented in that output.)

   * The operands you gave to the `configure' command when you installed
     the compiler.

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

   * Details of any other deviations from the standard procedure for
     installing GNU Fortran.

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

   * If you send examples of assembler code output from GNU Fortran,
     please use `-g' when you make them.  The debugging information
     includes source line numbers which are essential for correlating
     the output with the input.

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

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

     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.

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

   Here are some things that are not necessary:

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

   * In particular, some people insert conditionals `#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.

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

     *Note Sending Patches::, for guidelines on how to make it easy for
     us to understand and install your patches.

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

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


File: ^.!gcc.docs.fortran.g77,  Node: Sending Patches,  Prev: Bug Reporting,  Up: Bugs

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, `[e-mail]'.

   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.

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

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

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

   * Don't mix together changes made for different reasons.  Send them
     *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.

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

   * Use `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 `-c' format.

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

   * 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 `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.

   * 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 `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 *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.


File: ^.!gcc.docs.fortran.g77,  Node: Service,  Next: Index,  Prev: Bugs,  Up: Top

How To Get Help with GNU Fortran
********************************

   If you need help installing, using or changing GNU Fortran, there
are two ways to find it:

   * Look in the service directory for someone who might help you for a
     fee.  The service directory is found in the file named `SERVICE'
     in the GNU CC distribution.

   * Send a message to `[e-mail]'.


File: ^.!gcc.docs.fortran.g77,  Node: Index,  Prev: Service,  Up: Top

Index
*****

* Menu:

* #define:                              Overall Options.
* #if:                                  Overall Options.
* #include:                             Overall Options.
* %DESCR() intrinsic <1>:               Changes.
* %DESCR() intrinsic:                   Extensions.
* %LOC() intrinsic:                     Extensions.
* %REF() intrinsic:                     Extensions.
* %VAL() intrinsic:                     Extensions.
* *N notation:                          Types.
* --driver option <1>:                  G77 and GCC.
* --driver option:                      Invoking G77.
* -fGROUP-intrinsics-hide option:       Overly Convenient Options.
* -fcaller-saves option:                Optimize Options.
* -fcase-initcap option:                Fortran Dialect Options.
* -fcase-lower option:                  Fortran Dialect Options.
* -fcase-preserve option:               Fortran Dialect Options.
* -fcase-strict-lower option:           Fortran Dialect Options.
* -fcase-strict-upper option:           Fortran Dialect Options.
* -fcase-upper option:                  Fortran Dialect Options.
* -fdcp-intrinsics-delete option:       Fortran Dialect Options.
* -fdcp-intrinsics-disable option:      Fortran Dialect Options.
* -fdcp-intrinsics-enable option:       Fortran Dialect Options.
* -fdcp-intrinsics-hide option:         Fortran Dialect Options.
* -fdelayed-branch option:              Optimize Options.
* -fdollar-ok option:                   Fortran Dialect Options.
* -fexpensive-optimizations option:     Optimize Options.
* -ff2c-intrinsics-delete option:       Fortran Dialect Options.
* -ff2c-intrinsics-disable option:      Fortran Dialect Options.
* -ff2c-intrinsics-enable option:       Fortran Dialect Options.
* -ff2c-intrinsics-hide option:         Fortran Dialect Options.
* -ff2c-library option:                 Code Gen Options.
* -ff90 option:                         Fortran Dialect Options.
* -ff90-intrinsics-delete option:       Fortran Dialect Options.
* -ff90-intrinsics-disable option:      Fortran Dialect Options.
* -ff90-intrinsics-enable option:       Fortran Dialect Options.
* -ff90-intrinsics-hide option:         Fortran Dialect Options.
* -ff90-not-vxt option:                 Fortran Dialect Options.
* -ffast-math option:                   Optimize Options.
* -ffixed-line-length-N option:         Fortran Dialect Options.
* -ffloat-store option:                 Optimize Options.
* -fforce-addr option:                  Optimize Options.
* -fforce-mem option:                   Optimize Options.
* -ffree-form option:                   Fortran Dialect Options.
* -finit-local-zero option <1>:         Overly Convenient Options.
* -finit-local-zero option:             Code Gen Options.
* -fintrin-case-any option:             Fortran Dialect Options.
* -fintrin-case-initcap option:         Fortran Dialect Options.
* -fintrin-case-lower option:           Fortran Dialect Options.
* -fintrin-case-upper option:           Fortran Dialect Options.
* -fmatch-case-any option:              Fortran Dialect Options.
* -fmatch-case-initcap option:          Fortran Dialect Options.
* -fmatch-case-lower option:            Fortran Dialect Options.
* -fmatch-case-upper option:            Fortran Dialect Options.
* -fmil-intrinsics-delete option:       Fortran Dialect Options.
* -fmil-intrinsics-disable option:      Fortran Dialect Options.
* -fmil-intrinsics-enable option:       Fortran Dialect Options.
* -fmil-intrinsics-hide option:         Fortran Dialect Options.
* -fno-automatic option <1>:            Overly Convenient Options.
* -fno-automatic option:                Code Gen Options.
* -fno-backslash option:                Fortran Dialect Options.
* -fno-common option:                   Code Gen Options.
* -fno-f2c option <1>:                  Faster Programs.
* -fno-f2c option:                      Code Gen Options.
* -fno-fixed-form option:               Fortran Dialect Options.
* -fno-ident option:                    Code Gen Options.
* -fno-inline option:                   Optimize Options.
* -fno-second-underscore option:        Code Gen Options.
* -fno-ugly-args option:                Warning Options.
* -fno-ugly-init option:                Warning Options.
* -fno-underscoring option:             Code Gen Options.
* -fpack-struct option:                 Code Gen Options.
* -fpcc-struct-return option:           Code Gen Options.
* -fpedantic option:                    Warning Options.
* -freg-struct-return option:           Code Gen Options.
* -frerun-cse-after-loop option:        Optimize Options.
* -fschedule-insns option:              Optimize Options.
* -fschedule-insns2 option:             Optimize Options.
* -fset-g77-defaults option:            Overall Options.
* -fshort-double option:                Code Gen Options.
* -fsource-case-lower option:           Fortran Dialect Options.
* -fsource-case-preserve option:        Fortran Dialect Options.
* -fsource-case-upper option:           Fortran Dialect Options.
* -fstrength-reduce option:             Optimize Options.
* -fsymbol-case-any option:             Fortran Dialect Options.
* -fsymbol-case-initcap option:         Fortran Dialect Options.
* -fsymbol-case-lower option:           Fortran Dialect Options.
* -fsymbol-case-upper option:           Fortran Dialect Options.
* -fsyntax-only option:                 Warning Options.
* -fugly option <1>:                    Overly Convenient Options.
* -fugly option:                        Warning Options.
* -funix-intrinsics-delete option:      Fortran Dialect Options.
* -funix-intrinsics-disable option:     Fortran Dialect Options.
* -funix-intrinsics-enable option:      Fortran Dialect Options.
* -funix-intrinsics-hide option:        Fortran Dialect Options.
* -funroll-all-loops option:            Optimize Options.
* -funroll-loops option:                Optimize Options.
* -fversion option:                     Overall Options.
* -fvxt-intrinsics-delete option:       Fortran Dialect Options.
* -fvxt-intrinsics-disable option:      Fortran Dialect Options.
* -fvxt-intrinsics-enable option:       Fortran Dialect Options.
* -fvxt-intrinsics-hide option:         Fortran Dialect Options.
* -fvxt-not-f90 option:                 Fortran Dialect Options.
* -fzeros option:                       Code Gen Options.
* -g option:                            Debugging Options.
* -I- option:                           Directory Options.
* -Idir option:                         Directory Options.
* -pedantic option:                     Warning Options.
* -pedantic-errors option:              Warning Options.
* -u option:                            Warning Options.
* -v option:                            G77 and GCC.
* -w option:                            Warning Options.
* -Waggregate-return option:            Warning Options.
* -Wall option:                         Warning Options.
* -Wcomment option:                     Warning Options.
* -Wconversion option:                  Warning Options.
* -Werror option:                       Warning Options.
* -Wformat option:                      Warning Options.
* -Wid-clash-LEN option:                Warning Options.
* -Wimplicit option:                    Warning Options.
* -Wlarger-than-LEN option:             Warning Options.
* -Wparentheses option:                 Warning Options.
* -Wredundant-decls option:             Warning Options.
* -Wshadow option:                      Warning Options.
* -Wsurprising option:                  Warning Options.
* -Wswitch option:                      Warning Options.
* -Wtraditional option:                 Warning Options.
* -Wuninitialized option:               Warning Options.
* -Wunused option:                      Warning Options.
* .F:                                   Overall Options.
* .fpp:                                 Overall Options.
* /WARNINGS=DECLARATIONS switch:        Warning Options.
* 64-bit systems:                       Alpha Problems.
* bison:                                Missing bison?.
* g77, installation of:                 Installation of Binaries.
* gcc versions supported by g77:        Merging Distributions.
* gcc, installation of:                 Installation of Binaries.
* gdb support:                          But-bugs.
* makeinfo:                             Missing makeinfo?.
* ABORT() intrinsic:                    Fortran Dialect Options.
* ACCEPT statement:                     Missing Features.
* adjustable arrays:                    Adjustable Arrays.
* aggregate initialization:             Large Initialization.
* all warnings:                         Warning Options.
* Alpha, bugs:                          Alpha Problems.
* alternate entry points:               Alternate Entry Points.
* alternate returns:                    Alternate Returns.
* AND intrinsic:                        Missing Features.
* ANSI FORTRAN 77 support:              Standard Support.
* arguments, unused:                    Warning Options.
* array ordering:                       Arrays.
* arrays:                               Arrays.
* arrays, adjustable:                   Adjustable Arrays.
* arrays, automatic:                    Adjustable Arrays.
* arrays, dimensioning:                 Adjustable Arrays.
* as command:                           What is GNU Fortran?.
* assembler:                            What is GNU Fortran?.
* assembly code:                        What is GNU Fortran?.
* assembly code, invalid:               Bug Criteria.
* ASSIGN statement:                     Assigned Statement Labels.
* assigned statement labels:            Assigned Statement Labels.
* automatic arrays:                     Adjustable Arrays.
* back end, gcc:                        What is GNU Fortran?.
* backslash <1>:                        Fortran Dialect Options.
* backslash:                            Non-bugs.
* backtrace for bug reports:            Bug Reporting.
* basic concepts:                       What is GNU Fortran?.
* beginners:                            Getting Started.
* binaries, distributing:               Distributing Binaries.
* bit patterns:                         Floating-point Bit Patterns.
* block data:                           Disappointments.
* block data and libraries:             Block Data and Libraries.
* BLOCK DATA statement <1>:             Block Data and Libraries.
* BLOCK DATA statement:                 Disappointments.
* bootstrap build:                      Bootstrap Build.
* bug criteria:                         Bug Criteria.
* bug report mailing lists:             Bug Lists.
* bugs <1>:                             What is GNU Fortran?.
* bugs:                                 Bugs.
* bugs, known:                          Trouble.
* build, bootstrap:                     Bootstrap Build.
* build, straight:                      Straight Build.
* building g77:                         Building gcc.
* building gcc:                         Building gcc.
* but-bugs:                             But-bugs.
* C preprocessor:                       Overall Options.
* C routines calling Fortran:           Debugging and Interfacing.
* calling C routines:                   Debugging and Interfacing.
* card image:                           Fortran Dialect Options.
* carriage returns:                     Source Form.
* case sensitivity:                     Case Sensitivity.
* cc1 program:                          What is GNU Fortran?.
* cc1plus program:                      What is GNU Fortran?.
* changes, user-visible:                Changes.
* character constants <1>:              Fortran Dialect Options.
* character constants <1>:              Distensions.
* character constants <1>:              Dialects.
* character constants:                  Character and Hollerith Constants.
* character set:                        Fortran Dialect Options.
* characters, comment:                  Dialects.
* characters, continuation:             Dialects.
* CLOSE statement:                      Missing Features.
* code generation conventions:          Code Gen Options.
* code generator:                       What is GNU Fortran?.
* code, assembly:                       What is GNU Fortran?.
* code, distributing:                   Distributing Binaries.
* code, in-line:                        What is GNU Fortran?.
* code, legacy:                         Collected Fortran Wisdom.
* code, machine:                        What is GNU Fortran?.
* code, modifying:                      Unpacking.
* code, object:                         Object Compatibility.
* code, source <1>:                     What is GNU Fortran?.
* code, source <1>:                     Case Sensitivity.
* code, source <1>:                     Unpacking.
* code, source:                         Source Form.
* code, stack variables:                Maximum Stackable Size.
* code, user:                           But-bugs.
* code, writing:                        Collected Fortran Wisdom.
* column-major ordering:                Arrays.
* command options:                      Invoking G77.
* commands, as:                         What is GNU Fortran?.
* commands, f77:                        Installing f77.
* commands, g77 <1>:                    G77 and GCC.
* commands, g77:                        What is GNU Fortran?.
* commands, gcc <1>:                    G77 and GCC.
* commands, gcc:                        What is GNU Fortran?.
* commands, gdb:                        What is GNU Fortran?.
* commands, ld:                         What is GNU Fortran?.
* comment character:                    Dialects.
* COMMON blocks:                        Debugging Options.
* common blocks:                        Common Blocks.
* common blocks, large:                 But-bugs.
* COMMON statement <1>:                 Common Blocks.
* COMMON statement:                     Disappointments.
* compatibility <1>:                    Object Compatibility.
* compatibility <1>:                    Block Data and Libraries.
* compatibility:                        Faster Programs.
* compatibility, f2c:                   Code Gen Options.
* compilation, in-line:                 Optimize Options.
* compilation, pedantic:                Pedantic Compilation.
* compiler bugs, reporting:             Bug Reporting.
* compilers:                            What is GNU Fortran?.
* compilers, compatibility:             Object Compatibility.
* compiling programs:                   G77 and GCC.
* COMPLEX intrinsics:                   Fortran Dialect Options.
* COMPLEX type:                         Types.
* components of g77:                    What is GNU Fortran?.
* concepts, basic:                      What is GNU Fortran?.
* conformance, IEEE:                    Optimize Options.
* constants:                            Constants.
* constants, character <1>:             Dialects.
* constants, character <1>:             Distensions.
* constants, character:                 Character and Hollerith Constants.
* constants, Hollerith <1>:             Distensions.
* constants, Hollerith <1>:             Character and Hollerith Constants.
* constants, Hollerith:                 Changes.
* constants, octal:                     Dialects.
* constants, typeless:                  Changes.
* continuation character:               Dialects.
* contributors:                         Contributors.
* core dump:                            Bug Criteria.
* cpp preprocessor:                     Overall Options.
* cpp program <1>:                      Bug Reporting.
* cpp program <1>:                      Preprocessor Options.
* cpp program <1>:                      What is GNU Fortran?.
* cpp program:                          Overall Options.
* Cray pointers:                        Missing Features.
* creating patch files:                 Merging Distributions.
* credits:                              Contributors.
* cross-compilation:                    Cross-compiler Problems.
* cross-compiler, building:             Floating-point Bit Patterns.
* DATA statement:                       Code Gen Options.
* data types:                           Types.
* debugger:                             What is GNU Fortran?.
* debugging <1>:                        Main Program Unit.
* debugging:                            Debugging and Interfacing.
* debugging information options:        Debugging Options.
* debug_rtx:                            Bug Reporting.
* deleted intrinsics:                   Intrinsics.
* diagnostics, incorrect:               What is GNU Fortran?.
* dialect options:                      Fortran Dialect Options.
* dialects of language:                 Dialects.
* Digital Fortran features:             Fortran Dialect Options.
* DIMENSION statement <1>:              Adjustable Arrays.
* DIMENSION statement:                  Arrays.
* dimensioning arrays:                  Adjustable Arrays.
* directory options:                    Directory Options.
* directory search paths for inclusion: Directory Options.
* directory, updating info:             Updating Documentation.
* disabled intrinsics:                  Intrinsics.
* disposition of files:                 Missing Features.
* distensions:                          Distensions.
* distributions, unpacking:             Unpacking.
* distributions, why separate:          Merging Distributions.
* DO statement <1>:                     Loops.
* DO statement:                         Warning Options.
* documentation:                        Updating Documentation.
* dollar sign:                          Fortran Dialect Options.
* DOUBLE COMPLEX type:                  Types.
* DOUBLE PRECISION type:                Types.
* double quotes:                        Dialects.
* driver, gcc command as:               What is GNU Fortran?.
* dummies, unused:                      Warning Options.
* effecting IMPLICIT NONE:              Warning Options.
* enabled intrinsics:                   Intrinsics.
* entry points:                         Alternate Entry Points.
* ENTRY statement:                      Alternate Entry Points.
* environment variables:                Environment Variables.
* EQUIVALENCE areas:                    Debugging Options.
* equivalence areas:                    Local Equivalence Areas.
* EQUIVALENCE statement:                Local Equivalence Areas.
* error messages:                       Warnings and Errors.
* error messages, incorrect:            What is GNU Fortran?.
* errors, linker:                       But-bugs.
* exclamation points:                   Dialects.
* executable file:                      What is GNU Fortran?.
* EXIT() intrinsic:                     Fortran Dialect Options.
* extended-source option:               Fortran Dialect Options.
* extensions:                           Extensions.
* extensions, file name:                Overall Options.
* extensions, VXT:                      Dialects.
* extra warnings:                       Warning Options.
* f2c compatibility <1>:                Debugging and Interfacing.
* f2c compatibility <1>:                Code Gen Options.
* f2c compatibility <1>:                Block Data and Libraries.
* f2c compatibility <1>:                Faster Programs.
* f2c compatibility:                    Object Compatibility.
* f2c intrinsics:                       Fortran Dialect Options.
* F2CLIBOK:                             Installing f2c.
* F2C_INSTALL_FLAG:                     Installing f2c.
* f77 command:                          Installing f77.
* f77 support:                          Non-bugs.
* f771 program:                         What is GNU Fortran?.
* f771, linking error for:              General Problems.
* F77_INSTALL_FLAG:                     Installing f77.
* fatal signal:                         Bug Criteria.
* features, ugly <1>:                   Distensions.
* features, ugly:                       Warning Options.
* FFE:                                  What is GNU Fortran?.
* FFECOM_sizeMAXSTACKITEM:              Maximum Stackable Size.
* file format not recognized:           What is GNU Fortran?.
* file name extension:                  Overall Options.
* file name suffix:                     Overall Options.
* file type:                            Overall Options.
* file, source:                         What is GNU Fortran?.
* files, executable:                    What is GNU Fortran?.
* files, source:                        Source Form.
* fixed form <1>:                       Source Form.
* fixed form:                           Fortran Dialect Options.
* fixed-form line length:               Fortran Dialect Options.
* floating-point bit patterns:          Floating-point Bit Patterns.
* FLUSH() intrinsic:                    Fortran Dialect Options.
* FORMAT statement:                     Missing Features.
* Fortran 90 features <1>:              Fortran Dialect Options.
* Fortran 90 features <1>:              Dialects.
* Fortran 90 features:                  Fortran Dialect Options.
* Fortran 90 intrinsics:                Fortran Dialect Options.
* Fortran 90 support:                   Missing Features.
* Fortran preprocessor:                 Overall Options.
* free form <1>:                        Fortran Dialect Options.
* free form:                            Source Form.
* front end, g77:                       What is GNU Fortran?.
* FSF, funding the:                     Funding GNU Fortran.
* FUNCTION statement <1>:               Functions.
* FUNCTION statement:                   Procedures.
* functions:                            Functions.
* functions, intrinsic:                 Fortran Dialect Options.
* funding improvements:                 Funding GNU Fortran.
* funding the FSF:                      Funding GNU Fortran.
* g77 command <1>:                      What is GNU Fortran?.
* g77 command:                          G77 and GCC.
* g77 front end:                        What is GNU Fortran?.
* g77 options, -driver:                 G77 and GCC.
* g77 options, -v:                      G77 and GCC.
* g77 options, driver:                  Invoking G77.
* g77, components of:                   What is GNU Fortran?.
* GBE <1>:                              What is GNU Fortran?.
* GBE:                                  General Problems.
* gcc back end:                         What is GNU Fortran?.
* gcc command <1>:                      G77 and GCC.
* gcc command:                          What is GNU Fortran?.
* gcc command as driver:                What is GNU Fortran?.
* gcc not recognizing Fortran source:   What is GNU Fortran?.
* gdb command:                          What is GNU Fortran?.
* GETARG() intrinsic:                   Main Program Unit.
* getting started:                      Getting Started.
* GNU Back End (GBE):                   What is GNU Fortran?.
* GNU C required:                       General Problems.
* GNU Fortran command options:          Invoking G77.
* GNU Fortran Front End (FFE):          What is GNU Fortran?.
* GOTO statement:                       Assigned Statement Labels.
* groups of intrinsics:                 Intrinsics.
* hidden intrinsics:                    Intrinsics.
* Hollerith constants <1>:              Character and Hollerith Constants.
* Hollerith constants <1>:              Fortran Dialect Options.
* Hollerith constants <1>:              Distensions.
* Hollerith constants <1>:              Changes.
* Hollerith constants:                  Distensions.
* IARGC() intrinsic:                    Main Program Unit.
* IEEE conformance:                     Optimize Options.
* IMPLICIT CHARACTER*(*) statement:     Disappointments.
* implicit declaration, warning:        Warning Options.
* IMPLICIT NONE, similar effect:        Warning Options.
* improvements, funding:                Funding GNU Fortran.
* in-line code:                         What is GNU Fortran?.
* in-line compilation:                  Optimize Options.
* INCLUDE statement <1>:                Preprocessor Options.
* INCLUDE statement <1>:                Bug Reporting.
* INCLUDE statement:                    Directory Options.
* included files:                       Bug Reporting.
* inclusion, directory search paths for: Directory Options.
* incorrect diagnostics:                What is GNU Fortran?.
* incorrect error messages:             What is GNU Fortran?.
* incorrect use of language:            What is GNU Fortran?.
* info, updating directory:             Updating Documentation.
* initialization of local variables:    Code Gen Options.
* INQUIRE statement:                    Missing Features.
* installation of binaries:             Installation of Binaries.
* installation problems:                Problems Installing.
* installation trouble:                 Trouble.
* installing GNU Fortran:               Installation.
* installing, checking before:          Pre-installation Checks.
* INTEGER type:                         Types.
* INTEGER*2 support:                    Missing Features.
* interfacing:                          Debugging and Interfacing.
* intrinsic functions:                  Fortran Dialect Options.
* intrinsic subroutines:                Fortran Dialect Options.
* intrinsics, %DESCR() <1>:             Extensions.
* intrinsics, %DESCR():                 Changes.
* intrinsics, %LOC():                   Extensions.
* intrinsics, %REF():                   Extensions.
* intrinsics, %VAL():                   Extensions.
* intrinsics, ABORT():                  Fortran Dialect Options.
* intrinsics, AND:                      Missing Features.
* intrinsics, COMPLEX:                  Fortran Dialect Options.
* intrinsics, deleted:                  Intrinsics.
* intrinsics, disabled:                 Intrinsics.
* intrinsics, enabled:                  Intrinsics.
* intrinsics, EXIT():                   Fortran Dialect Options.
* intrinsics, f2c:                      Fortran Dialect Options.
* intrinsics, FLUSH():                  Fortran Dialect Options.
* intrinsics, Fortran 90:               Fortran Dialect Options.
* intrinsics, GETARG():                 Main Program Unit.
* intrinsics, groups:                   Intrinsics.
* intrinsics, groups of:                Intrinsics.
* intrinsics, hidden:                   Intrinsics.
* intrinsics, IARGC():                  Main Program Unit.
* intrinsics, LOC():                    Extensions.
* intrinsics, MIL-STD 1753:             Fortran Dialect Options.
* intrinsics, OR:                       Missing Features.
* intrinsics, SHIFT:                    Missing Features.
* intrinsics, side effects of:          Fortran Dialect Options.
* intrinsics, SIGNAL():                 Fortran Dialect Options.
* intrinsics, SYSTEM():                 Fortran Dialect Options.
* intrinsics, UNIX:                     Fortran Dialect Options.
* intrinsics, VXT:                      Fortran Dialect Options.
* Introduction:                         Top.
* invalid assembly code:                Bug Criteria.
* invalid input:                        Bug Criteria.
* KIND= notation:                       Types.
* known causes of trouble:              Trouble.
* language dialect options:             Fortran Dialect Options.
* language dialects:                    Dialects.
* language extensions:                  Extensions.
* language, incorrect use of:           What is GNU Fortran?.
* LANGUAGES:                            Building gcc.
* large common blocks:                  But-bugs.
* large initialization:                 Large Initialization.
* ld can't find strange names:          But-bugs.
* ld can't find _main:                  But-bugs.
* ld can't find _strtoul:               General Problems.
* ld command:                           What is GNU Fortran?.
* ld error for f771:                    General Problems.
* ld error for user code:               But-bugs.
* ld errors:                            But-bugs.
* legacy code:                          Collected Fortran Wisdom.
* length of source lines:               Fortran Dialect Options.
* letters, lowercase:                   Case Sensitivity.
* letters, uppercase:                   Case Sensitivity.
* libf2c library:                       What is GNU Fortran?.
* libraries:                            What is GNU Fortran?.
* libraries, containing BLOCK DATA:     Block Data and Libraries.
* libraries, libf2c:                    What is GNU Fortran?.
* line length:                          Fortran Dialect Options.
* linker errors:                        But-bugs.
* linking:                              What is GNU Fortran?.
* linking error for f771:               General Problems.
* linking error for user code:          But-bugs.
* LOC() intrinsic:                      Extensions.
* local equivalence areas:              Local Equivalence Areas.
* LOGICAL type:                         Types.
* LOGICAL*1 support:                    Missing Features.
* loops, speeding up:                   Optimize Options.
* loops, unrolling:                     Optimize Options.
* lowercase letters:                    Case Sensitivity.
* machine code:                         What is GNU Fortran?.
* main program unit, debugging:         Main Program Unit.
* main():                               Main Program Unit.
* MAIN__():                             Main Program Unit.
* MAP statement:                        Missing Features.
* maximum stackable size:               Maximum Stackable Size.
* memory utilization:                   Large Initialization.
* merging distributions:                Merging Distributions.
* messages, warning:                    Warning Options.
* messages, warning and error:          Warnings and Errors.
* MIL-STD 1753:                         Fortran Dialect Options.
* missing bison:                        Missing bison?.
* missing makeinfo:                     Missing makeinfo?.
* missing debug features:               Debugging Options.
* mistakes:                             What is GNU Fortran?.
* modifying g77:                        Unpacking.
* NAMELIST statement:                   Extensions.
* naming conflicts:                     Disappointments.
* native compiler:                      Installing f77.
* negative forms of options:            Invoking G77.
* new users:                            Getting Started.
* newbies:                              Getting Started.
* null byte, trailing:                  Character and Hollerith Constants.
* number of trips:                      Loops.
* object code:                          Object Compatibility.
* octal constants:                      Dialects.
* OPEN statement:                       Missing Features.
* optimizations, Pentium:               Unpacking.
* optimize options:                     Optimize Options.
* options to control warnings:          Warning Options.
* options, -driver <1>:                 G77 and GCC.
* options, -driver:                     Invoking G77.
* options, -fGROUP-intrinsics-hide:     Overly Convenient Options.
* options, -fcaller-saves:              Optimize Options.
* options, -fcase-initcap:              Fortran Dialect Options.
* options, -fcase-lower:                Fortran Dialect Options.
* options, -fcase-preserve:             Fortran Dialect Options.
* options, -fcase-strict-lower:         Fortran Dialect Options.
* options, -fcase-strict-upper:         Fortran Dialect Options.
* options, -fcase-upper:                Fortran Dialect Options.
* options, -fdcp-intrinsics-delete:     Fortran Dialect Options.
* options, -fdcp-intrinsics-disable:    Fortran Dialect Options.
* options, -fdcp-intrinsics-enable:     Fortran Dialect Options.
* options, -fdcp-intrinsics-hide:       Fortran Dialect Options.
* options, -fdelayed-branch:            Optimize Options.
* options, -fdollar-ok:                 Fortran Dialect Options.
* options, -fexpensive-optimizations:   Optimize Options.
* options, -ff2c-intrinsics-delete:     Fortran Dialect Options.
* options, -ff2c-intrinsics-disable:    Fortran Dialect Options.
* options, -ff2c-intrinsics-enable:     Fortran Dialect Options.
* options, -ff2c-intrinsics-hide:       Fortran Dialect Options.
* options, -ff2c-library:               Code Gen Options.
* options, -ff90:                       Fortran Dialect Options.
* options, -ff90-intrinsics-delete:     Fortran Dialect Options.
* options, -ff90-intrinsics-disable:    Fortran Dialect Options.
* options, -ff90-intrinsics-enable:     Fortran Dialect Options.
* options, -ff90-intrinsics-hide:       Fortran Dialect Options.
* options, -ff90-not-vxt:               Fortran Dialect Options.
* options, -ffast-math:                 Optimize Options.
* options, -ffixed-line-length-N:       Fortran Dialect Options.
* options, -ffloat-store:               Optimize Options.
* options, -fforce-addr:                Optimize Options.
* options, -fforce-mem:                 Optimize Options.
* options, -ffree-form:                 Fortran Dialect Options.
* options, -finit-local-zero <1>:       Overly Convenient Options.
* options, -finit-local-zero:           Code Gen Options.
* options, -fintrin-case-any:           Fortran Dialect Options.
* options, -fintrin-case-initcap:       Fortran Dialect Options.
* options, -fintrin-case-lower:         Fortran Dialect Options.
* options, -fintrin-case-upper:         Fortran Dialect Options.
* options, -fmatch-case-any:            Fortran Dialect Options.
* options, -fmatch-case-initcap:        Fortran Dialect Options.
* options, -fmatch-case-lower:          Fortran Dialect Options.
* options, -fmatch-case-upper:          Fortran Dialect Options.
* options, -fmil-intrinsics-delete:     Fortran Dialect Options.
* options, -fmil-intrinsics-disable:    Fortran Dialect Options.
* options, -fmil-intrinsics-enable:     Fortran Dialect Options.
* options, -fmil-intrinsics-hide:       Fortran Dialect Options.
* options, -fno-automatic <1>:          Overly Convenient Options.
* options, -fno-automatic:              Code Gen Options.
* options, -fno-backslash:              Fortran Dialect Options.
* options, -fno-common:                 Code Gen Options.
* options, -fno-f2c <1>:                Code Gen Options.
* options, -fno-f2c:                    Faster Programs.
* options, -fno-fixed-form:             Fortran Dialect Options.
* options, -fno-ident:                  Code Gen Options.
* options, -fno-inline:                 Optimize Options.
* options, -fno-second-underscore:      Code Gen Options.
* options, -fno-ugly-args:              Warning Options.
* options, -fno-ugly-init:              Warning Options.
* options, -fno-underscoring:           Code Gen Options.
* options, -fpack-struct:               Code Gen Options.
* options, -fpcc-struct-return:         Code Gen Options.
* options, -fpedantic:                  Warning Options.
* options, -freg-struct-return:         Code Gen Options.
* options, -frerun-cse-after-loop:      Optimize Options.
* options, -fschedule-insns:            Optimize Options.
* options, -fschedule-insns2:           Optimize Options.
* options, -fset-g77-defaults:          Overall Options.
* options, -fshort-double:              Code Gen Options.
* options, -fsource-case-lower:         Fortran Dialect Options.
* options, -fsource-case-preserve:      Fortran Dialect Options.
* options, -fsource-case-upper:         Fortran Dialect Options.
* options, -fstrength-reduce:           Optimize Options.
* options, -fsymbol-case-any:           Fortran Dialect Options.
* options, -fsymbol-case-initcap:       Fortran Dialect Options.
* options, -fsymbol-case-lower:         Fortran Dialect Options.
* options, -fsymbol-case-upper:         Fortran Dialect Options.
* options, -fsyntax-only:               Warning Options.
* options, -fugly <1>:                  Overly Convenient Options.
* options, -fugly:                      Warning Options.
* options, -funix-intrinsics-delete:    Fortran Dialect Options.
* options, -funix-intrinsics-disable:   Fortran Dialect Options.
* options, -funix-intrinsics-enable:    Fortran Dialect Options.
* options, -funix-intrinsics-hide:      Fortran Dialect Options.
* options, -funroll-all-loops:          Optimize Options.
* options, -funroll-loops:              Optimize Options.
* options, -fversion:                   Overall Options.
* options, -fvxt-intrinsics-delete:     Fortran Dialect Options.
* options, -fvxt-intrinsics-disable:    Fortran Dialect Options.
* options, -fvxt-intrinsics-enable:     Fortran Dialect Options.
* options, -fvxt-intrinsics-hide:       Fortran Dialect Options.
* options, -fvxt-not-f90:               Fortran Dialect Options.
* options, -fzeros:                     Code Gen Options.
* options, -g:                          Debugging Options.
* options, -I-:                         Directory Options.
* options, -Idir:                       Directory Options.
* options, -pedantic:                   Warning Options.
* options, -pedantic-errors:            Warning Options.
* options, -v:                          G77 and GCC.
* options, -W:                          Warning Options.
* options, -Waggregate-return:          Warning Options.
* options, -Wall:                       Warning Options.
* options, -Wcomment:                   Warning Options.
* options, -Wconversion:                Warning Options.
* options, -Werror:                     Warning Options.
* options, -Wformat:                    Warning Options.
* options, -Wid-clash-LEN:              Warning Options.
* options, -Wimplicit:                  Warning Options.
* options, -Wlarger-than-LEN:           Warning Options.
* options, -Wparentheses:               Warning Options.
* options, -Wredundant-decls:           Warning Options.
* options, -Wshadow:                    Warning Options.
* options, -Wsurprising:                Warning Options.
* options, -Wswitch:                    Warning Options.
* options, -Wtraditional:               Warning Options.
* options, -Wuninitialized:             Warning Options.
* options, -Wunused:                    Warning Options.
* options, code generation:             Code Gen Options.
* options, debugging:                   Debugging Options.
* options, dialect:                     Fortran Dialect Options.
* options, directory search:            Directory Options.
* options, GNU Fortran command:         Invoking G77.
* options, negative forms:              Invoking G77.
* options, optimization:                Optimize Options.
* options, overall:                     Overall Options.
* options, overly convenient:           Overly Convenient Options.
* options, preprocessor:                Preprocessor Options.
* OR intrinsic:                         Missing Features.
* order of evaluation, side effects:    Non-bugs.
* ordering, array:                      Arrays.
* overall options:                      Overall Options.
* overflow:                             Warning Options.
* overly convenient options:            Overly Convenient Options.
* packages:                             Unpacking.
* PARAMETER statement:                  Missing Features.
* parameters, unused:                   Warning Options.
* patch files:                          General Problems.
* patch files, creating:                Merging Distributions.
* pedantic compilation:                 Pedantic Compilation.
* Pentium optimizations:                Unpacking.
* POINTER statement:                    Missing Features.
* pre-installation checks:              Pre-installation Checks.
* preprocessor <1>:                     Bug Reporting.
* preprocessor <1>:                     What is GNU Fortran?.
* preprocessor:                         Overall Options.
* preprocessor options:                 Preprocessor Options.
* prerequisites:                        Prerequisites.
* printing version information <1>:     Overall Options.
* printing version information:         What is GNU Fortran?.
* problems installing:                  Problems Installing.
* procedures:                           Procedures.
* PROGRAM statement:                    Main Program Unit.
* programs, cc1:                        What is GNU Fortran?.
* programs, cc1plus:                    What is GNU Fortran?.
* programs, compiling:                  G77 and GCC.
* programs, cpp <1>:                    Bug Reporting.
* programs, cpp <1>:                    What is GNU Fortran?.
* programs, cpp <1>:                    Overall Options.
* programs, cpp:                        Preprocessor Options.
* programs, f771:                       What is GNU Fortran?.
* programs, speeding up:                Faster Programs.
* questionable instructions:            What is GNU Fortran?.
* quick start:                          Quick Start.
* REAL type:                            Types.
* recent versions <1>:                  Changes.
* recent versions:                      News.
* RECORD statement:                     Missing Features.
* reporting bugs:                       Bugs.
* requirements, GNU C:                  General Problems.
* RETURN statement <1>:                 Functions.
* RETURN statement:                     Alternate Returns.
* return type of functions:             Functions.
* row-major ordering:                   Arrays.
* run-time library:                     What is GNU Fortran?.
* run-time options:                     Code Gen Options.
* SAVE statement:                       Code Gen Options.
* search path:                          Directory Options.
* searching for included files:         Directory Options.
* semicolons:                           Extensions.
* separate distributions:               Merging Distributions.
* SHIFT intrinsic:                      Missing Features.
* side effects:                         Fortran Dialect Options.
* side effects, order of evaluation:    Non-bugs.
* SIGNAL() intrinsic:                   Fortran Dialect Options.
* signature of procedures:              Procedures.
* slow compiler:                        Large Initialization.
* source code <1>:                      Case Sensitivity.
* source code <1>:                      What is GNU Fortran?.
* source code <1>:                      Unpacking.
* source code:                          Source Form.
* source file:                          What is GNU Fortran?.
* source file form:                     Fortran Dialect Options.
* source file format <1>:               Fortran Dialect Options.
* source file format <1>:               Case Sensitivity.
* source file format:                   Source Form.
* source form:                          Source Form.
* source tree:                          Unpacking.
* speed, compiler:                      Large Initialization.
* speeding up loops:                    Optimize Options.
* speeding up programs:                 Faster Programs.
* standard support:                     Standard Support.
* statement labels, assigned:           Assigned Statement Labels.
* statements, ACCEPT:                   Missing Features.
* statements, ASSIGN:                   Assigned Statement Labels.
* statements, BLOCK DATA <1>:           Disappointments.
* statements, BLOCK DATA:               Block Data and Libraries.
* statements, CLOSE:                    Missing Features.
* statements, COMMON <1>:               Disappointments.
* statements, COMMON:                   Common Blocks.
* statements, DATA:                     Code Gen Options.
* statements, DIMENSION <1>:            Adjustable Arrays.
* statements, DIMENSION:                Arrays.
* statements, DO <1>:                   Loops.
* statements, DO:                       Warning Options.
* statements, ENTRY:                    Alternate Entry Points.
* statements, EQUIVALENCE:              Local Equivalence Areas.
* statements, FORMAT:                   Missing Features.
* statements, FUNCTION <1>:             Functions.
* statements, FUNCTION:                 Procedures.
* statements, GOTO:                     Assigned Statement Labels.
* statements, IMPLICIT CHARACTER*(*):   Disappointments.
* statements, INCLUDE <1>:              Directory Options.
* statements, INCLUDE <1>:              Preprocessor Options.
* statements, INCLUDE:                  Bug Reporting.
* statements, INQUIRE:                  Missing Features.
* statements, MAP:                      Missing Features.
* statements, NAMELIST:                 Extensions.
* statements, OPEN:                     Missing Features.
* statements, PARAMETER:                Missing Features.
* statements, POINTER:                  Missing Features.
* statements, PROGRAM:                  Main Program Unit.
* statements, RECORD:                   Missing Features.
* statements, RETURN <1>:               Alternate Returns.
* statements, RETURN:                   Functions.
* statements, SAVE:                     Code Gen Options.
* statements, separated by semicolon:   Extensions.
* statements, STRUCTURE:                Missing Features.
* statements, SUBROUTINE <1>:           Procedures.
* statements, SUBROUTINE:               Alternate Returns.
* statements, TYPE <1>:                 Dialects.
* statements, TYPE:                     Missing Features.
* statements, UNION:                    Missing Features.
* straight build:                       Straight Build.
* STRUCTURE statement:                  Missing Features.
* SUBROUTINE statement <1>:             Procedures.
* SUBROUTINE statement:                 Alternate Returns.
* subroutines:                          Alternate Returns.
* subroutines, intrinsic:               Fortran Dialect Options.
* suffixes, file name:                  Overall Options.
* support for gcc versions:             Merging Distributions.
* support for ANSI FORTRAN 77:          Standard Support.
* support, gdb:                         But-bugs.
* support, f77:                         Non-bugs.
* support, Fortran 90:                  Missing Features.
* suppressing warnings:                 Warning Options.
* symbol names <1>:                     Names.
* symbol names:                         Fortran Dialect Options.
* symbol names, transforming:           Code Gen Options.
* symbol names, underscores:            Code Gen Options.
* syntax checking:                      Warning Options.
* SYSTEM() intrinsic:                   Fortran Dialect Options.
* tab characters:                       Source Form.
* texinfo:                              Updating Documentation.
* trailing null byte:                   Character and Hollerith Constants.
* transformation of symbol names:       Names.
* transforming symbol names:            Code Gen Options.
* translation of user programs:         What is GNU Fortran?.
* trips, number of:                     Loops.
* TYPE statement <1>:                   Missing Features.
* TYPE statement:                       Dialects.
* typeless constants:                   Changes.
* types, COMPLEX:                       Types.
* types, constants:                     Constants.
* types, DOUBLE COMPLEX:                Types.
* types, DOUBLE PRECISION:              Types.
* types, file:                          Overall Options.
* types, INTEGER:                       Types.
* types, LOGICAL:                       Types.
* types, of data:                       Types.
* types, REAL:                          Types.
* ugly features <1>:                    Distensions.
* ugly features:                        Warning Options.
* undefined behavior:                   Bug Criteria.
* undefined function value:             Bug Criteria.
* undefined reference (_main):          But-bugs.
* undefined reference (_strtoul):       General Problems.
* underscores:                          Code Gen Options.
* uninitialized variables <1>:          Warning Options.
* uninitialized variables:              Code Gen Options.
* UNION statement:                      Missing Features.
* UNIX intrinsics:                      Fortran Dialect Options.
* unpacking distributions:              Unpacking.
* unrecognized file format:             What is GNU Fortran?.
* unresolved reference (various):       But-bugs.
* unrolling loops:                      Optimize Options.
* unsupported warnings:                 Warning Options.
* unused arguments:                     Warning Options.
* unused dummies:                       Warning Options.
* unused parameters:                    Warning Options.
* unused variables:                     Warning Options.
* updating info directory:              Updating Documentation.
* uppercase letters:                    Case Sensitivity.
* user-visible changes:                 Changes.
* variables, initialization of:         Code Gen Options.
* variables, uninitialized <1>:         Warning Options.
* variables, uninitialized:             Code Gen Options.
* variables, unused:                    Warning Options.
* version information, printing <1>:    What is GNU Fortran?.
* version information, printing:        Overall Options.
* versions of gcc:                      Merging Distributions.
* versions, recent <1>:                 Changes.
* versions, recent:                     News.
* VXT extensions:                       Dialects.
* VXT features <1>:                     Dialects.
* VXT features:                         Fortran Dialect Options.
* VXT intrinsics:                       Fortran Dialect Options.
* warning messages:                     Warning Options.
* warnings:                             What is GNU Fortran?.
* warnings vs errors:                   Warnings and Errors.
* warnings, all:                        Warning Options.
* warnings, extra:                      Warning Options.
* warnings, implicit declaration:       Warning Options.
* warnings, unsupported:                Warning Options.
* why separate distributions:           Merging Distributions.
* wisdom:                               Collected Fortran Wisdom.
* writing code:                         Collected Fortran Wisdom.
* zero byte, trailing:                  Character and Hollerith Constants.
* _strtoul:                             General Problems.



Tag Table:
Node: Top1563
Node: Copying3134
Node: Contributors22331
Node: Funding25183
Node: Funding GNU Fortran27701
Node: Look and Feel30520
Node: Getting Started31037
Node: What is GNU Fortran?33370
Node: G77 and GCC42922
Node: Invoking G7744288
Node: Option Summary46377
Node: Overall Options50422
Node: Fortran Dialect Options53759
Node: Warning Options61505
Node: Debugging Options70141
Node: Optimize Options70989
Node: Preprocessor Options73251
Node: Directory Options74001
Node: Code Gen Options75250
Node: Environment Variables82351
Node: News82824
Node: Changes107364
Node: Language113636
Node: Standard Support115169
Node: Extensions117580
Node: Types120540
Node: Constants125025
Node: Source Form126194
Node: Pedantic Compilation130041
Node: Case Sensitivity133433
Node: Intrinsics142015
Node: Dialects145294
Node: Object Compatibility146954
Node: Dropping f2c Compatibility149280
Node: Other Compilers152061
Node: Distensions153848
Node: Installation156193
Node: Prerequisites157346
Node: Problems Installing161898
Node: General Problems162542
Node: Cross-compiler Problems165629
Node: Quick Start167661
Node: Complete Installation175650
Node: Unpacking176245
Node: Merging Distributions179359
Node: Installing f77184604
Node: Installing f2c185964
Node: Patching GNU Fortran188904
Node: Where to Install190154
Node: Configuring gcc193405
Node: Building gcc195192
Node: Bootstrap Build197214
Node: Straight Build199137
Node: Pre-installation Checks200541
Node: Installation of Binaries203765
Node: Updating Documentation205125
Node: Missing bison?205961
Node: Missing makeinfo?207328
Node: Distributing Binaries207868
Node: Settings213578
Node: Maximum Stackable Size214425
Node: Floating-point Bit Patterns215006
Node: Large Initialization215767
Node: Alpha Problems217364
Node: Debugging and Interfacing218443
Node: Names221016
Node: Main Program Unit224077
Node: Arrays226434
Node: Procedures229776
Node: Adjustable Arrays232152
Node: Alternate Returns235025
Node: Functions235912
Node: Common Blocks237547
Node: Local Equivalence Areas238722
Node: Alternate Entry Points240241
Node: Assigned Statement Labels247022
Node: Collected Fortran Wisdom248876
Node: Overly Convenient Options250327
Node: Block Data and Libraries253327
Node: Faster Programs255741
Node: Working Programs257364
Node: Loops260047
Node: Advantages Over f2c265266
Node: Language Extensions266171
Node: Compiler Options266693
Node: Compiler Speed267160
Node: Program Speed267884
Node: Ease of Debugging269182
Node: Character and Hollerith Constants271635
Node: Trouble272444
Node: But-bugs273911
Node: GPC Bugs279044
Node: Missing Features283336
Node: Disappointments297381
Node: Non-bugs299795
Node: Warnings and Errors311379
Node: Open Questions313078
Node: Bugs314381
Node: Bug Criteria315786
Node: Bug Lists318047
Node: Bug Reporting318832
Node: Sending Patches332259
Node: Service337756
Node: Index338230

End Tag Table