This is g77.info, produced by makeinfo version 4.8 from
/usr/obj/ports/g77-3.3.5/g77/gcc/f/g77.texi.

   Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002,2003,2004 Free
Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.

INFO-DIR-SECTION Programming
START-INFO-DIR-ENTRY
* g77: (g77).                  The GNU Fortran compiler.
END-INFO-DIR-ENTRY
   This file documents the use and the internals of the GNU Fortran
(`g77') compiler.  It corresponds to the GCC-3.3.5 version of `g77'.

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

   Copyright (C) 1995,1996,1997,1998,1999,2000,2001,2002,2003,2004 Free
Software Foundation, Inc.

   Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding Free
Software", the Front-Cover texts being (a) (see below), and with the
Back-Cover Texts being (b) (see below).  A copy of the license is
included in the section entitled "GNU Free Documentation License".

   (a) The FSF's Front-Cover Text is:

   A GNU Manual

   (b) The FSF's Back-Cover Text is:

   You have freedom to copy and modify this GNU Manual, like GNU
software.  Copies published by the Free Software Foundation raise
funds for GNU development.

   Contributed by James Craig Burley (<craig@jcb-sc.com>).  Inspired by
a first pass at translating `g77-0.5.16/f/DOC' that was contributed to
Craig by David Ronis (<ronis@onsager.chem.mcgill.ca>).


File: g77.info,  Node: Top,  Next: Copying,  Up: (DIR)

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

This manual documents how to run, install and port `g77', as well as
its new features and incompatibilities, and how to report bugs.  It
corresponds to the GCC-3.3.5 version of `g77'.

* Menu:

* Copying::         GNU General Public License says
                    how you can copy and share GNU Fortran.
* GNU Free Documentation License::
		    How you can copy and share this manual.
* Contributors::    People who have contributed to GNU Fortran.
* Funding::         How to help assure continued work for free software.
* Funding GNU Fortran::  How to help assure continued work on GNU Fortran.

* 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.
* Compiler::        The GNU Fortran compiler.
* Other Dialects::  Dialects of Fortran supported by `g77'.
* Other Compilers:: Fortran compilers other than `g77'.
* Other Languages:: Languages other than 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.

* Adding Options::  Guidance on teaching `g77' about new options.
* Projects::        Projects for `g77' internals hackers.
* Front End::       Design and implementation of the `g77' front end.

* M: Diagnostics.   Diagnostics produced by `g77'.

* Keyword Index::   Index of concepts and symbol names.


File: g77.info,  Node: Copying,  Next: GNU Free Documentation License,  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) YEAR  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) YEAR 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: g77.info,  Node: GNU Free Documentation License,  Next: Contributors,  Prev: Copying,  Up: Top

GNU Free Documentation License
******************************

                      Version 1.2, November 2002

     Copyright (C) 2000,2001,2002 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.

  0. PREAMBLE

     The purpose of this License is to make a manual, textbook, or other
     functional and useful document "free" in the sense of freedom: to
     assure everyone the effective freedom to copy and redistribute it,
     with or without modifying it, either commercially or
     noncommercially.  Secondarily, this License preserves for the
     author and publisher a way to get credit for their work, while not
     being considered responsible for modifications made by others.

     This License is a kind of "copyleft", which means that derivative
     works of the document must themselves be free in the same sense.
     It complements the GNU General Public License, which is a copyleft
     license designed for free software.

     We have designed this License in order to use it for manuals for
     free software, because free software needs free documentation: a
     free program should come with manuals providing the same freedoms
     that the software does.  But this License is not limited to
     software manuals; it can be used for any textual work, regardless
     of subject matter or whether it is published as a printed book.
     We recommend this License principally for works whose purpose is
     instruction or reference.

  1. APPLICABILITY AND DEFINITIONS

     This License applies to any manual or other work, in any medium,
     that contains a notice placed by the copyright holder saying it
     can be distributed under the terms of this License.  Such a notice
     grants a world-wide, royalty-free license, unlimited in duration,
     to use that work under the conditions stated herein.  The
     "Document", below, refers to any such manual or work.  Any member
     of the public is a licensee, and is addressed as "you".  You
     accept the license if you copy, modify or distribute the work in a
     way requiring permission under copyright law.

     A "Modified Version" of the Document means any work containing the
     Document or a portion of it, either copied verbatim, or with
     modifications and/or translated into another language.

     A "Secondary Section" is a named appendix or a front-matter section
     of the Document that deals exclusively with the relationship of the
     publishers or authors of the Document to the Document's overall
     subject (or to related matters) and contains nothing that could
     fall directly within that overall subject.  (Thus, if the Document
     is in part a textbook of mathematics, a Secondary Section may not
     explain any mathematics.)  The relationship could be a matter of
     historical connection with the subject or with related matters, or
     of legal, commercial, philosophical, ethical or political position
     regarding them.

     The "Invariant Sections" are certain Secondary Sections whose
     titles are designated, as being those of Invariant Sections, in
     the notice that says that the Document is released under this
     License.  If a section does not fit the above definition of
     Secondary then it is not allowed to be designated as Invariant.
     The Document may contain zero Invariant Sections.  If the Document
     does not identify any Invariant Sections then there are none.

     The "Cover Texts" are certain short passages of text that are
     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
     that says that the Document is released under this License.  A
     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
     be at most 25 words.

     A "Transparent" copy of the Document means a machine-readable copy,
     represented in a format whose specification is available to the
     general public, that is suitable for revising the document
     straightforwardly with generic text editors or (for images
     composed of pixels) generic paint programs or (for drawings) some
     widely available drawing editor, and that is suitable for input to
     text formatters or for automatic translation to a variety of
     formats suitable for input to text formatters.  A copy made in an
     otherwise Transparent file format whose markup, or absence of
     markup, has been arranged to thwart or discourage subsequent
     modification by readers is not Transparent.  An image format is
     not Transparent if used for any substantial amount of text.  A
     copy that is not "Transparent" is called "Opaque".

     Examples of suitable formats for Transparent copies include plain
     ASCII without markup, Texinfo input format, LaTeX input format,
     SGML or XML using a publicly available DTD, and
     standard-conforming simple HTML, PostScript or PDF designed for
     human modification.  Examples of transparent image formats include
     PNG, XCF and JPG.  Opaque formats include proprietary formats that
     can be read and edited only by proprietary word processors, SGML or
     XML for which the DTD and/or processing tools are not generally
     available, and the machine-generated HTML, PostScript or PDF
     produced by some word processors for output purposes only.

     The "Title Page" means, for a printed book, the title page itself,
     plus such following pages as are needed to hold, legibly, the
     material this License requires to appear in the title page.  For
     works in formats which do not have any title page as such, "Title
     Page" means the text near the most prominent appearance of the
     work's title, preceding the beginning of the body of the text.

     A section "Entitled XYZ" means a named subunit of the Document
     whose title either is precisely XYZ or contains XYZ in parentheses
     following text that translates XYZ in another language.  (Here XYZ
     stands for a specific section name mentioned below, such as
     "Acknowledgements", "Dedications", "Endorsements", or "History".)
     To "Preserve the Title" of such a section when you modify the
     Document means that it remains a section "Entitled XYZ" according
     to this definition.

     The Document may include Warranty Disclaimers next to the notice
     which states that this License applies to the Document.  These
     Warranty Disclaimers are considered to be included by reference in
     this License, but only as regards disclaiming warranties: any other
     implication that these Warranty Disclaimers may have is void and
     has no effect on the meaning of this License.

  2. VERBATIM COPYING

     You may copy and distribute the Document in any medium, either
     commercially or noncommercially, provided that this License, the
     copyright notices, and the license notice saying this License
     applies to the Document are reproduced in all copies, and that you
     add no other conditions whatsoever to those of this License.  You
     may not use technical measures to obstruct or control the reading
     or further copying of the copies you make or distribute.  However,
     you may accept compensation in exchange for copies.  If you
     distribute a large enough number of copies you must also follow
     the conditions in section 3.

     You may also lend copies, under the same conditions stated above,
     and you may publicly display copies.

  3. COPYING IN QUANTITY

     If you publish printed copies (or copies in media that commonly
     have printed covers) of the Document, numbering more than 100, and
     the Document's license notice requires Cover Texts, you must
     enclose the copies in covers that carry, clearly and legibly, all
     these Cover Texts: Front-Cover Texts on the front cover, and
     Back-Cover Texts on the back cover.  Both covers must also clearly
     and legibly identify you as the publisher of these copies.  The
     front cover must present the full title with all words of the
     title equally prominent and visible.  You may add other material
     on the covers in addition.  Copying with changes limited to the
     covers, as long as they preserve the title of the Document and
     satisfy these conditions, can be treated as verbatim copying in
     other respects.

     If the required texts for either cover are too voluminous to fit
     legibly, you should put the first ones listed (as many as fit
     reasonably) on the actual cover, and continue the rest onto
     adjacent pages.

     If you publish or distribute Opaque copies of the Document
     numbering more than 100, you must either include a
     machine-readable Transparent copy along with each Opaque copy, or
     state in or with each Opaque copy a computer-network location from
     which the general network-using public has access to download
     using public-standard network protocols a complete Transparent
     copy of the Document, free of added material.  If you use the
     latter option, you must take reasonably prudent steps, when you
     begin distribution of Opaque copies in quantity, to ensure that
     this Transparent copy will remain thus accessible at the stated
     location until at least one year after the last time you
     distribute an Opaque copy (directly or through your agents or
     retailers) of that edition to the public.

     It is requested, but not required, that you contact the authors of
     the Document well before redistributing any large number of
     copies, to give them a chance to provide you with an updated
     version of the Document.

  4. MODIFICATIONS

     You may copy and distribute a Modified Version of the Document
     under the conditions of sections 2 and 3 above, provided that you
     release the Modified Version under precisely this License, with
     the Modified Version filling the role of the Document, thus
     licensing distribution and modification of the Modified Version to
     whoever possesses a copy of it.  In addition, you must do these
     things in the Modified Version:

       A. Use in the Title Page (and on the covers, if any) a title
          distinct from that of the Document, and from those of
          previous versions (which should, if there were any, be listed
          in the History section of the Document).  You may use the
          same title as a previous version if the original publisher of
          that version gives permission.

       B. List on the Title Page, as authors, one or more persons or
          entities responsible for authorship of the modifications in
          the Modified Version, together with at least five of the
          principal authors of the Document (all of its principal
          authors, if it has fewer than five), unless they release you
          from this requirement.

       C. State on the Title page the name of the publisher of the
          Modified Version, as the publisher.

       D. Preserve all the copyright notices of the Document.

       E. Add an appropriate copyright notice for your modifications
          adjacent to the other copyright notices.

       F. Include, immediately after the copyright notices, a license
          notice giving the public permission to use the Modified
          Version under the terms of this License, in the form shown in
          the Addendum below.

       G. Preserve in that license notice the full lists of Invariant
          Sections and required Cover Texts given in the Document's
          license notice.

       H. Include an unaltered copy of this License.

       I. Preserve the section Entitled "History", Preserve its Title,
          and add to it an item stating at least the title, year, new
          authors, and publisher of the Modified Version as given on
          the Title Page.  If there is no section Entitled "History" in
          the Document, create one stating the title, year, authors,
          and publisher of the Document as given on its Title Page,
          then add an item describing the Modified Version as stated in
          the previous sentence.

       J. Preserve the network location, if any, given in the Document
          for public access to a Transparent copy of the Document, and
          likewise the network locations given in the Document for
          previous versions it was based on.  These may be placed in
          the "History" section.  You may omit a network location for a
          work that was published at least four years before the
          Document itself, or if the original publisher of the version
          it refers to gives permission.

       K. For any section Entitled "Acknowledgements" or "Dedications",
          Preserve the Title of the section, and preserve in the
          section all the substance and tone of each of the contributor
          acknowledgements and/or dedications given therein.

       L. Preserve all the Invariant Sections of the Document,
          unaltered in their text and in their titles.  Section numbers
          or the equivalent are not considered part of the section
          titles.

       M. Delete any section Entitled "Endorsements".  Such a section
          may not be included in the Modified Version.

       N. Do not retitle any existing section to be Entitled
          "Endorsements" or to conflict in title with any Invariant
          Section.

       O. Preserve any Warranty Disclaimers.

     If the Modified Version includes new front-matter sections or
     appendices that qualify as Secondary Sections and contain no
     material copied from the Document, you may at your option
     designate some or all of these sections as invariant.  To do this,
     add their titles to the list of Invariant Sections in the Modified
     Version's license notice.  These titles must be distinct from any
     other section titles.

     You may add a section Entitled "Endorsements", provided it contains
     nothing but endorsements of your Modified Version by various
     parties--for example, statements of peer review or that the text
     has been approved by an organization as the authoritative
     definition of a standard.

     You may add a passage of up to five words as a Front-Cover Text,
     and a passage of up to 25 words as a Back-Cover Text, to the end
     of the list of Cover Texts in the Modified Version.  Only one
     passage of Front-Cover Text and one of Back-Cover Text may be
     added by (or through arrangements made by) any one entity.  If the
     Document already includes a cover text for the same cover,
     previously added by you or by arrangement made by the same entity
     you are acting on behalf of, you may not add another; but you may
     replace the old one, on explicit permission from the previous
     publisher that added the old one.

     The author(s) and publisher(s) of the Document do not by this
     License give permission to use their names for publicity for or to
     assert or imply endorsement of any Modified Version.

  5. COMBINING DOCUMENTS

     You may combine the Document with other documents released under
     this License, under the terms defined in section 4 above for
     modified versions, provided that you include in the combination
     all of the Invariant Sections of all of the original documents,
     unmodified, and list them all as Invariant Sections of your
     combined work in its license notice, and that you preserve all
     their Warranty Disclaimers.

     The combined work need only contain one copy of this License, and
     multiple identical Invariant Sections may be replaced with a single
     copy.  If there are multiple Invariant Sections with the same name
     but different contents, make the title of each such section unique
     by adding at the end of it, in parentheses, the name of the
     original author or publisher of that section if known, or else a
     unique number.  Make the same adjustment to the section titles in
     the list of Invariant Sections in the license notice of the
     combined work.

     In the combination, you must combine any sections Entitled
     "History" in the various original documents, forming one section
     Entitled "History"; likewise combine any sections Entitled
     "Acknowledgements", and any sections Entitled "Dedications".  You
     must delete all sections Entitled "Endorsements."

  6. COLLECTIONS OF DOCUMENTS

     You may make a collection consisting of the Document and other
     documents released under this License, and replace the individual
     copies of this License in the various documents with a single copy
     that is included in the collection, provided that you follow the
     rules of this License for verbatim copying of each of the
     documents in all other respects.

     You may extract a single document from such a collection, and
     distribute it individually under this License, provided you insert
     a copy of this License into the extracted document, and follow
     this License in all other respects regarding verbatim copying of
     that document.

  7. AGGREGATION WITH INDEPENDENT WORKS

     A compilation of the Document or its derivatives with other
     separate and independent documents or works, in or on a volume of
     a storage or distribution medium, is called an "aggregate" if the
     copyright resulting from the compilation is not used to limit the
     legal rights of the compilation's users beyond what the individual
     works permit.  When the Document is included an aggregate, this
     License does not apply to the other works in the aggregate which
     are not themselves derivative works of the Document.

     If the Cover Text requirement of section 3 is applicable to these
     copies of the Document, then if the Document is less than one half
     of the entire aggregate, the Document's Cover Texts may be placed
     on covers that bracket the Document within the aggregate, or the
     electronic equivalent of covers if the Document is in electronic
     form.  Otherwise they must appear on printed covers that bracket
     the whole aggregate.

  8. TRANSLATION

     Translation is considered a kind of modification, so you may
     distribute translations of the Document under the terms of section
     4.  Replacing Invariant Sections with translations requires special
     permission from their copyright holders, but you may include
     translations of some or all Invariant Sections in addition to the
     original versions of these Invariant Sections.  You may include a
     translation of this License, and all the license notices in the
     Document, and any Warrany Disclaimers, provided that you also
     include the original English version of this License and the
     original versions of those notices and disclaimers.  In case of a
     disagreement between the translation and the original version of
     this License or a notice or disclaimer, the original version will
     prevail.

     If a section in the Document is Entitled "Acknowledgements",
     "Dedications", or "History", the requirement (section 4) to
     Preserve its Title (section 1) will typically require changing the
     actual title.

  9. TERMINATION

     You may not copy, modify, sublicense, or distribute the Document
     except as expressly provided for under this License.  Any other
     attempt to copy, modify, sublicense or distribute the Document 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.

 10. FUTURE REVISIONS OF THIS LICENSE

     The Free Software Foundation may publish new, revised versions of
     the GNU Free Documentation 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.  See
     `http://www.gnu.org/copyleft/'.

     Each version of the License is given a distinguishing version
     number.  If the Document specifies that a particular numbered
     version of this License "or any later version" applies to it, you
     have the option of following the terms and conditions either of
     that specified version or of any later version that has been
     published (not as a draft) by the Free Software Foundation.  If
     the Document does not specify a version number of this License,
     you may choose any version ever published (not as a draft) by the
     Free Software Foundation.

ADDENDUM: How to use this License for your documents
====================================================

To use this License in a document you have written, include a copy of
the License in the document and put the following copyright and license
notices just after the title page:

       Copyright (C)  YEAR  YOUR NAME.
       Permission is granted to copy, distribute and/or modify this document
       under the terms of the GNU Free Documentation License, Version 1.2
       or any later version published by the Free Software Foundation;
       with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts.
       A copy of the license is included in the section entitled ``GNU
       Free Documentation License''.

   If you have Invariant Sections, Front-Cover Texts and Back-Cover
Texts, replace the "with...Texts." line with this:

         with the Invariant Sections being LIST THEIR TITLES, with
         the Front-Cover Texts being LIST, and with the Back-Cover Texts
         being LIST.

   If you have Invariant Sections without Cover Texts, or some other
combination of the three, merge those two alternatives to suit the
situation.

   If your document contains nontrivial examples of program code, we
recommend releasing these examples in parallel under your choice of
free software license, such as the GNU General Public License, to
permit their use in free software.


File: g77.info,  Node: Contributors,  Next: Funding,  Prev: GNU Free Documentation License,  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 GCC:
     (gcc)Contributors, for more information.

   * The run-time library used by GNU Fortran is a repackaged version
     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)--<takafumi@u-aizu.ac.jp>

          Kate Hedstrom

          Michel Kern (INRIA and Rice
          University)--<Michel.Kern@inria.fr>

          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

   * Dave Love (<d.love@dl.ac.uk>) wrote the libU77 part of the
     run-time library.

   * Scott Snyder (<snyder@d0sgif.fnal.gov>) 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.

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

   * Toon Moene (<toon@moene.indiv.nluug.nl>) 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.

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

   * John Carr (<jfc@mit.edu>) wrote the alias analysis improvements.

   * Thanks to Mary Cortani and the staff at Craftwork Solutions
     (<support@craftwork.com>) for all of their support.

   * 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: g77.info,  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 Compiler Collection
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: g77.info,  Node: Funding GNU Fortran,  Next: Getting Started,  Prev: Funding,  Up: Top

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

James Craig Burley (<craig@jcb-sc.com>), the original author of `g77',
stopped working on it in September 1999 (He has a web page at
`http://world.std.com/%7Eburley/'.)

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

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

   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 <gnu@gnu.org> for information on funding
the FSF.

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

   Email <gcc@gcc.gnu.org> to volunteer for this work.

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

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


File: g77.info,  Node: Getting Started,  Next: What is GNU Fortran?,  Prev: Funding GNU Fortran,  Up: Top

2 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 About GNU Fortran: 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 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: g77.info,  Node: What is GNU Fortran?,  Next: G77 and GCC,  Prev: Getting Started,  Up: Top

3 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 `libg2c' run-time library.  This library contains the machine
     code needed to support capabilities of the Fortran language that
     are not directly provided by the machine code generated by the
     `g77' compilation phase.

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

     The maintainer of `libf2c' currently is <dmg@bell-labs.com>.

   * 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 (`libg2c' 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.  (If it produces an error message near the end
of the output--diagnostics from the linker, usually `ld'--you might
have an out-of-date `libf2c' that improperly handles complex
arithmetic.)  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 `libg2c', so
`libg2c' 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 much of the `libg2c' component comes from the `libf2c' component
of `f2c', a free Fortran-to-C converter distributed by Bellcore (AT&T),
plus `libU77', provided by Dave Love, 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: g77.info,  Node: G77 and GCC,  Next: Invoking G77,  Prev: What is GNU Fortran?,  Up: Top

4 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++; Objective-C; Ada; Fortran; or Java: (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.


File: g77.info,  Node: Invoking G77,  Next: News,  Prev: G77 and GCC,  Up: Top

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

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

   All `gcc' and `g77' options are accepted both by `g77' and by `gcc'
(as well as any other drivers built at the same time, such as `g++'),
since adding `g77' to the `gcc' distribution enables acceptance of
`g77' options by all of the relevant drivers.

   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.
* Shorthand Options::   Options that are shorthand for other options.
* 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: g77.info,  Node: Option Summary,  Next: Overall Options,  Up: Invoking G77

5.1 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.
          -fversion  -fset-g77-defaults  -fno-silent

_Shorthand Options_
     *Note Shorthand Options::.
          -ff66  -fno-f66  -ff77  -fno-f77  -fno-ugly

_Fortran Language Options_
     *Note Options Controlling Fortran Dialect: Fortran Dialect Options.
          -ffree-form  -fno-fixed-form  -ff90
          -fvxt  -fdollar-ok  -fno-backslash
          -fno-ugly-args  -fno-ugly-assign  -fno-ugly-assumed
          -fugly-comma  -fugly-complex  -fugly-init  -fugly-logint
          -fonetrip  -ftypeless-boz
          -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
          -ff2c-intrinsics-delete  -ff2c-intrinsics-hide
          -ff2c-intrinsics-disable  -ff2c-intrinsics-enable
          -fbadu77-intrinsics-delete  -fbadu77-intrinsics-hide
          -fbadu77-intrinsics-disable  -fbadu77-intrinsics-enable
          -ff90-intrinsics-delete  -ff90-intrinsics-hide
          -ff90-intrinsics-disable  -ff90-intrinsics-enable
          -fgnu-intrinsics-delete  -fgnu-intrinsics-hide
          -fgnu-intrinsics-disable  -fgnu-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
          -w  -Wno-globals  -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.
          -malign-double
          -ffloat-store  -fforce-mem  -fforce-addr  -fno-inline
          -ffast-math  -fstrength-reduce  -frerun-cse-after-loop
          -funsafe-math-optimizations -ffinite-math-only -fno-trapping-math
          -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  -fno-second-underscore
          -femulate-complex
          -falias-check  -fargument-alias
          -fargument-noalias  -fno-argument-noalias-global
          -fno-globals  -fflatten-arrays
          -fbounds-check  -ffortran-bounds-check


* Menu:

* Overall Options::     Controlling the kind of output:
                        an executable, object files, assembler files,
                        or preprocessed source.
* Shorthand Options::   Options that are shorthand for other options.
* 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: g77.info,  Node: Overall Options,  Next: Shorthand Options,  Prev: Option Summary,  Up: Invoking G77

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

Compilation can involve as many as four stages: preprocessing, code
generation (often what is really meant by the term "compilation"),
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 program is contained in the file--that is, the language in which the
program is written is generally indicated by the suffix.  Suffixes
specific to GNU Fortran are listed below.  *Note Options Controlling
the Kind of Output: (gcc)Overall Options, for information on suffixes
recognized by GNU CC.

`FILE.f'

`FILE.for'

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

     Such source code cannot contain any preprocessor directives, such
     as `#include', `#define', `#if', and so on.

     You can force `.f' files to be preprocessed by `cpp' by using `-x
     f77-cpp-input'.  *Note LEX::.

`FILE.F'

`FILE.fpp'

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

     Note that preprocessing is not extended to the contents of files
     included by the `INCLUDE' directive--the `#include' preprocessor
     directive must be used instead.

`FILE.r'
     Ratfor source code, which must be preprocessed by the `ratfor'
     command, which is available separately (as it is not yet part of
     the GNU Fortran distribution).  A public domain version in C is at
     `http://sepwww.stanford.edu/sep/prof/ratfor.shar.2'.

   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 constructs such as Hollerith and character constants can
nevertheless present problems, especially when these are continued
across multiple source lines.  These problems result, primarily, from
differences between the way such constants are interpreted by the C
preprocessor and by a Fortran compiler.

   Another example of a problem that results from using the C
preprocessor is that a Fortran comment line that happens to contain any
characters "interesting" to the C preprocessor, such as a backslash at
the end of the line, is not recognized by the preprocessor as a comment
line, so instead of being passed through "raw", the line is edited
according to the rules for the preprocessor.  For example, the
backslash at the end of the line is removed, along with the subsequent
newline, resulting in the next line being effectively commented
out--unfortunate if that line is a non-comment line of important code!

   _Note:_ The `-traditional' and `-undef' flags are supplied to `cpp'
by default, to help avoid unpleasant surprises.  *Note Options
Controlling the Preprocessor: (gcc)Preprocessor Options.  This means
that ANSI C preprocessor features (such as the `#' operator) aren't
available, and only variables in the C reserved namespace (generally,
names with a leading underscore) are liable to substitution by C
predefines.  Thus, if you want to do system-specific tests, use, for
example, `#ifdef __linux__' rather than `#ifdef linux'.  Use the `-v'
option to see exactly how the preprocessor is invoked.

   Unfortunately, the `-traditional' flag will not avoid an error from
anything that `cpp' sees as an unterminated C comment, such as:
     C Some Fortran compilers accept /* as starting
     C an inline comment.
   *Note Trailing Comment::.

   The following options that affect overall processing are recognized
by the `g77' and `gcc' commands in a GNU Fortran installation:

`-fversion'
     Ensure that the `g77' version of the compiler phase is reported,
     if run, and, starting in `egcs' version 1.1, that internal
     consistency checks in the `f771' program are run.

     This option is supplied automatically when `-v' or `--verbose' is
     specified as a command-line option for `g77' or `gcc' and when the
     resulting commands compile Fortran source files.

     In GCC 3.1, this is changed back to the behavior `gcc' displays
     for `.c' files.

`-fset-g77-defaults'
     _Version info:_ This option was obsolete as of `egcs' version 1.1.
     The effect is instead achieved by the `lang_init_options' routine
     in `gcc/gcc/f/com.c'.

     Set up whatever `gcc' options are to apply to Fortran
     compilations, and avoid running internal consistency checks that
     might take some time.

     This option is supplied automatically when compiling Fortran code
     via the `g77' or `gcc' command.  The description of this option is
     provided 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' However, such developers should, after linking a
     new `f771' executable, invoke it without this option once, e.g.
     via `./f771 -quiet < /dev/null', to ensure that they have not
     introduced any internal inconsistencies (such as in the table of
     intrinsics) before proceeding--`g77' will crash with a diagnostic
     if it detects an inconsistency.

`-fno-silent'
     Print (to `stderr') the names of the program units as they are
     compiled, in a form similar to that used by popular UNIX `f77'
     implementations and `f2c'

   *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: g77.info,  Node: Shorthand Options,  Next: Fortran Dialect Options,  Prev: Overall Options,  Up: Invoking G77

5.3 Shorthand Options
=====================

The following options serve as "shorthand" for other options accepted
by the compiler:

`-fugly'
     _Note:_ This option is no longer supported.  The information,
     below, is provided to aid in the conversion of old scripts.

     Specify that certain "ugly" constructs are to be quietly accepted.
     Same as:

          -fugly-args -fugly-assign -fugly-assumed
          -fugly-comma -fugly-complex -fugly-init
          -fugly-logint

     These constructs are considered inappropriate to use in new or
     well-maintained portable Fortran code, but widely used in old code.
     *Note Distensions::, for more information.

`-fno-ugly'
     Specify that all "ugly" constructs are to be noisily rejected.
     Same as:

          -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
          -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
          -fno-ugly-logint

     *Note Distensions::, for more information.

`-ff66'
     Specify that the program is written in idiomatic FORTRAN 66.  Same
     as `-fonetrip -fugly-assumed'.

     The `-fno-f66' option is the inverse of `-ff66'.  As such, it is
     the same as `-fno-onetrip -fno-ugly-assumed'.

     The meaning of this option is likely to be refined as future
     versions of `g77' provide more compatibility with other existing
     and obsolete Fortran implementations.

`-ff77'
     Specify that the program is written in idiomatic UNIX FORTRAN 77
     and/or the dialect accepted by the `f2c' product.  Same as
     `-fbackslash -fno-typeless-boz'.

     The meaning of this option is likely to be refined as future
     versions of `g77' provide more compatibility with other existing
     and obsolete Fortran implementations.

`-fno-f77'
     The `-fno-f77' option is _not_ the inverse of `-ff77'.  It
     specifies that the program is not written in idiomatic UNIX
     FORTRAN 77 or `f2c' but in a more widely portable dialect.
     `-fno-f77' is the same as `-fno-backslash'.

     The meaning of this option is likely to be refined as future
     versions of `g77' provide more compatibility with other existing
     and obsolete Fortran implementations.


File: g77.info,  Node: Fortran Dialect Options,  Next: Warning Options,  Prev: Shorthand Options,  Up: Invoking G77

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

     *Note Fortran 90::, for more information.

`-fvxt'
     Specify the treatment of certain constructs that have different
     meanings depending on whether the code is written in GNU Fortran
     (based on FORTRAN 77 and akin to Fortran 90) or VXT Fortran (more
     like VAX FORTRAN).

     The default is `-fno-vxt'.  `-fvxt' specifies that the VXT Fortran
     interpretations for those constructs are to be chosen.

     *Note VXT Fortran::, 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 Backslash in Constants::, for information on why
     `-fbackslash' is the default instead of `-fno-backslash'.

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

     *Note Ugly Implicit Argument Conversion::, for more information.

`-fugly-assign'
     Use the same storage for a given variable regardless of whether it
     is used to hold an assigned-statement label (as in `ASSIGN 10 TO
     I') or used to hold numeric data (as in `I = 3').

     *Note Ugly Assigned Labels::, for more information.

`-fugly-assumed'
     Assume any dummy array with a final dimension specified as `1' is
     really an assumed-size array, as if `*' had been specified for the
     final dimension instead of `1'.

     For example, `DIMENSION X(1)' is treated as if it had read
     `DIMENSION X(*)'.

     *Note Ugly Assumed-Size Arrays::, for more information.

`-fugly-comma'
     In an external-procedure invocation, treat a trailing comma in the
     argument list as specification of a trailing null argument, and
     treat an empty argument list as specification of a single null
     argument.

     For example, `CALL FOO(,)' is treated as `CALL FOO(%VAL(0),
     %VAL(0))'.  That is, _two_ null arguments are specified by the
     procedure call when `-fugly-comma' is in force.  And `F = FUNC()'
     is treated as `F = FUNC(%VAL(0))'.

     The default behavior, `-fno-ugly-comma', is to ignore a single
     trailing comma in an argument list.  So, by default, `CALL
     FOO(X,)' is treated exactly the same as `CALL FOO(X)'.

     *Note Ugly Null Arguments::, for more information.

`-fugly-complex'
     Do not complain about `REAL(EXPR)' or `AIMAG(EXPR)' when EXPR is a
     `COMPLEX' type other than `COMPLEX(KIND=1)'--usually this is used
     to permit `COMPLEX(KIND=2)' (`DOUBLE COMPLEX') operands.

     The `-ff90' option controls the interpretation of this construct.

     *Note Ugly Complex Part Extraction::, for more information.

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

     *Note Ugly Conversion of Initializers::, for more information.

`-fugly-logint'
     Treat `INTEGER' and `LOGICAL' variables and expressions as
     potential stand-ins for each other.

     For example, automatic conversion between `INTEGER' and `LOGICAL'
     is enabled, for many contexts, via this option.

     *Note Ugly Integer Conversions::, for more information.

`-fonetrip'
     Executable iterative `DO' loops are to be executed at least once
     each time they are reached.

     ANSI FORTRAN 77 and more recent versions of the Fortran standard
     specify that the body of an iterative `DO' loop is not executed if
     the number of iterations calculated from the parameters of the
     loop is less than 1.  (For example, `DO 10 I = 1, 0'.)  Such a
     loop is called a "zero-trip loop".

     Prior to ANSI FORTRAN 77, many compilers implemented `DO' loops
     such that the body of a loop would be executed at least once, even
     if the iteration count was zero.  Fortran code written assuming
     this behavior is said to require "one-trip loops".  For example,
     some code written to the FORTRAN 66 standard expects this behavior
     from its `DO' loops, although that standard did not specify this
     behavior.

     The `-fonetrip' option specifies that the source file(s) being
     compiled require one-trip loops.

     This option affects only those loops specified by the (iterative)
     `DO' statement and by implied-`DO' lists in I/O statements.  Loops
     specified by implied-`DO' lists in `DATA' and specification
     (non-executable) statements are not affected.

`-ftypeless-boz'
     Specifies that prefix-radix non-decimal constants, such as
     `Z'ABCD'', are typeless instead of `INTEGER(KIND=1)'.

     You can test for yourself whether a particular compiler treats the
     prefix form as `INTEGER(KIND=1)' or typeless by running the
     following program:

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

     Reports indicate that many compilers process this form as
     `INTEGER(KIND=1)', though a few as typeless, and at least one
     based on a command-line option specifying some kind of
     compatibility.

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

`-fbadu77-intrinsics-delete'

`-fbadu77-intrinsics-hide'

`-fbadu77-intrinsics-disable'

`-fbadu77-intrinsics-enable'
     Specify status of UNIX intrinsics having inappropriate forms.
     `-fbadu77-intrinsics-enable' is the default.  *Note Intrinsic
     Groups::.

`-ff2c-intrinsics-delete'

`-ff2c-intrinsics-hide'

`-ff2c-intrinsics-disable'

`-ff2c-intrinsics-enable'
     Specify status of f2c-specific intrinsics.
     `-ff2c-intrinsics-enable' is the default.  *Note Intrinsic
     Groups::.

`-ff90-intrinsics-delete'

`-ff90-intrinsics-hide'

`-ff90-intrinsics-disable'

`-ff90-intrinsics-enable'
     Specify status of F90-specific intrinsics.
     `-ff90-intrinsics-enable' is the default.  *Note Intrinsic
     Groups::.

`-fgnu-intrinsics-delete'

`-fgnu-intrinsics-hide'

`-fgnu-intrinsics-disable'

`-fgnu-intrinsics-enable'
     Specify status of Digital's COMPLEX-related intrinsics.
     `-fgnu-intrinsics-enable' is the default.  *Note Intrinsic
     Groups::.

`-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.  *Note Intrinsic
     Groups::.

`-funix-intrinsics-delete'

`-funix-intrinsics-hide'

`-funix-intrinsics-disable'

`-funix-intrinsics-enable'
     Specify status of UNIX intrinsics.  `-funix-intrinsics-enable' is
     the default.  *Note Intrinsic Groups::.

`-fvxt-intrinsics-delete'

`-fvxt-intrinsics-hide'

`-fvxt-intrinsics-disable'

`-fvxt-intrinsics-enable'
     Specify status of VXT intrinsics.  `-fvxt-intrinsics-enable' is
     the default.  *Note Intrinsic Groups::.

`-ffixed-line-length-N'
     Set column after which characters are ignored in typical fixed-form
     lines in the source file, and through which spaces are assumed (as
     if padded to that length) after the ends of short fixed-form lines.

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

     *Note Source Form::, for more information.


File: g77.info,  Node: Warning Options,  Next: Debugging Options,  Prev: Fortran Dialect Options,  Up: Invoking G77

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

`-w'
     Inhibit all warning messages.

`-Wno-globals'
     Inhibit warnings about use of a name as both a global name (a
     subroutine, function, or block data program unit, or a common
     block) and implicitly as the name of an intrinsic in a source file.

     Also inhibit warnings about inconsistent invocations and/or
     definitions of global procedures (function and subroutines).  Such
     inconsistencies include different numbers of arguments and
     different types of arguments.

`-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
     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 might 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 = 9.4
          ...
          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 resulting from 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.

          An example of an expression producing different results in a
          surprising way is `-I*S', where I holds the value
          `-2147483648' and S holds `0.5'.  On many systems, negating I
          results in the same value, not a positive number, because it
          is already the lower bound of what an `INTEGER(KIND=1)'
          variable can hold.  So, the expression evaluates to a
          positive number, while the "expected" interpretation,
          `(-I)*S', would evaluate to a negative number.

          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' 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, if optimization is specified via
     `-O', the `-Wuninitialized' 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'

`-Wswitch-default'

`-Wswitch-enum'

`-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: g77.info,  Node: Debugging Options,  Next: Optimize Options,  Prev: Warning Options,  Up: Invoking G77

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

     A sample debugging session looks like this (note the use of the
     breakpoint):
          $ cat gdb.f
                PROGRAM PROG
                DIMENSION A(10)
                DATA A /1.,2.,3.,4.,5.,6.,7.,8.,9.,10./
                A(5) = 4.
                PRINT*,A
                END
          $ g77 -g -O gdb.f
          $ gdb a.out
          ...
          (gdb) break MAIN__
          Breakpoint 1 at 0x8048e96: file gdb.f, line 4.
          (gdb) run
          Starting program: /home/toon/g77-bugs/./a.out
          Breakpoint 1, MAIN__ () at gdb.f:4
          4             A(5) = 4.
          Current language:  auto; currently fortran
          (gdb) print a(5)
          $1 = 5
          (gdb) step
          5             PRINT*,A
          (gdb) print a(5)
          $2 = 4
          ...
     One could also add the setting of the breakpoint and the first run
     command to the file `.gdbinit' in the current directory, to
     simplify the debugging session.

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


File: g77.info,  Node: Optimize Options,  Next: Preprocessor Options,  Prev: Debugging Options,  Up: Invoking G77

5.7 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.  However, note that certain
diagnostics--such as for uninitialized variables--depend on the flow
analysis done by `-O', i.e. you must use `-O' or `-O2' to get such
diagnostics.

   The following flags have particular applicability when compiling
Fortran programs:

`-malign-double'
     (Intel x86 architecture only.)

     Noticeably improves performance of `g77' programs making heavy use
     of `REAL(KIND=2)' (`DOUBLE PRECISION') data on some systems.  In
     particular, systems using Pentium, Pentium Pro, 586, and 686
     implementations of the i386 architecture execute programs faster
     when `REAL(KIND=2)' (`DOUBLE PRECISION') data are aligned on
     64-bit boundaries in memory.

     This option can, at least, make benchmark results more consistent
     across various system configurations, versions of the program, and
     data sets.

     _Note:_ The warning in the `gcc' documentation about this option
     does not apply, generally speaking, to Fortran code compiled by
     `g77'

     *Note Aligned Data::, for more information on alignment issues.

     _Also also note:_ The negative form of `-malign-double' is
     `-mno-align-double', not `-benign-double'.

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

     This option is effective when the floating-point unit is set to
     work in IEEE 854 `extended precision'--as it typically is on x86
     and m68k GNU systems--rather than IEEE 754 double precision.
     `-ffloat-store' tries to remove the extra precision by spilling
     data from floating-point registers into memory and this typically
     involves a big performance hit.  However, it doesn't affect
     intermediate results, so that it is only partially effective.
     `Excess precision' is avoided in code like:
          a = b + c
          d = a * e
     but not in code like:
                d = (b + c) * e

     For another, potentially better, way of controlling the precision,
     see *Note Floating-point precision::.

`-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.  Sets
     `-funsafe-math-optimizations', `-ffinite-math-only', and
     `-fno-trapping-math'.

`-funsafe-math-optimizations'
     Allow optimizations that may be give incorrect results for certain
     IEEE inputs.

`-ffinite-math-only'
     Allow optimizations for floating-point arithmetic that assume that
     arguments and results are not NaNs or +-Infs.

     This option should never be turned on by any `-O' option since it
     can result in incorrect output for programs which depend on an
     exact implementation of IEEE or ISO rules/specifications.

     The default is `-fno-finite-math-only'.

`-fno-trapping-math'
     Allow the compiler to assume that floating-point arithmetic will
     not generate traps on any inputs.  This is useful, for example,
     when running a program using IEEE "non-stop" floating-point
     arithmetic.

`-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'
     Typically improves performance on code using iterative `DO' loops
     by unrolling them and is probably generally appropriate for
     Fortran, though it is not turned on at any optimization level.
     Note that outer loop unrolling isn't done specifically; decisions
     about whether to unroll a loop are made on the basis of its
     instruction count.

     Also, no `loop discovery'(1) is done, so only loops written with
     `DO' benefit from loop optimizations, including--but not limited
     to--unrolling.  Loops written with `IF' and `GOTO' are not
     currently recognized as such.  This option unrolls only iterative
     `DO' loops, not `DO WHILE' loops.

`-funroll-all-loops'
     Probably improves performance on code using `DO WHILE' loops by
     unrolling them in addition to iterative `DO' loops.  In the absence
     of `DO WHILE', this option is equivalent to `-funroll-loops' but
     possibly slower.

`-fno-move-all-movables'

`-fno-reduce-all-givs'

`-fno-rerun-loop-opt'
     In general, the optimizations enabled with these options will lead
     to faster code being generated by GNU Fortran; hence they are
     enabled by default when issuing the `g77' command.

     `-fmove-all-movables' and `-freduce-all-givs' will enable loop
     optimization to move all loop-invariant index computations in
     nested loops over multi-rank array dummy arguments out of these
     loops.

     `-frerun-loop-opt' will move offset calculations resulting from
     the fact that Fortran arrays by default have a lower bound of 1
     out of the loops.

     These three options are intended to be removed someday, once loop
     optimization is sufficiently advanced to perform all those
     transformations without help from these options.

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

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

   (1) "loop discovery" refers to the process by which a compiler, or
indeed any reader of a program, determines which portions of the
program are more likely to be executed repeatedly as it is being run.
Such discovery typically is done early when compiling using
optimization techniques, so the "discovered" loops get more
attention--and more run-time resources, such as registers--from the
compiler.  It is easy to "discover" loops that are constructed out of
looping constructs in the language (such as Fortran's `DO').  For some
programs, "discovering" loops constructed out of lower-level constructs
(such as `IF' and `GOTO') can lead to generation of more optimal code
than otherwise.


File: g77.info,  Node: Preprocessor Options,  Next: Directory Options,  Prev: Optimize Options,  Up: Invoking G77

5.8 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'
directive.  Since this directive 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' directive.

   However, the `INCLUDE' directive does not apply preprocessing to the
contents of the included file itself.

   Therefore, any file that contains preprocessor directives (such as
`#include', `#define', and `#if') must be included via the `#include'
directive, not via the `INCLUDE' directive.  Therefore, any file
containing preprocessor directives, if included, is necessarily
included by a file that itself contains preprocessor directives.


File: g77.info,  Node: Directory Options,  Next: Code Gen Options,  Prev: Preprocessor Options,  Up: Invoking G77

5.9 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 preprocessor is used.

   Some of these options also affect how `g77' searches for files
specified via the `INCLUDE' directive, although files included by that
directive are not, themselves, preprocessed.  These options are:

`-I-'

`-IDIR'
     These affect interpretation of the `INCLUDE' directive (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 Options, for
     information on the `-I' option.


File: g77.info,  Node: Code Gen Options,  Next: Environment Variables,  Prev: Directory Options,  Up: Invoking G77

5.10 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' use the GNU calling conventions instead.

     The `f2c' calling conventions require functions that return type
     `REAL(KIND=1)' to actually return the C type `double', and
     functions that return type `COMPLEX' to return the values via an
     extra argument in the calling sequence that points to where to
     store the return value.  Under the GNU calling conventions, such
     functions simply return their results as they would in GNU
     C--`REAL(KIND=1)' functions return the C type `float', and
     `COMPLEX' functions return the GNU C type `complex' (or its
     `struct' equivalent).

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

     However, because the `libg2c' library uses `f2c' calling
     conventions, `g77' rejects attempts to pass intrinsics implemented
     by routines in this library as actual arguments when `-fno-f2c' is
     used, to avoid bugs when they are actually called by code
     expecting the GNU calling conventions to work.

     For example, `INTRINSIC ABS;CALL FOO(ABS)' is rejected when
     `-fno-f2c' is in force.  (Future versions of the `g77' run-time
     library might offer routines that provide GNU-callable versions of
     the routines that implement the `f2c' intrinsics that may be
     passed as actual arguments, so that valid programs need not be
     rejected when `-fno-f2c' is used.)

     *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 `libg2c' (or the original `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.  The `-fno-second-underscore' option disables appending of
     the second underscore in all cases.)

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

`-femulate-complex'
     Implement `COMPLEX' arithmetic via emulation, instead of using the
     facilities of the `gcc' back end that provide direct support of
     `complex' arithmetic.

     (`gcc' had some bugs in its back-end support for `complex'
     arithmetic, due primarily to the support not being completed as of
     version 2.8.1 and `egcs' 1.1.2.)

     Use `-femulate-complex' if you suspect code-generation bugs, or
     experience compiler crashes, that might result from `g77' using
     the `COMPLEX' support in the `gcc' back end.  If using that option
     fixes the bugs or crashes you are seeing, that indicates a likely
     `g77' bugs (though, all compiler crashes are considered bugs), so,
     please report it.  (Note that the known bugs, now believed fixed,
     produced compiler crashes rather than causing the generation of
     incorrect code.)

     Use of this option should not affect how Fortran code compiled by
     `g77' works in terms of its interfaces to other code, e.g. that
     compiled by `f2c'

     As of GCC version 3.0, this option is not necessary anymore.

     _Caution:_ Future versions of `g77' might ignore both forms of
     this option.

`-falias-check'

`-fargument-alias'

`-fargument-noalias'

`-fno-argument-noalias-global'
     _Version info:_ These options are not supported by versions of
     `g77' based on `gcc' version 2.8.

     These options specify to what degree aliasing (overlap) is
     permitted between arguments (passed as pointers) and `COMMON'
     (external, or public) storage.

     The default for Fortran code, as mandated by the FORTRAN 77 and
     Fortran 90 standards, is `-fargument-noalias-global'.  The default
     for code written in the C language family is `-fargument-alias'.

     Note that, on some systems, compiling with `-fforce-addr' in
     effect can produce more optimal code when the default aliasing
     options are in effect (and when optimization is enabled).

     *Note Aliasing Assumed To Work::, for detailed information on the
     implications of compiling Fortran code that depends on the ability
     to alias dummy arguments.

`-fno-globals'
     Disable diagnostics about inter-procedural analysis problems, such
     as disagreements about the type of a function or a procedure's
     argument, that might cause a compiler crash when attempting to
     inline a reference to a procedure within a program unit.  (The
     diagnostics themselves are still produced, but as warnings, unless
     `-Wno-globals' is specified, in which case no relevant diagnostics
     are produced.)

     Further, this option disables such inlining, to avoid compiler
     crashes resulting from incorrect code that would otherwise be
     diagnosed.

     As such, this option might be quite useful when compiling
     existing, "working" code that happens to have a few bugs that do
     not generally show themselves, but which `g77' diagnoses.

     Use of this option therefore has the effect of instructing `g77'
     to behave more like it did up through version 0.5.19.1, when it
     paid little or no attention to disagreements between program units
     about a procedure's type and argument information, and when it
     performed no inlining of procedures (except statement functions).

     Without this option, `g77' defaults to performing the potentially
     inlining procedures as it started doing in version 0.5.20, but as
     of version 0.5.21, it also diagnoses disagreements that might
     cause such inlining to crash the compiler as (fatal) errors, and
     warns about similar disagreements that are currently believed to
     not likely to result in the compiler later crashing or producing
     incorrect code.

`-fflatten-arrays'
     Use back end's C-like constructs (pointer plus offset) instead of
     its `ARRAY_REF' construct to handle all array references.

     _Note:_ This option is not supported.  It is intended for use only
     by `g77' developers, to evaluate code-generation issues.  It might
     be removed at any time.

`-fbounds-check'
`-ffortran-bounds-check'
     Enable generation of run-time checks for array subscripts and
     substring start and end points against the (locally) declared
     minimum and maximum values.

     The current implementation uses the `libf2c' library routine
     `s_rnge' to print the diagnostic.

     However, whereas `f2c' generates a single check per reference for
     a multi-dimensional array, of the computed offset against the
     valid offset range (0 through the size of the array), `g77'
     generates a single check per _subscript_ expression.  This catches
     some cases of potential bugs that `f2c' does not, such as
     references to below the beginning of an assumed-size array.

     `g77' also generates checks for `CHARACTER' substring references,
     something `f2c' currently does not do.

     Use the new `-ffortran-bounds-check' option to specify
     bounds-checking for only the Fortran code you are compiling, not
     necessarily for code written in other languages.

     _Note:_ To provide more detailed information on the offending
     subscript, `g77' provides the `libg2c' run-time library routine
     `s_rnge' with somewhat differently-formatted information.  Here's
     a sample diagnostic:

          Subscript out of range on file line 4, procedure rnge.f/bf.
          Attempt to access the -6-th element of variable b[subscript-2-of-2].
          Aborted

     The above message indicates that the offending source line is line
     4 of the file `rnge.f', within the program unit (or statement
     function) named `bf'.  The offended array is named `b'.  The
     offended array dimension is the second for a two-dimensional array,
     and the offending, computed subscript expression was `-6'.

     For a `CHARACTER' substring reference, the second line has this
     appearance:

          Attempt to access the 11-th element of variable a[start-substring].

     This indicates that the offended `CHARACTER' variable or array is
     named `a', the offended substring position is the starting
     (leftmost) position, and the offending substring expression is
     `11'.

     (Though the verbage of `s_rnge' is not ideal for the purpose of
     the `g77' compiler, the above information should provide adequate
     diagnostic abilities to it users.)

   *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 `libg2c' 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 `libg2c' library, at the
     very least, even if it is built with the same option.


File: g77.info,  Node: Environment Variables,  Prev: Code Gen Options,  Up: Invoking G77

5.11 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 GCC: (gcc)Environment
Variables, for information on environment variables.


File: g77.info,  Node: News,  Next: Changes,  Prev: Invoking G77,  Up: Top

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

   Changes made to recent versions of GNU Fortran are listed below,
with the most recent version first.

   The changes are generally listed in order:

  1. Code-generation and run-time-library bug-fixes

  2. Compiler and run-time-library crashes involving valid code that
     have been fixed

  3. New features

  4. Fixes and enhancements to existing features

  5. New diagnostics

  6. Internal improvements

  7. Miscellany

   This order is not strict--for example, some items involve a
combination of these elements.

   Note that two variants of `g77' are tracked below.  The `egcs'
variant is described vis-a-vis previous versions of `egcs' and/or an
official FSF version, as appropriate.  Note that all such variants are
obsolete _as of July 1999_ - the information is retained here only for
its historical value.

   Therefore, `egcs' versions sometimes have multiple listings to help
clarify how they differ from other versions, though this can make
getting a complete picture of what a particular `egcs' version contains
somewhat more difficult.

   For information on bugs in the GCC-3.3.5 version of `g77', see *Note
Known Bugs In GNU Fortran: Known Bugs.

   An online, "live" version of this document (derived directly from
the mainline, development version of `g77' within `gcc') is available at
`http://gcc.gnu.org/onlinedocs/g77/News.html'.

   The following information was last updated on 2003-05-18:

In `GCC' 3.3 versus `GCC' 3.2:
==============================

   * Problem Reports fixed (in chronological order of submission):
    `1832'
          -list directed i/o overflow hangs, -fbounds-check doesn't
          detect

    `3924'
          g77 generates code which is rejected by GAS if COFF debugging
          info is requested

    `6286'
          Broken links on web pages

    `6367'
          (libf2c) multiple repeat counts confuse namelist read into
          array

    `6491'
          Logical operations error on logicals when using -fugly-logint

    `6742'
          Generation of C++ Prototype for FORTRAN and extern "C"

    `7113'
          Failure of g77.f-torture/execute/f90-intrinsic-bit.f -Os on
          irix6.5

    `7236'
          (libf2c) OPEN(...,RECL=nnn,...) without ACCESS='DIRECT'
          should assume a direct access file

    `7278'
          g77 "bug"; the executable misbehave (use of options -O2
          -fno-automatic gave wrong results)

    `7384'
          (libf2c) DATE_AND_TIME milliseconds field inactive on Windows

    `7388'
          Incorrect output with 0-based array of characters

    `8587'
          Double complex zero ** double precision number -> NaN instead
          of zero

    `9038'
          -ffixed-line-length-none -x f77-cpp-input gives: Warning:
          unknown register name line-length-none

    `9263'
          ICE caused by invalid PARAMETER in implied DO loop

    `10197'
          Direct access files not unformatted by default

    `10726'
          Documentation for function IDATE Intrinsic (UNIX) is wrong
          [fixed in 3.3.1].

   * Richard Henderson (<rth@redhat.com>) analyzed and improved the
     handling of (no-)aliasing information for dummy arguments and
     improved the optimization of induction variables in unrolled loops.

In `GCC' 3.2 versus `GCC' 3.1:
==============================

   * Problem Reports fixed (in chronological order of submission):
    `7681'
          ICE in compensate_edge, at reg-stack.c:2591

    `8308'
          gcc-3.x does not compile files with suffix .r (RATFOR) [Fixed
          in 3.2.1]

    `9258'
          [3.2/3.3/3.4 regression] ICE in compensate_edge, at
          reg-stack.c:2589

In `GCC' 3.1 (formerly known as g77-0.5.27) versus `GCC' 3.0:
=============================================================

   * Problem Reports fixed (in chronological order of submission):
    `947'
          Data statement initialization with subscript of kind INTEGER*2

    `3743'
          Reference to intrinsic `ISHFT' invalid

    `3807'
          Function BESJN(integer,double) problems

    `3957'
          g77 -pipe -xf77-cpp-input sends output to stdout

    `4279'
          g77 -h" gives bogus output

    `4730'
          ICE on valid input using CALL EXIT(%VAL(...))

    `4752'
          g77 -v -c -xf77-version /dev/null -xnone causes ice

    `4885'
          BACKSPACE example that doesn't work as of gcc/g77-3.0.x

    `5122'
          g77 rejects accepted use of INTEGER*2 as type of DATA
          statement loop index

    `5397'
          ICE on compiling source with 540 000 000 REAL array

    `5473'
          ICE on BESJN(integer*8,real)

    `5837'
          bug in loop unrolling

    `6106'
          sparc-sun-solaris2.7 gcc-3.1 extra g77 testsuite failures
          w/-m64

    `6138'
          Incorrect acces of integer*1 variables on PA

    `6304'
          Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2

   * `g77' now has its man page generated from the texinfo
     documentation, to guarantee that it remains up to date.

   * `g77' used to reject the following program on 32-bit targets:
          PROGRAM PROG
          DIMENSION A(140 000 000)
          END
     with the message:
          prog.f: In program `prog':
          prog.f:2:
                   DIMENSION A(140 000 000)
                             ^
          Array `a' at (^) is too large to handle
     because 140 000 000 REALs is larger than the largest bit-extent
     that can be expressed in 32 bits.  However, bit-sizes never play a
     role after offsets have been converted to byte addresses.
     Therefore this check has been removed, and the limit is now 2
     Gbyte of memory (around 530 000 000 REALs).  Note: On GNU/Linux
     systems one has to compile and link programs that occupy more than
     1 Gbyte statically, i.e. `g77 -static ...'.

   * Based on work done by Juergen Pfeifer (<juergen.pfeifer@gmx.net>)
     libf2c is now a shared library.  One can still link in all objects
     with the program by specifying the `-static' option.

   * Robert Anderson (<rwa@alumni.princeton.edu>) thought up a two line
     change that enables g77 to compile such code as:
          SUBROUTINE SUB(A, N)
          DIMENSION N(2)
          DIMENSION A(N(1),N(2))
          A(1,1) = 1.
          END
     Note the use of array elements in the bounds of the adjustable
     array A.

   * George Helffrich (<george@geo.titech.ac.jp>) implemented a change
     in substring index checking (when specifying `-fbounds-check')
     that permits the use of zero length substrings of the form
     `string(1:0)'.

   * Based on code developed by Pedro Vazquez
     (<vazquez@penelope.iqm.unicamp.br>), the `libf2c' library is now
     able to read and write files larger than 2 Gbyte on 32-bit target
     machines, if the operating system supports this.

In 0.5.26, `GCC' 3.0 versus `GCC' 2.95:
=======================================

   * When a REWIND was issued after a WRITE statement on an unformatted
     file, the implicit truncation was performed by copying the
     truncated file to /tmp and copying the result back.  This has been
     fixed by using the `ftruncate' OS function.  Thanks go to the
     GAMESS developers for bringing this to our attention.

   * Using options `-g', `-ggdb' or `-gdwarf[-2]' (where appropriate
     for your target) now also enables debugging information for COMMON
     BLOCK and EQUIVALENCE items to be emitted.  Thanks go to Andrew
     Vaught (<andy@xena.eas.asu.edu>) and George Helffrich
     (<george@geology.bristol.ac.uk>) for fixing this longstanding
     problem.

   * It is not necessary anymore to use the option `-femulate-complex'
     to compile Fortran code using COMPLEX arithmetic, even on 64-bit
     machines (like the Alpha).  This will improve code generation.

   * INTRINSIC arithmetic functions are now treated as routines that do
     not depend on anything but their argument(s).  This enables
     further instruction scheduling, because it is known that they
     cannot read or modify arbitrary locations.

   * Upgrade to `libf2c' as of 2000-12-05.

     This fixes a bug where a namelist containing initialization of
     LOGICAL items and a variable starting with T or F would be read
     incorrectly.

   * The `TtyNam' intrinsics now set NAME to all spaces (at run time)
     if the system has no `ttyname' implementation available.

   * Upgrade to `libf2c' as of 1999-06-28.

     This fixes a bug whereby input to a `NAMELIST' read involving a
     repeat count, such as `K(5)=10*3', was not properly handled by
     `libf2c'.  The first item was written to `K(5)', but the remaining
     nine were written elsewhere (still within the array), not
     necessarily starting at `K(6)'.

In 0.5.25, `GCC' 2.95 (`EGCS' 1.2) versus `EGCS' 1.1.2:
=======================================================

   * `g77' no longer generates bad code for assignments, or other
     conversions, of `REAL' or `COMPLEX' constant expressions to type
     `INTEGER(KIND=2)' (often referred to as `INTEGER*8').

     For example, `INTEGER*8 J; J = 4E10' now works as documented.

   * `g77' no longer truncates `INTEGER(KIND=2)' (usually `INTEGER*8')
     subscript expressions when evaluating array references on systems
     with pointers widers than `INTEGER(KIND=1)' (such as Alphas).

   * `g77' no longer generates bad code for an assignment to a
     `COMPLEX' variable or array that partially overlaps one or more of
     the sources of the same assignment (a very rare construction).  It
     now assigns through a temporary, in cases where such partial
     overlap is deemed possible.

   * `libg2c' (`libf2c') no longer loses track of the file being worked
     on during a `BACKSPACE' operation.

   * `libg2c' (`libf2c') fixes a bug whereby input to a `NAMELIST' read
     involving a repeat count, such as `K(5)=10*3', was not properly
     handled by `libf2c'.  The first item was written to `K(5)', but
     the remaining nine were written elsewhere (still within the array),
     not necessarily starting at `K(6)'.

   * Automatic arrays now seem to be working on HP-UX systems.

   * The `Date' intrinsic now returns the correct result on big-endian
     systems.

   * Fix `g77' so it no longer crashes when compiling I/O statements
     using keywords that define `INTEGER' values, such as `IOSTAT=J',
     where J is other than default `INTEGER' (such as `INTEGER*2').
     Instead, it issues a diagnostic.

   * Fix `g77' so it properly handles `DATA A/RPT*VAL/', where RPT is
     not default `INTEGER', such as `INTEGER*2', instead of producing a
     spurious diagnostic.  Also fix `DATA (A(I),I=1,N)', where `N' is
     not default `INTEGER' to work instead of crashing `g77'.

   * The `-ax' option is now obeyed when compiling Fortran programs.
     (It is passed to the `f771' driver.)

   * The new `-fbounds-check' option causes `g77' to compile run-time
     bounds checks of array subscripts, as well as of substring start
     and end points.

   * `libg2c' now supports building as multilibbed library, which
     provides better support for systems that require options such as
     `-mieee' to work properly.

   * Source file names with the suffixes `.FOR' and `.FPP' now are
     recognized by `g77' as if they ended in `.for' and `.fpp',
     respectively.

   * The order of arguments to the _subroutine_ forms of the `CTime',
     `DTime', `ETime', and `TtyNam' intrinsics has been swapped.  The
     argument serving as the returned value for the corresponding
     function forms now is the _second_ argument, making these
     consistent with the other subroutine forms of `libU77' intrinsics.

   * `g77' now warns about a reference to an intrinsic that has an
     interface that is not Year 2000 (Y2K) compliant.  Also, `libg2c'
     has been changed to increase the likelihood of catching references
     to the implementations of these intrinsics using the `EXTERNAL'
     mechanism (which would avoid the new warnings).

     *Note Year 2000 (Y2K) Problems::, for more information.

   * `g77' now warns about a reference to a function when the
     corresponding _subsequent_ function program unit disagrees with
     the reference concerning the type of the function.

   * `-fno-emulate-complex' is now the default option.  This should
     result in improved performance of code that uses the `COMPLEX'
     data type.

   * The `-malign-double' option now reliably aligns _all_
     double-precision variables and arrays on Intel x86 targets.

   * Even without the `-malign-double' option, `g77' reliably aligns
     local double-precision variables that are not in `EQUIVALENCE'
     areas and not `SAVE''d.

   * `g77' now open-codes ("inlines") division of `COMPLEX' operands
     instead of generating a run-time call to the `libf2c' routines
     `c_div' or `z_div', unless the `-Os' option is specified.

   * `g77' no longer generates code to maintain `errno', a C-language
     concept, when performing operations such as the `SqRt' intrinsic.

   * `g77' developers can temporarily use the `-fflatten-arrays' option
     to compare how the compiler handles code generation using C-like
     constructs as compared to the Fortran-like method constructs
     normally used.

   * A substantial portion of the `g77' front end's code-generation
     component was rewritten.  It now generates code using facilities
     more robustly supported by the `gcc' back end.  One effect of this
     rewrite is that some codes no longer produce a spurious "label LAB
     used before containing binding contour" message.

   * Support for the `-fugly' option has been removed.

   * Improve documentation and indexing, including information on Year
     2000 (Y2K) compliance, and providing more information on internals
     of the front end.

   * Upgrade to `libf2c' as of 1999-05-10.

In 0.5.24 versus 0.5.23:
========================

There is no `g77' version 0.5.24 at this time, or planned.  0.5.24 is
the version number designated for bug fixes and, perhaps, some new
features added, to 0.5.23.  Version 0.5.23 requires `gcc' 2.8.1, as
0.5.24 was planned to require.

   Due to `EGCS' becoming `GCC' (which is now an acronym for "GNU
Compiler Collection"), and `EGCS' 1.2 becoming officially designated
`GCC' 2.95, there seems to be no need for an actual 0.5.24 release.

   To reduce the confusion already resulting from use of 0.5.24 to
designate `g77' versions within `EGCS' versions 1.0 and 1.1, as well as
in versions of `g77' documentation and notices during that period,
"mainline" `g77' version numbering resumes at 0.5.25 with `GCC' 2.95
(`EGCS' 1.2), skipping over 0.5.24 as a placeholder version number.

   To repeat, there is no `g77' 0.5.24, but there is now a 0.5.25.
Please remain calm and return to your keypunch units.

In `EGCS' 1.1.2 versus `EGCS' 1.1.1:
====================================

   * Fix the `IDate' intrinsic (VXT) (in `libg2c') so the returned year
     is in the documented, non-Y2K-compliant range of 0-99, instead of
     being returned as 100 in the year 2000.

     *Note IDate Intrinsic (VXT)::, for more information.

   * Fix the `Date_and_Time' intrinsic (in `libg2c') to return the
     milliseconds value properly in VALUES(8).

   * Fix the `LStat' intrinsic (in `libg2c') to return device-ID
     information properly in SARRAY(7).

   * Improve documentation.

In `EGCS' 1.1.1 versus `EGCS' 1.1:
==================================

   * Fix `libg2c' so it performs an implicit `ENDFILE' operation (as
     appropriate) whenever a `REWIND' is done.

     (This bug was introduced in 0.5.23 and `egcs' 1.1 in `g77''s
     version of `libf2c'.)

   * Fix `libg2c' so it no longer crashes with a spurious diagnostic
     upon doing any I/O following a direct formatted write.

     (This bug was introduced in 0.5.23 and `egcs' 1.1 in `g77''s
     version of `libf2c'.)

   * Fix `g77' so it no longer crashes compiling references to the
     `Rand' intrinsic on some systems.

   * Fix `g77' portion of installation process so it works better on
     some systems (those with shells requiring `else true' clauses on
     `if' constructs for the completion code to be set properly).

In `EGCS' 1.1 versus `EGCS' 1.0.3:
==================================

   * Fix bugs in the `libU77' intrinsic `HostNm' that wrote one byte
     beyond the end of its `CHARACTER' argument, and in the `libU77'
     intrinsics `GMTime' and `LTime' that overwrote their arguments.

   * Assumed arrays with negative bounds (such as `REAL A(-1:*)') no
     longer elicit spurious diagnostics from `g77', even on systems
     with pointers having different sizes than integers.

     This bug is not known to have existed in any recent version of
     `gcc'.  It was introduced in an early release of `egcs'.

   * Valid combinations of `EXTERNAL', passing that external as a dummy
     argument without explicitly giving it a type, and, in a subsequent
     program unit, referencing that external as an external function
     with a different type no longer crash `g77'.

   * `CASE DEFAULT' no longer crashes `g77'.

   * The `-Wunused' option no longer issues a spurious warning about
     the "master" procedure generated by `g77' for procedures
     containing `ENTRY' statements.

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * `g77' no longer installs the `f77' command and `f77.1' man page in
     the `/usr' or `/usr/local' hierarchy, even if the `f77-install-ok'
     file exists in the source or build directory.  See the
     installation documentation for more information.

   * `g77' no longer installs the `libf2c.a' library and `f2c.h'
     include file in the `/usr' or `/usr/local' hierarchy, even if the
     `f2c-install-ok' or `f2c-exists-ok' files exist in the source or
     build directory.  See the installation documentation for more
     information.

   * The `libf2c.a' library produced by `g77' has been renamed to
     `libg2c.a'.  It is installed only in the `gcc' "private" directory
     hierarchy, `gcc-lib'.  This allows system administrators and users
     to choose which version of the `libf2c' library from `netlib' they
     wish to use on a case-by-case basis.  See the installation
     documentation for more information.

   * The `f2c.h' include (header) file produced by `g77' has been
     renamed to `g2c.h'.  It is installed only in the `gcc' "private"
     directory hierarchy, `gcc-lib'.  This allows system administrators
     and users to choose which version of the include file from
     `netlib' they wish to use on a case-by-case basis.  See the
     installation documentation for more information.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * During the configuration and build process, `g77' creates
     subdirectories it needs only as it needs them.  Other cleaning up
     of the configuration and build process has been performed as well.

   * `install-info' now used to update the directory of Info
     documentation to contain an entry for `g77' (during installation).

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.

   * Improve compilation of `FORMAT' expressions so that a null byte is
     appended to the last operand if it is a constant.  This provides a
     cleaner run-time diagnostic as provided by `libf2c' for statements
     like `PRINT '(I1', 42'.

   * Improve documentation and indexing.

   * The upgrade to `libf2c' as of 1998-06-18 should fix a variety of
     problems, including those involving some uses of the `T' format
     specifier, and perhaps some build (porting) problems as well.

In `EGCS' 1.1 versus `g77' 0.5.23:
==================================

   * Fix a code-generation bug that afflicted Intel x86 targets when
     `-O2' was specified compiling, for example, an old version of the
     `DNRM2' routine.

     The x87 coprocessor stack was being mismanaged in cases involving
     assigned `GOTO' and `ASSIGN'.

   * `g77' no longer produces incorrect code and initial values for
     `EQUIVALENCE' and `COMMON' aggregates that, due to "unnatural"
     ordering of members vis-a-vis their types, require initial padding.

   * Fix `g77' crash compiling code containing the construct
     `CMPLX(0.)' or similar.

   * `g77' no longer crashes when compiling code containing
     specification statements such as `INTEGER(KIND=7) PTR'.

   * `g77' no longer crashes when compiling code such as `J = SIGNAL(1,
     2)'.

   * `g77' now treats `%LOC(EXPR)' and `LOC(EXPR)' as "ordinary"
     expressions when they are used as arguments in procedure calls.
     This change applies only to global (filewide) analysis, making it
     consistent with how `g77' actually generates code for these cases.

     Previously, `g77' treated these expressions as denoting special
     "pointer" arguments for the purposes of filewide analysis.

   * Fix `g77' crash (or apparently infinite run-time) when compiling
     certain complicated expressions involving `COMPLEX' arithmetic
     (especially multiplication).

   * Align static double-precision variables and arrays on Intel x86
     targets regardless of whether `-malign-double' is specified.

     Generally, this affects only local variables and arrays having the
     `SAVE' attribute or given initial values via `DATA'.

   * The `g77' driver now ensures that `-lg2c' is specified in the link
     phase prior to any occurrence of `-lm'.  This prevents
     accidentally linking to a routine in the SunOS4 `-lm' library when
     the generated code wants to link to the one in `libf2c' (`libg2c').

   * `g77' emits more debugging information when `-g' is used.

     This new information allows, for example, `which __g77_length_a'
     to be used in `gdb' to determine the type of the phantom length
     argument supplied with `CHARACTER' variables.

     This information pertains to internally-generated type, variable,
     and other information, not to the longstanding deficiencies
     vis-a-vis `COMMON' and `EQUIVALENCE'.

   * The F90 `Date_and_Time' intrinsic now is supported.

   * The F90 `System_Clock' intrinsic allows the optional arguments
     (except for the `Count' argument) to be omitted.

   * Upgrade to `libf2c' as of 1998-06-18.

   * Improve documentation and indexing.

In 0.5.23 versus 0.5.22:
========================

   * This release contains several regressions against version 0.5.22
     of `g77', due to using the "vanilla" `gcc' back end instead of
     patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for `__restrict__' keyword, the options
          `-fargument-alias', `-fargument-noalias', and
          `-fargument-noalias-global', and the corresponding
          alias-analysis code.

          (`egcs' has the alias-analysis code, but not the
          `__restrict__' keyword.  `egcs' `g77' users benefit from the
          alias-analysis code despite the lack of the `__restrict__'
          keyword, which is a C-language construct.)

        - Support for the GNU compiler options `-fmove-all-movables',
          `-freduce-all-givs', and `-frerun-loop-opt'.

          (`egcs' supports these options.  `g77' users of `egcs'
          benefit from them even if they are not explicitly specified,
          because the defaults are optimized for `g77' users.)

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

     Note that the `gcc/f/gbe/' subdirectory has been removed from this
     distribution as a result of `g77' no longer including patches for
     the `gcc' back end.

   * Fix bugs in the `libU77' intrinsic `HostNm' that wrote one byte
     beyond the end of its `CHARACTER' argument, and in the `libU77'
     intrinsics `GMTime' and `LTime' that overwrote their arguments.

   * Support `gcc' version 2.8, and remove support for prior versions
     of `gcc'.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * `CASE DEFAULT' no longer crashes `g77'.

   * Valid combinations of `EXTERNAL', passing that external as a dummy
     argument without explicitly giving it a type, and, in a subsequent
     program unit, referencing that external as an external function
     with a different type no longer crash `g77'.

   * `g77' no longer installs the `f77' command and `f77.1' man page in
     the `/usr' or `/usr/local' hierarchy, even if the `f77-install-ok'
     file exists in the source or build directory.  See the
     installation documentation for more information.

   * `g77' no longer installs the `libf2c.a' library and `f2c.h'
     include file in the `/usr' or `/usr/local' hierarchy, even if the
     `f2c-install-ok' or `f2c-exists-ok' files exist in the source or
     build directory.  See the installation documentation for more
     information.

   * The `libf2c.a' library produced by `g77' has been renamed to
     `libg2c.a'.  It is installed only in the `gcc' "private" directory
     hierarchy, `gcc-lib'.  This allows system administrators and users
     to choose which version of the `libf2c' library from `netlib' they
     wish to use on a case-by-case basis.  See the installation
     documentation for more information.

   * The `f2c.h' include (header) file produced by `g77' has been
     renamed to `g2c.h'.  It is installed only in the `gcc' "private"
     directory hierarchy, `gcc-lib'.  This allows system administrators
     and users to choose which version of the include file from
     `netlib' they wish to use on a case-by-case basis.  See the
     installation documentation for more information.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * The `-Wunused' option no longer issues a spurious warning about
     the "master" procedure generated by `g77' for procedures
     containing `ENTRY' statements.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * During the configuration and build process, `g77' creates
     subdirectories it needs only as it needs them, thus avoiding
     unnecessary creation of, for example, `stage1/f/runtime' when
     doing a non-bootstrap build.  Other cleaning up of the
     configuration and build process has been performed as well.

   * `install-info' now used to update the directory of Info
     documentation to contain an entry for `g77' (during installation).

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.

   * Improve documentation and indexing.

   * Upgrade to `libf2c' as of 1998-04-20.

     This should fix a variety of problems, including those involving
     some uses of the `T' format specifier, and perhaps some build
     (porting) problems as well.

In 0.5.22 versus 0.5.21:
========================

   * Fix code generation for iterative `DO' loops that have one or more
     references to the iteration variable, or to aliases of it, in
     their control expressions.  For example, `DO 10 J=2,J' now is
     compiled correctly.

   * Fix a code-generation bug that afflicted Intel x86 targets when
     `-O2' was specified compiling, for example, an old version of the
     `DNRM2' routine.

     The x87 coprocessor stack was being mismanaged in cases involving
     assigned `GOTO' and `ASSIGN'.

   * Fix `DTime' intrinsic so as not to truncate results to integer
     values (on some systems).

   * Fix `Signal' intrinsic so it offers portable support for 64-bit
     systems (such as Digital Alphas running GNU/Linux).

   * Fix run-time crash involving `NAMELIST' on 64-bit machines such as
     Alphas.

   * Fix `g77' version of `libf2c' so it no longer produces a spurious
     `I/O recursion' diagnostic at run time when an I/O operation (such
     as `READ *,I') is interrupted in a manner that causes the program
     to be terminated via the `f_exit' routine (such as via `C-c').

   * Fix `g77' crash triggered by `CASE' statement with an omitted
     lower or upper bound.

   * Fix `g77' crash compiling references to `CPU_Time' intrinsic.

   * Fix `g77' crash (or apparently infinite run-time) when compiling
     certain complicated expressions involving `COMPLEX' arithmetic
     (especially multiplication).

   * Fix `g77' crash on statements such as `PRINT *,
     (REAL(Z(I)),I=1,2)', where `Z' is `DOUBLE COMPLEX'.

   * Fix a `g++' crash.

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Fix a profiling-related bug in `gcc' back end for Intel x86
     architecture.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * Rename the `gcc' keyword `restrict' to `__restrict__', to avoid
     rejecting valid, existing, C programs.  Support for `restrict' is
     now more like support for `complex'.

   * Fix `-fpedantic' to not reject procedure invocations such as
     `I=J()' and `CALL FOO()'.

   * Fix `-fugly-comma' to affect invocations of only external
     procedures.  Restore rejection of gratuitous trailing omitted
     arguments to intrinsics, as in `I=MAX(3,4,,)'.

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

   * Improve diagnostic messages from `libf2c' so it is more likely
     that the printing of the active format string is limited to the
     string, with no trailing garbage being printed.

     (Unlike `f2c', `g77' did not append a null byte to its compiled
     form of every format string specified via a `FORMAT' statement.
     However, `f2c' would exhibit the problem anyway for a statement
     like `PRINT '(I)garbage', 1' by printing `(I)garbage' as the
     format string.)

   * Improve compilation of `FORMAT' expressions so that a null byte is
     appended to the last operand if it is a constant.  This provides a
     cleaner run-time diagnostic as provided by `libf2c' for statements
     like `PRINT '(I1', 42'.

   * Fix various crashes involving code with diagnosed errors.

   * Fix cross-compilation bug when configuring `libf2c'.

   * Improve diagnostics.

   * Improve documentation and indexing.

   * Upgrade to `libf2c' as of 1997-09-23.  This fixes a formatted-I/O
     bug that afflicted 64-bit systems with 32-bit integers (such as
     Digital Alpha running GNU/Linux).

In `EGCS' 1.0.2 versus `EGCS' 1.0.1:
====================================

   * Fix `g77' crash triggered by `CASE' statement with an omitted
     lower or upper bound.

   * Fix `g77' crash on statements such as `PRINT *,
     (REAL(Z(I)),I=1,2)', where `Z' is `DOUBLE COMPLEX'.

   * Fix `-fPIC' (such as compiling for ELF targets) on the Intel x86
     architecture target so invalid assembler code is no longer
     produced.

   * Fix `-fpedantic' to not reject procedure invocations such as
     `I=J()' and `CALL FOO()'.

   * Fix `-fugly-comma' to affect invocations of only external
     procedures.  Restore rejection of gratuitous trailing omitted
     arguments to intrinsics, as in `I=MAX(3,4,,)'.

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

In `EGCS' 1.0.1 versus `EGCS' 1.0:
==================================

   * Fix run-time crash involving `NAMELIST' on 64-bit machines such as
     Alphas.

In `EGCS' 1.0 versus `g77' 0.5.21:
==================================

   * Version 1.0 of `egcs' contains several regressions against version
     0.5.21 of `g77', due to using the "vanilla" `gcc' back end instead
     of patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for the C-language `restrict' keyword.

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

     Note that the `gcc/f/gbe/' subdirectory has been removed from this
     distribution as a result of `g77' being fully integrated with the
     `egcs' variant of the `gcc' back end.

   * Fix code generation for iterative `DO' loops that have one or more
     references to the iteration variable, or to aliases of it, in
     their control expressions.  For example, `DO 10 J=2,J' now is
     compiled correctly.

   * Fix `DTime' intrinsic so as not to truncate results to integer
     values (on some systems).

   * Some Fortran code, miscompiled by `g77' built on `gcc' version
     2.8.1 on m68k-next-nextstep3 configurations when using the `-O2'
     option, is now compiled correctly.  It is believed that a C
     function known to miscompile on that configuration when using the
     `-O2 -funroll-loops' options also is now compiled correctly.

   * Remove support for non-`egcs' versions of `gcc'.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

   * Improve diagnostic messages from `libf2c' so it is more likely
     that the printing of the active format string is limited to the
     string, with no trailing garbage being printed.

     (Unlike `f2c', `g77' did not append a null byte to its compiled
     form of every format string specified via a `FORMAT' statement.
     However, `f2c' would exhibit the problem anyway for a statement
     like `PRINT '(I)garbage', 1' by printing `(I)garbage' as the
     format string.)

   * Upgrade to `libf2c' as of 1997-09-23.  This fixes a formatted-I/O
     bug that afflicted 64-bit systems with 32-bit integers (such as
     Digital Alpha running GNU/Linux).

In 0.5.21:
==========

   * Fix a code-generation bug introduced by 0.5.20 caused by loop
     unrolling (by specifying `-funroll-loops' or similar).  This bug
     afflicted all code compiled by version 2.7.2.2.f.2 of `gcc' (C,
     C++, Fortran, and so on).

   * Fix a code-generation bug manifested when combining local
     `EQUIVALENCE' with a `DATA' statement that follows the first
     executable statement (or is treated as an executable-context
     statement as a result of using the `-fpedantic' option).

   * Fix a compiler crash that occurred when an integer division by a
     constant zero is detected.  Instead, when the `-W' option is
     specified, the `gcc' back end issues a warning about such a case.
     This bug afflicted all code compiled by version 2.7.2.2.f.2 of
     `gcc' (C, C++, Fortran, and so on).

   * Fix a compiler crash that occurred in some cases of procedure
     inlining.  (Such cases became more frequent in 0.5.20.)

   * Fix a compiler crash resulting from using `DATA' or similar to
     initialize a `COMPLEX' variable or array to zero.

   * Fix compiler crashes involving use of `AND', `OR', or `XOR'
     intrinsics.

   * Fix compiler bug triggered when using a `COMMON' or `EQUIVALENCE'
     variable as the target of an `ASSIGN' or assigned-`GOTO' statement.

   * Fix compiler crashes due to using the name of a some non-standard
     intrinsics (such as `FTell' or `FPutC') as such and as the name of
     a procedure or common block.  Such dual use of a name in a program
     is allowed by the standard.

   * Place automatic arrays on the stack, even if `SAVE' or the
     `-fno-automatic' option is in effect.  This avoids a compiler
     crash in some cases.

   * The `-malign-double' option now reliably aligns `DOUBLE PRECISION'
     optimally on Pentium and Pentium Pro architectures (586 and 686 in
     `gcc').

   * New option `-Wno-globals' disables warnings about "suspicious" use
     of a name both as a global name and as the implicit name of an
     intrinsic, and warnings about disagreements over the number or
     natures of arguments passed to global procedures, or the natures
     of the procedures themselves.

     The default is to issue such warnings, which are new as of this
     version of `g77'.

   * New option `-fno-globals' disables diagnostics about potentially
     fatal disagreements analysis problems, such as disagreements over
     the number or natures of arguments passed to global procedures, or
     the natures of those procedures themselves.

     The default is to issue such diagnostics and flag the compilation
     as unsuccessful.  With this option, the diagnostics are issued as
     warnings, or, if `-Wno-globals' is specified, are not issued at
     all.

     This option also disables inlining of global procedures, to avoid
     compiler crashes resulting from coding errors that these
     diagnostics normally would identify.

   * Diagnose cases where a reference to a procedure disagrees with the
     type of that procedure, or where disagreements about the number or
     nature of arguments exist.  This avoids a compiler crash.

   * Fix parsing bug whereby `g77' rejected a second initialization
     specification immediately following the first's closing `/' without
     an intervening comma in a `DATA' statement, and the second
     specification was an implied-DO list.

   * Improve performance of the `gcc' back end so certain complicated
     expressions involving `COMPLEX' arithmetic (especially
     multiplication) don't appear to take forever to compile.

   * Fix a couple of profiling-related bugs in `gcc' back end.

   * Integrate GNU Ada's (GNAT's) changes to the back end, which
     consist almost entirely of bug fixes.  These fixes are circa
     version 3.10p of GNAT.

   * Include some other `gcc' fixes that seem useful in `g77''s version
     of `gcc'.  (See `gcc/ChangeLog' for details--compare it to that
     file in the vanilla `gcc-2.7.2.3.tar.gz' distribution.)

   * Fix `libU77' routines that accept file and other names to strip
     trailing blanks from them, for consistency with other
     implementations.  Blanks may be forcibly appended to such names by
     appending a single null character (`CHAR(0)') to the significant
     trailing blanks.

   * Fix `CHMOD' intrinsic to work with file names that have embedded
     blanks, commas, and so on.

   * Fix `SIGNAL' intrinsic so it accepts an optional third `Status'
     argument.

   * Fix `IDATE()' intrinsic subroutine (VXT form) so it accepts
     arguments in the correct order.  Documentation fixed accordingly,
     and for `GMTIME()' and `LTIME()' as well.

   * Make many changes to `libU77' intrinsics to support existing code
     more directly.

     Such changes include allowing both subroutine and function forms
     of many routines, changing `MCLOCK()' and `TIME()' to return
     `INTEGER(KIND=1)' values, introducing `MCLOCK8()' and `TIME8()' to
     return `INTEGER(KIND=2)' values, and placing functions that are
     intended to perform side effects in a new intrinsic group,
     `badu77'.

   * Improve `libU77' so it is more portable.

   * Add options `-fbadu77-intrinsics-delete',
     `-fbadu77-intrinsics-hide', and so on.

   * Fix crashes involving diagnosed or invalid code.

   * `g77' and `gcc' now do a somewhat better job detecting and
     diagnosing arrays that are too large to handle before these cause
     diagnostics during the assembler or linker phase, a compiler
     crash, or generation of incorrect code.

   * Make some fixes to alias analysis code.

   * Add support for `restrict' keyword in `gcc' front end.

   * Support `gcc' version 2.7.2.3 (modified by `g77' into version
     2.7.2.3.f.1), and remove support for prior versions of `gcc'.

   * Incorporate GNAT's patches to the `gcc' back end into `g77''s, so
     GNAT users do not need to apply GNAT's patches to build both GNAT
     and `g77' from the same source tree.

   * Modify `make' rules and related code so that generation of Info
     documentation doesn't require compilation using `gcc'.  Now, any
     ANSI C compiler should be adequate to produce the `g77'
     documentation (in particular, the tables of intrinsics) from
     scratch.

   * Add `INT2' and `INT8' intrinsics.

   * Add `CPU_TIME' intrinsic.

   * Add `ALARM' intrinsic.

   * `CTIME' intrinsic now accepts any `INTEGER' argument, not just
     `INTEGER(KIND=2)'.

   * Warn when explicit type declaration disagrees with the type of an
     intrinsic invocation.

   * Support `*f771' entry in `gcc' `specs' file.

   * Fix typo in `make' rule `g77-cross', used only for cross-compiling.

   * Fix `libf2c' build procedure to re-archive library if previous
     attempt to archive was interrupted.

   * Change `gcc' to unroll loops only during the last invocation (of
     as many as two invocations) of loop optimization.

   * Improve handling of `-fno-f2c' so that code that attempts to pass
     an intrinsic as an actual argument, such as `CALL FOO(ABS)', is
     rejected due to the fact that the run-time-library routine is,
     effectively, compiled with `-ff2c' in effect.

   * Fix `g77' driver to recognize `-fsyntax-only' as an option that
     inhibits linking, just like `-c' or `-S', and to recognize and
     properly handle the `-nostdlib', `-M', `-MM', `-nodefaultlibs',
     and `-Xlinker' options.

   * Upgrade to `libf2c' as of 1997-08-16.

   * Modify `libf2c' to consistently and clearly diagnose recursive I/O
     (at run time).

   * `g77' driver now prints version information (such as produced by
     `g77 -v') to `stderr' instead of `stdout'.

   * The `.r' suffix now designates a Ratfor source file, to be
     preprocessed via the `ratfor' command, available separately.

   * Fix some aspects of how `gcc' determines what kind of system is
     being configured and what kinds are supported.  For example, GNU
     Linux/Alpha ELF systems now are directly supported.

   * Improve diagnostics.

   * Improve documentation and indexing.

   * Include all pertinent files for `libf2c' that come from
     `netlib.bell-labs.com'; give any such files that aren't quite
     accurate in `g77''s version of `libf2c' the suffix `.netlib'.

   * Reserve `INTEGER(KIND=0)' for future use.

In 0.5.20:
==========

   * The `-fno-typeless-boz' option is now the default.

     This option specifies that non-decimal-radix constants using the
     prefixed-radix form (such as `Z'1234'') are to be interpreted as
     `INTEGER(KIND=1)' constants.  Specify `-ftypeless-boz' to cause
     such constants to be interpreted as typeless.

     (Version 0.5.19 introduced `-fno-typeless-boz' and its inverse.)

     *Note Options Controlling Fortran Dialect: Fortran Dialect Options,
     for information on the `-ftypeless-boz' option.

   * Options `-ff90-intrinsics-enable' and `-fvxt-intrinsics-enable'
     now are the defaults.

     Some programs might use names that clash with intrinsic names
     defined (and now enabled) by these options or by the new `libU77'
     intrinsics.  Users of such programs might need to compile them
     differently (using, for example, `-ff90-intrinsics-disable') or,
     better yet, insert appropriate `EXTERNAL' statements specifying
     that these names are not intended to be names of intrinsics.

   * The `ALWAYS_FLUSH' macro is no longer defined when building
     `libf2c', which should result in improved I/O performance,
     especially over NFS.

     _Note:_ If you have code that depends on the behavior of `libf2c'
     when built with `ALWAYS_FLUSH' defined, you will have to modify
     `libf2c' accordingly before building it from this and future
     versions of `g77'.

     *Note Output Assumed To Flush::, for more information.

   * Dave Love's implementation of `libU77' has been added to the
     version of `libf2c' distributed with and built as part of `g77'.
     `g77' now knows about the routines in this library as intrinsics.

   * New option `-fvxt' specifies that the source file is written in
     VXT Fortran, instead of GNU Fortran.

     *Note VXT Fortran::, for more information on the constructs
     recognized when the `-fvxt' option is specified.

   * The `-fvxt-not-f90' option has been deleted, along with its
     inverse, `-ff90-not-vxt'.

     If you used one of these deleted options, you should re-read the
     pertinent documentation to determine which options, if any, are
     appropriate for compiling your code with this version of `g77'.

     *Note Other Dialects::, for more information.

   * The `-fugly' option now issues a warning, as it likely will be
     removed in a future version.

     (Enabling all the `-fugly-*' options is unlikely to be feasible,
     or sensible, in the future, so users should learn to specify only
     those `-fugly-*' options they really need for a particular source
     file.)

   * The `-fugly-assumed' option, introduced in version 0.5.19, has
     been changed to better accommodate old and new code.

     *Note Ugly Assumed-Size Arrays::, for more information.

   * Make a number of fixes to the `g77' front end and the `gcc' back
     end to better support Alpha (AXP) machines.  This includes
     providing at least one bug-fix to the `gcc' back end for Alphas.

   * Related to supporting Alpha (AXP) machines, the `LOC()' intrinsic
     and `%LOC()' construct now return values of `INTEGER(KIND=0)' type,
     as defined by the GNU Fortran language.

     This type is wide enough (holds the same number of bits) as the
     character-pointer type on the machine.

     On most machines, this won't make a difference, whereas, on Alphas
     and other systems with 64-bit pointers, the `INTEGER(KIND=0)' type
     is equivalent to `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') instead of the more common `INTEGER(KIND=1)' (often
     referred to as `INTEGER*4').

   * Emulate `COMPLEX' arithmetic in the `g77' front end, to avoid bugs
     in `complex' support in the `gcc' back end.  New option
     `-fno-emulate-complex' causes `g77' to revert the 0.5.19 behavior.

   * Fix bug whereby `REAL A(1)', for example, caused a compiler crash
     if `-fugly-assumed' was in effect and A was a local (automatic)
     array.  That case is no longer affected by the new handling of
     `-fugly-assumed'.

   * Fix `g77' command driver so that `g77 -o foo.f' no longer deletes
     `foo.f' before issuing other diagnostics, and so the `-x' option
     is properly handled.

   * Enable inlining of subroutines and functions by the `gcc' back end.
     This works as it does for `gcc' itself--program units may be
     inlined for invocations that follow them in the same program unit,
     as long as the appropriate compile-time options are specified.

   * Dummy arguments are no longer assumed to potentially alias
     (overlap) other dummy arguments or `COMMON' areas when any of
     these are defined (assigned to) by Fortran code.

     This can result in faster and/or smaller programs when compiling
     with optimization enabled, though on some systems this effect is
     observed only when `-fforce-addr' also is specified.

     New options `-falias-check', `-fargument-alias',
     `-fargument-noalias', and `-fno-argument-noalias-global' control
     the way `g77' handles potential aliasing.

     *Note Aliasing Assumed To Work::, for detailed information on why
     the new defaults might result in some programs no longer working
     the way they did when compiled by previous versions of `g77'.

   * The `CONJG()' and `DCONJG()' intrinsics now are compiled in-line.

   * The bug-fix for 0.5.19.1 has been re-done.  The `g77' compiler has
     been changed back to assume `libf2c' has no aliasing problems in
     its implementations of the `COMPLEX' (and `DOUBLE COMPLEX')
     intrinsics.  The `libf2c' has been changed to have no such
     problems.

     As a result, 0.5.20 is expected to offer improved performance over
     0.5.19.1, perhaps as good as 0.5.19 in most or all cases, due to
     this change alone.

     _Note:_ This change requires version 0.5.20 of `libf2c', at least,
     when linking code produced by any versions of `g77' other than
     0.5.19.1.  Use `g77 -v' to determine the version numbers of the
     `libF77', `libI77', and `libU77' components of the `libf2c'
     library.  (If these version numbers are not printed--in
     particular, if the linker complains about unresolved references to
     names like `g77__fvers__'--that strongly suggests your
     installation has an obsolete version of `libf2c'.)

   * New option `-fugly-assign' specifies that the same memory
     locations are to be used to hold the values assigned by both
     statements `I = 3' and `ASSIGN 10 TO I', for example.  (Normally,
     `g77' uses a separate memory location to hold assigned statement
     labels.)

     *Note Ugly Assigned Labels::, for more information.

   * `FORMAT' and `ENTRY' statements now are allowed to precede
     `IMPLICIT NONE' statements.

   * Produce diagnostic for unsupported `SELECT CASE' on `CHARACTER'
     type, instead of crashing, at compile time.

   * Fix crashes involving diagnosed or invalid code.

   * Change approach to building `libf2c' archive (`libf2c.a') so that
     members are added to it only when truly necessary, so the user
     that installs an already-built `g77' doesn't need to have write
     access to the build tree (whereas the user doing the build might
     not have access to install new software on the system).

   * Support `gcc' version 2.7.2.2 (modified by `g77' into version
     2.7.2.2.f.2), and remove support for prior versions of `gcc'.

   * Upgrade to `libf2c' as of 1997-02-08, and fix up some of the build
     procedures.

   * Improve general build procedures for `g77', fixing minor bugs
     (such as deletion of any file named `f771' in the parent directory
     of `gcc/').

   * Enable full support of `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') available in `libf2c' and `f2c.h' so that `f2c' users
     may make full use of its features via the `g77' version of `f2c.h'
     and the `INTEGER(KIND=2)' support routines in the `g77' version of
     `libf2c'.

   * Improve `g77' driver and `libf2c' so that `g77 -v' yields version
     information on the library.

   * The `SNGL' and `FLOAT' intrinsics now are specific intrinsics,
     instead of synonyms for the generic intrinsic `REAL'.

   * New intrinsics have been added.  These are `REALPART', `IMAGPART',
     `COMPLEX', `LONG', and `SHORT'.

   * A new group of intrinsics, `gnu', has been added to contain the
     new `REALPART', `IMAGPART', and `COMPLEX' intrinsics.  An old
     group, `dcp', has been removed.

   * Complain about industry-wide ambiguous references `REAL(EXPR)' and
     `AIMAG(EXPR)', where EXPR is `DOUBLE COMPLEX' (or any complex type
     other than `COMPLEX'), unless `-ff90' option specifies Fortran 90
     interpretation or new `-fugly-complex' option, in conjunction with
     `-fnot-f90', specifies `f2c' interpretation.

   * Make improvements to diagnostics.

   * Speed up compiler a bit.

   * Improvements to documentation and indexing, including a new
     chapter containing information on one, later more, diagnostics
     that users are directed to pull up automatically via a message in
     the diagnostic itself.

     (Hence the menu item `M' for the node `Diagnostics' in the
     top-level menu of the Info documentation.)

In previous versions:
=====================

Information on previous versions is archived in `gcc/gcc/f/news.texi'
following the test of the `DOC-OLDNEWS' macro.


File: g77.info,  Node: Changes,  Next: Language,  Prev: News,  Up: Top

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

This chapter describes changes to `g77' that are visible to the
programmers who actually write and maintain Fortran code they compile
with `g77'.  Information on changes to installation procedures, changes
to the documentation, and bug fixes is not provided here, unless it is
likely to affect how users use `g77'.  *Note News About GNU Fortran:
News, for information on such changes to `g77'.

   Note that two variants of `g77' are tracked below.  The `egcs'
variant is described vis-a-vis previous versions of `egcs' and/or an
official FSF version, as appropriate.  Note that all such variants are
obsolete _as of July 1999_ - the information is retained here only for
its historical value.

   Therefore, `egcs' versions sometimes have multiple listings to help
clarify how they differ from other versions, though this can make
getting a complete picture of what a particular `egcs' version contains
somewhat more difficult.

   For information on bugs in the GCC-3.3.5 version of `g77', see *Note
Known Bugs In GNU Fortran: Known Bugs.

   The following information was last updated on 2003-05-18:

In `GCC' 3.3 versus `GCC' 3.2:
==============================

   * Problem Reports fixed (in chronological order of submission):
    `1832'
          -list directed i/o overflow hangs, -fbounds-check doesn't
          detect

    `3924'
          g77 generates code which is rejected by GAS if COFF debugging
          info is requested

    `6286'
          Broken links on web pages

    `6367'
          (libf2c) multiple repeat counts confuse namelist read into
          array

    `6491'
          Logical operations error on logicals when using -fugly-logint

    `6742'
          Generation of C++ Prototype for FORTRAN and extern "C"

    `7113'
          Failure of g77.f-torture/execute/f90-intrinsic-bit.f -Os on
          irix6.5

    `7236'
          (libf2c) OPEN(...,RECL=nnn,...) without ACCESS='DIRECT'
          should assume a direct access file

    `7278'
          g77 "bug"; the executable misbehave (use of options -O2
          -fno-automatic gave wrong results)

    `7384'
          (libf2c) DATE_AND_TIME milliseconds field inactive on Windows

    `7388'
          Incorrect output with 0-based array of characters

    `8587'
          Double complex zero ** double precision number -> NaN instead
          of zero

    `9038'
          -ffixed-line-length-none -x f77-cpp-input gives: Warning:
          unknown register name line-length-none

    `9263'
          ICE caused by invalid PARAMETER in implied DO loop

    `10197'
          Direct access files not unformatted by default

    `10726'
          Documentation for function IDATE Intrinsic (UNIX) is wrong
          [fixed in 3.3.1].

   * Richard Henderson (<rth@redhat.com>) analyzed and improved the
     handling of (no-)aliasing information for dummy arguments and
     improved the optimization of induction variables in unrolled loops.

In `GCC' 3.2 versus `GCC' 3.1:
==============================

   * Problem Reports fixed (in chronological order of submission):
    `7681'
          ICE in compensate_edge, at reg-stack.c:2591

    `8308'
          gcc-3.x does not compile files with suffix .r (RATFOR) [Fixed
          in 3.2.1]

    `9258'
          [3.2/3.3/3.4 regression] ICE in compensate_edge, at
          reg-stack.c:2589

In `GCC' 3.1 (formerly known as g77-0.5.27) versus `GCC' 3.0:
=============================================================

   * Problem Reports fixed (in chronological order of submission):
    `947'
          Data statement initialization with subscript of kind INTEGER*2

    `3743'
          Reference to intrinsic `ISHFT' invalid

    `3807'
          Function BESJN(integer,double) problems

    `3957'
          g77 -pipe -xf77-cpp-input sends output to stdout

    `4279'
          g77 -h" gives bogus output

    `4730'
          ICE on valid input using CALL EXIT(%VAL(...))

    `4752'
          g77 -v -c -xf77-version /dev/null -xnone causes ice

    `4885'
          BACKSPACE example that doesn't work as of gcc/g77-3.0.x

    `5122'
          g77 rejects accepted use of INTEGER*2 as type of DATA
          statement loop index

    `5397'
          ICE on compiling source with 540 000 000 REAL array

    `5473'
          ICE on BESJN(integer*8,real)

    `5837'
          bug in loop unrolling

    `6106'
          sparc-sun-solaris2.7 gcc-3.1 extra g77 testsuite failures
          w/-m64

    `6138'
          Incorrect acces of integer*1 variables on PA

    `6304'
          Failure of LAPACK test dtest on irix6.5 with -mabi=64 -O2

   * `g77' now has its man page generated from the texinfo
     documentation, to guarantee that it remains up to date.

   * `g77' used to reject the following program on 32-bit targets:
          PROGRAM PROG
          DIMENSION A(140 000 000)
          END
     with the message:
          prog.f: In program `prog':
          prog.f:2:
                   DIMENSION A(140 000 000)
                             ^
          Array `a' at (^) is too large to handle
     because 140 000 000 REALs is larger than the largest bit-extent
     that can be expressed in 32 bits.  However, bit-sizes never play a
     role after offsets have been converted to byte addresses.
     Therefore this check has been removed, and the limit is now 2
     Gbyte of memory (around 530 000 000 REALs).  Note: On GNU/Linux
     systems one has to compile and link programs that occupy more than
     1 Gbyte statically, i.e. `g77 -static ...'.

   * Based on work done by Juergen Pfeifer (<juergen.pfeifer@gmx.net>)
     libf2c is now a shared library.  One can still link in all objects
     with the program by specifying the `-static' option.

   * Robert Anderson (<rwa@alumni.princeton.edu>) thought up a two line
     change that enables g77 to compile such code as:
          SUBROUTINE SUB(A, N)
          DIMENSION N(2)
          DIMENSION A(N(1),N(2))
          A(1,1) = 1.
          END
     Note the use of array elements in the bounds of the adjustable
     array A.

   * George Helffrich (<george@geo.titech.ac.jp>) implemented a change
     in substring index checking (when specifying `-fbounds-check')
     that permits the use of zero length substrings of the form
     `string(1:0)'.

   * Based on code developed by Pedro Vazquez
     (<vazquez@penelope.iqm.unicamp.br>), the `libf2c' library is now
     able to read and write files larger than 2 Gbyte on 32-bit target
     machines, if the operating system supports this.

In 0.5.26, `GCC' 3.0 versus `GCC' 2.95:
=======================================

   * When a REWIND was issued after a WRITE statement on an unformatted
     file, the implicit truncation was performed by copying the
     truncated file to /tmp and copying the result back.  This has been
     fixed by using the `ftruncate' OS function.  Thanks go to the
     GAMESS developers for bringing this to our attention.

   * Using options `-g', `-ggdb' or `-gdwarf[-2]' (where appropriate
     for your target) now also enables debugging information for COMMON
     BLOCK and EQUIVALENCE items to be emitted.  Thanks go to Andrew
     Vaught (<andy@xena.eas.asu.edu>) and George Helffrich
     (<george@geology.bristol.ac.uk>) for fixing this longstanding
     problem.

   * It is not necessary anymore to use the option `-femulate-complex'
     to compile Fortran code using COMPLEX arithmetic, even on 64-bit
     machines (like the Alpha).  This will improve code generation.

   * INTRINSIC arithmetic functions are now treated as routines that do
     not depend on anything but their argument(s).  This enables
     further instruction scheduling, because it is known that they
     cannot read or modify arbitrary locations.


In 0.5.25, `GCC' 2.95 (`EGCS' 1.2) versus `EGCS' 1.1.2:
=======================================================

   * The new `-fbounds-check' option causes `g77' to compile run-time
     bounds checks of array subscripts, as well as of substring start
     and end points.

   * `libg2c' now supports building as multilibbed library, which
     provides better support for systems that require options such as
     `-mieee' to work properly.

   * Source file names with the suffixes `.FOR' and `.FPP' now are
     recognized by `g77' as if they ended in `.for' and `.fpp',
     respectively.

   * The order of arguments to the _subroutine_ forms of the `CTime',
     `DTime', `ETime', and `TtyNam' intrinsics has been swapped.  The
     argument serving as the returned value for the corresponding
     function forms now is the _second_ argument, making these
     consistent with the other subroutine forms of `libU77' intrinsics.

   * `g77' now warns about a reference to an intrinsic that has an
     interface that is not Year 2000 (Y2K) compliant.  Also, `libg2c'
     has been changed to increase the likelihood of catching references
     to the implementations of these intrinsics using the `EXTERNAL'
     mechanism (which would avoid the new warnings).

     *Note Year 2000 (Y2K) Problems::, for more information.

   * `-fno-emulate-complex' is now the default option.  This should
     result in improved performance of code that uses the `COMPLEX'
     data type.

   * The `-malign-double' option now reliably aligns _all_
     double-precision variables and arrays on Intel x86 targets.

   * `g77' no longer generates code to maintain `errno', a C-language
     concept, when performing operations such as the `SqRt' intrinsic.

   * Support for the `-fugly' option has been removed.


In 0.5.24 versus 0.5.23:
========================

There is no `g77' version 0.5.24 at this time, or planned.  0.5.24 is
the version number designated for bug fixes and, perhaps, some new
features added, to 0.5.23.  Version 0.5.23 requires `gcc' 2.8.1, as
0.5.24 was planned to require.

   Due to `EGCS' becoming `GCC' (which is now an acronym for "GNU
Compiler Collection"), and `EGCS' 1.2 becoming officially designated
`GCC' 2.95, there seems to be no need for an actual 0.5.24 release.

   To reduce the confusion already resulting from use of 0.5.24 to
designate `g77' versions within `EGCS' versions 1.0 and 1.1, as well as
in versions of `g77' documentation and notices during that period,
"mainline" `g77' version numbering resumes at 0.5.25 with `GCC' 2.95
(`EGCS' 1.2), skipping over 0.5.24 as a placeholder version number.

   To repeat, there is no `g77' 0.5.24, but there is now a 0.5.25.
Please remain calm and return to your keypunch units.

In `EGCS' 1.1.2 versus `EGCS' 1.1.1:
====================================

In `EGCS' 1.1.1 versus `EGCS' 1.1:
==================================

In `EGCS' 1.1 versus `EGCS' 1.0.3:
==================================

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.


In `EGCS' 1.1 versus `g77' 0.5.23:
==================================

   * `g77' now treats `%LOC(EXPR)' and `LOC(EXPR)' as "ordinary"
     expressions when they are used as arguments in procedure calls.
     This change applies only to global (filewide) analysis, making it
     consistent with how `g77' actually generates code for these cases.

     Previously, `g77' treated these expressions as denoting special
     "pointer" arguments for the purposes of filewide analysis.

   * Align static double-precision variables and arrays on Intel x86
     targets regardless of whether `-malign-double' is specified.

     Generally, this affects only local variables and arrays having the
     `SAVE' attribute or given initial values via `DATA'.

   * The `g77' driver now ensures that `-lg2c' is specified in the link
     phase prior to any occurrence of `-lm'.  This prevents
     accidentally linking to a routine in the SunOS4 `-lm' library when
     the generated code wants to link to the one in `libf2c' (`libg2c').

   * `g77' emits more debugging information when `-g' is used.

     This new information allows, for example, `which __g77_length_a'
     to be used in `gdb' to determine the type of the phantom length
     argument supplied with `CHARACTER' variables.

     This information pertains to internally-generated type, variable,
     and other information, not to the longstanding deficiencies
     vis-a-vis `COMMON' and `EQUIVALENCE'.

   * The F90 `Date_and_Time' intrinsic now is supported.

   * The F90 `System_Clock' intrinsic allows the optional arguments
     (except for the `Count' argument) to be omitted.


In 0.5.23 versus 0.5.22:
========================

   * This release contains several regressions against version 0.5.22
     of `g77', due to using the "vanilla" `gcc' back end instead of
     patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for `__restrict__' keyword, the options
          `-fargument-alias', `-fargument-noalias', and
          `-fargument-noalias-global', and the corresponding
          alias-analysis code.

          (`egcs' has the alias-analysis code, but not the
          `__restrict__' keyword.  `egcs' `g77' users benefit from the
          alias-analysis code despite the lack of the `__restrict__'
          keyword, which is a C-language construct.)

        - Support for the GNU compiler options `-fmove-all-movables',
          `-freduce-all-givs', and `-frerun-loop-opt'.

          (`egcs' supports these options.  `g77' users of `egcs'
          benefit from them even if they are not explicitly specified,
          because the defaults are optimized for `g77' users.)

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

   * Support `gcc' version 2.8, and remove support for prior versions
     of `gcc'.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * The `g77' command now expects the run-time library to be named
     `libg2c.a' instead of `libf2c.a', to ensure that a version other
     than the one built and installed as part of the same `g77' version
     is picked up.

   * `g77''s version of `libf2c' separates out the setting of global
     state (such as command-line arguments and signal handling) from
     `main.o' into distinct, new library archive members.

     This should make it easier to write portable applications that
     have their own (non-Fortran) `main()' routine properly set up the
     `libf2c' environment, even when `libf2c' (now `libg2c') is a
     shared library.

   * Some diagnostics have been changed from warnings to errors, to
     prevent inadvertent use of the resulting, probably buggy, programs.
     These mostly include diagnostics about use of unsupported features
     in the `OPEN', `INQUIRE', `READ', and `WRITE' statements, and
     about truncations of various sorts of constants.


In 0.5.22 versus 0.5.21:
========================

   * Fix `Signal' intrinsic so it offers portable support for 64-bit
     systems (such as Digital Alphas running GNU/Linux).

   * Support `FORMAT(I<EXPR>)' when EXPR is a compile-time constant
     `INTEGER' expression.

   * Fix `g77' `-g' option so procedures that use `ENTRY' can be
     stepped through, line by line, in `gdb'.

   * Allow any `REAL' argument to intrinsics `Second' and `CPU_Time'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.

   * Use `tempnam', if available, to open scratch files (as in
     `OPEN(STATUS='SCRATCH')') so that the `TMPDIR' environment
     variable, if present, is used.

   * Rename the `gcc' keyword `restrict' to `__restrict__', to avoid
     rejecting valid, existing, C programs.  Support for `restrict' is
     now more like support for `complex'.

   * Fix `-fugly-comma' to affect invocations of only external
     procedures.  Restore rejection of gratuitous trailing omitted
     arguments to intrinsics, as in `I=MAX(3,4,,)'.

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.


In `EGCS' 1.0.2 versus `EGCS' 1.0.1:
====================================

   * Fix compiler so it accepts `-fgnu-intrinsics-*' and
     `-fbadu77-intrinsics-*' options.

In `EGCS' 1.0.1 versus `EGCS' 1.0:
==================================

In `EGCS' 1.0 versus `g77' 0.5.21:
==================================

   * Version 1.0 of `egcs' contains several regressions against version
     0.5.21 of `g77', due to using the "vanilla" `gcc' back end instead
     of patching it to fix a few bugs and improve performance in a few
     cases.

     Features that have been dropped from this version of `g77' due to
     their being implemented via `g77'-specific patches to the `gcc'
     back end in previous releases include:

        - Support for the C-language `restrict' keyword.

        - Support for the `-W' option warning about integer division by
          zero.

        - The Intel x86-specific option `-malign-double' applying to
          stack-allocated data as well as statically-allocate data.

   * Remove support for the `--driver' option, as `g77' now does all
     the driving, just like `gcc'.

   * Allow any numeric argument to intrinsics `Int2' and `Int8'.


In 0.5.21:
==========

   * When the `-W' option is specified, `gcc', `g77', and other GNU
     compilers that incorporate the `gcc' back end as modified by
     `g77', issue a warning about integer division by constant zero.

   * New option `-Wno-globals' disables warnings about "suspicious" use
     of a name both as a global name and as the implicit name of an
     intrinsic, and warnings about disagreements over the number or
     natures of arguments passed to global procedures, or the natures
     of the procedures themselves.

     The default is to issue such warnings, which are new as of this
     version of `g77'.

   * New option `-fno-globals' disables diagnostics about potentially
     fatal disagreements analysis problems, such as disagreements over
     the number or natures of arguments passed to global procedures, or
     the natures of those procedures themselves.

     The default is to issue such diagnostics and flag the compilation
     as unsuccessful.  With this option, the diagnostics are issued as
     warnings, or, if `-Wno-globals' is specified, are not issued at
     all.

     This option also disables inlining of global procedures, to avoid
     compiler crashes resulting from coding errors that these
     diagnostics normally would identify.

   * Fix `libU77' routines that accept file and other names to strip
     trailing blanks from them, for consistency with other
     implementations.  Blanks may be forcibly appended to such names by
     appending a single null character (`CHAR(0)') to the significant
     trailing blanks.

   * Fix `CHMOD' intrinsic to work with file names that have embedded
     blanks, commas, and so on.

   * Fix `SIGNAL' intrinsic so it accepts an optional third `Status'
     argument.

   * Make many changes to `libU77' intrinsics to support existing code
     more directly.

     Such changes include allowing both subroutine and function forms
     of many routines, changing `MCLOCK()' and `TIME()' to return
     `INTEGER(KIND=1)' values, introducing `MCLOCK8()' and `TIME8()' to
     return `INTEGER(KIND=2)' values, and placing functions that are
     intended to perform side effects in a new intrinsic group,
     `badu77'.

   * Add options `-fbadu77-intrinsics-delete',
     `-fbadu77-intrinsics-hide', and so on.

   * Add `INT2' and `INT8' intrinsics.

   * Add `CPU_TIME' intrinsic.

   * Add `ALARM' intrinsic.

   * `CTIME' intrinsic now accepts any `INTEGER' argument, not just
     `INTEGER(KIND=2)'.

   * `g77' driver now prints version information (such as produced by
     `g77 -v') to `stderr' instead of `stdout'.

   * The `.r' suffix now designates a Ratfor source file, to be
     preprocessed via the `ratfor' command, available separately.


In 0.5.20:
==========

   * The `-fno-typeless-boz' option is now the default.

     This option specifies that non-decimal-radix constants using the
     prefixed-radix form (such as `Z'1234'') are to be interpreted as
     `INTEGER(KIND=1)' constants.  Specify `-ftypeless-boz' to cause
     such constants to be interpreted as typeless.

     (Version 0.5.19 introduced `-fno-typeless-boz' and its inverse.)

     *Note Options Controlling Fortran Dialect: Fortran Dialect Options,
     for information on the `-ftypeless-boz' option.

   * Options `-ff90-intrinsics-enable' and `-fvxt-intrinsics-enable'
     now are the defaults.

     Some programs might use names that clash with intrinsic names
     defined (and now enabled) by these options or by the new `libU77'
     intrinsics.  Users of such programs might need to compile them
     differently (using, for example, `-ff90-intrinsics-disable') or,
     better yet, insert appropriate `EXTERNAL' statements specifying
     that these names are not intended to be names of intrinsics.

   * The `ALWAYS_FLUSH' macro is no longer defined when building
     `libf2c', which should result in improved I/O performance,
     especially over NFS.

     _Note:_ If you have code that depends on the behavior of `libf2c'
     when built with `ALWAYS_FLUSH' defined, you will have to modify
     `libf2c' accordingly before building it from this and future
     versions of `g77'.

     *Note Output Assumed To Flush::, for more information.

   * Dave Love's implementation of `libU77' has been added to the
     version of `libf2c' distributed with and built as part of `g77'.
     `g77' now knows about the routines in this library as intrinsics.

   * New option `-fvxt' specifies that the source file is written in
     VXT Fortran, instead of GNU Fortran.

     *Note VXT Fortran::, for more information on the constructs
     recognized when the `-fvxt' option is specified.

   * The `-fvxt-not-f90' option has been deleted, along with its
     inverse, `-ff90-not-vxt'.

     If you used one of these deleted options, you should re-read the
     pertinent documentation to determine which options, if any, are
     appropriate for compiling your code with this version of `g77'.

     *Note Other Dialects::, for more information.

   * The `-fugly' option now issues a warning, as it likely will be
     removed in a future version.

     (Enabling all the `-fugly-*' options is unlikely to be feasible,
     or sensible, in the future, so users should learn to specify only
     those `-fugly-*' options they really need for a particular source
     file.)

   * The `-fugly-assumed' option, introduced in version 0.5.19, has
     been changed to better accommodate old and new code.

     *Note Ugly Assumed-Size Arrays::, for more information.

   * Related to supporting Alpha (AXP) machines, the `LOC()' intrinsic
     and `%LOC()' construct now return values of `INTEGER(KIND=0)' type,
     as defined by the GNU Fortran language.

     This type is wide enough (holds the same number of bits) as the
     character-pointer type on the machine.

     On most machines, this won't make a difference, whereas, on Alphas
     and other systems with 64-bit pointers, the `INTEGER(KIND=0)' type
     is equivalent to `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') instead of the more common `INTEGER(KIND=1)' (often
     referred to as `INTEGER*4').

   * Emulate `COMPLEX' arithmetic in the `g77' front end, to avoid bugs
     in `complex' support in the `gcc' back end.  New option
     `-fno-emulate-complex' causes `g77' to revert the 0.5.19 behavior.

   * Dummy arguments are no longer assumed to potentially alias
     (overlap) other dummy arguments or `COMMON' areas when any of
     these are defined (assigned to) by Fortran code.

     This can result in faster and/or smaller programs when compiling
     with optimization enabled, though on some systems this effect is
     observed only when `-fforce-addr' also is specified.

     New options `-falias-check', `-fargument-alias',
     `-fargument-noalias', and `-fno-argument-noalias-global' control
     the way `g77' handles potential aliasing.

     *Note Aliasing Assumed To Work::, for detailed information on why
     the new defaults might result in some programs no longer working
     the way they did when compiled by previous versions of `g77'.

   * New option `-fugly-assign' specifies that the same memory
     locations are to be used to hold the values assigned by both
     statements `I = 3' and `ASSIGN 10 TO I', for example.  (Normally,
     `g77' uses a separate memory location to hold assigned statement
     labels.)

     *Note Ugly Assigned Labels::, for more information.

   * `FORMAT' and `ENTRY' statements now are allowed to precede
     `IMPLICIT NONE' statements.

   * Enable full support of `INTEGER(KIND=2)' (often referred to as
     `INTEGER*8') available in `libf2c' and `f2c.h' so that `f2c' users
     may make full use of its features via the `g77' version of `f2c.h'
     and the `INTEGER(KIND=2)' support routines in the `g77' version of
     `libf2c'.

   * Improve `g77' driver and `libf2c' so that `g77 -v' yields version
     information on the library.

   * The `SNGL' and `FLOAT' intrinsics now are specific intrinsics,
     instead of synonyms for the generic intrinsic `REAL'.

   * New intrinsics have been added.  These are `REALPART', `IMAGPART',
     `COMPLEX', `LONG', and `SHORT'.

   * A new group of intrinsics, `gnu', has been added to contain the
     new `REALPART', `IMAGPART', and `COMPLEX' intrinsics.  An old
     group, `dcp', has been removed.

   * Complain about industry-wide ambiguous references `REAL(EXPR)' and
     `AIMAG(EXPR)', where EXPR is `DOUBLE COMPLEX' (or any complex type
     other than `COMPLEX'), unless `-ff90' option specifies Fortran 90
     interpretation or new `-fugly-complex' option, in conjunction with
     `-fnot-f90', specifies `f2c' interpretation.


In previous versions:
=====================

Information on previous versions is archived in `gcc/gcc/f/news.texi'
following the test of the `DOC-OLDNEWS' macro.


File: g77.info,  Node: Language,  Next: Compiler,  Prev: Changes,  Up: Top

8 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,
currently available on the network at
`http://www.fortran.com/fortran/F77_std/rjcnf0001.html' or as
monolithic text at
`http://www.fortran.com/fortran/F77_std/f77_std.html'.  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.

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

   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.

   The GNU Fortran _language_ is described below.  Much of the material
is organized along the same lines as the ANSI FORTRAN 77 standard
itself.

   *Note Other Dialects::, for information on features `g77' supports
that are not part of the GNU Fortran language.

   _Note_: This portion of the documentation definitely needs a lot of
work!

* Menu:

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

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


File: g77.info,  Node: Direction of Language Development,  Next: Standard Support,  Up: Language

8.1 Direction of Language Development
=====================================

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

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

   The GNU Fortran _language_ is distinct from the GNU Fortran
_compilation system_ (`g77').

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

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

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

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

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

   * Serving as a mostly-upwards-compatible language from the de facto
     UNIX Fortran dialect as supported by `f77'.

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

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

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

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

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

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

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

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

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

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

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

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

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


File: g77.info,  Node: Standard Support,  Next: Conformance,  Prev: Direction of Language Development,  Up: Language

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

GNU Fortran supports ANSI FORTRAN 77 with the following caveats.  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.

* Menu:

* No Passing External Assumed-length::  CHAR*(*) CFUNC restriction.
* No Passing Dummy Assumed-length::     CHAR*(*) CFUNC restriction.
* No Pathological Implied-DO::          No `((..., I=...), I=...)'.
* No Useless Implied-DO::               No `(A, I=1, 1)'.


File: g77.info,  Node: No Passing External Assumed-length,  Next: No Passing Dummy Assumed-length,  Up: Standard Support

8.2.1 No Passing External Assumed-length
----------------------------------------

`g77' disallows 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.


File: g77.info,  Node: No Passing Dummy Assumed-length,  Next: No Pathological Implied-DO,  Prev: No Passing External Assumed-length,  Up: Standard Support

8.2.2 No Passing Dummy Assumed-length
-------------------------------------

`g77' disallows 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.


File: g77.info,  Node: No Pathological Implied-DO,  Next: No Useless Implied-DO,  Prev: No Passing Dummy Assumed-length,  Up: Standard Support

8.2.3 No Pathological Implied-DO
--------------------------------

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.


File: g77.info,  Node: No Useless Implied-DO,  Prev: No Pathological Implied-DO,  Up: Standard Support

8.2.4 No Useless Implied-DO
---------------------------

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.


File: g77.info,  Node: Conformance,  Next: Notation Used,  Prev: Standard Support,  Up: Language

8.3 Conformance
===============

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

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

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

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

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

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

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

   * Bugs in the program.

   * Bug in `g77'.

   * Bugs in the system.

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

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


File: g77.info,  Node: Notation Used,  Next: Terms and Concepts,  Prev: Conformance,  Up: Language

8.4 Notation Used in This Chapter
=================================

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

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

   For example:

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

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

   _Remember:_ The GNU Fortran language definition specifies both what
constitutes a valid GNU Fortran program and how, given such a program,
a valid GNU Fortran implementation is to interpret that program.

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

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

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

   * Keywords defined by the GNU Fortran language are shown in
     uppercase, as in: `COMMON', `INTEGER', and `BLOCK DATA'.

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

   * Portions of actual sample program, input, or output text look like
     this: `Actual program text'.

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

     For example: `PRINT *, 'My name is Bob''.

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

     "The `INTEGER IVAR' statement specifies that IVAR is a variable or
     array of type `INTEGER'."

     In the above example, any valid text may be substituted for the
     metasyntactic variable IVAR to make the statement apply to a
     specific instance, as long as the same text is substituted for
     _both_ occurrences of IVAR.

   * Ellipses ("...") are used to indicate further text that is either
     unimportant or expanded upon further, elsewhere.

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

     *Note Kind Notation::, for information on the relationship between
     Fortran 90 nomenclature (such as `INTEGER(KIND=1)') and the more
     traditional, less portably concise nomenclature (such as
     `INTEGER*4').


File: g77.info,  Node: Terms and Concepts,  Next: Characters Lines Sequence,  Prev: Notation Used,  Up: Language

8.5 Fortran Terms and Concepts
==============================

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

* Menu:

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


File: g77.info,  Node: Syntactic Items,  Next: Statements Comments Lines,  Up: Terms and Concepts

8.5.1 Syntactic Items
---------------------

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

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

   Underscores (`_') are accepted in symbol names after the first
character (which must be a letter).


File: g77.info,  Node: Statements Comments Lines,  Next: Scope of Names and Labels,  Prev: Syntactic Items,  Up: Terms and Concepts

8.5.2 Statements, Comments, and Lines
-------------------------------------

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

   Use of an exclamation point (`!') to begin a trailing comment (a
comment that extends to the end of the same source line) is permitted
under the following conditions:

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

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

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

   Use of a semicolon (`;') as a statement separator is permitted under
the following conditions:

   * The semicolon appears outside a character or Hollerith constant.
     Otherwise, the semicolon is considered part of the constant.

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

   * Neither a logical `IF' statement nor a non-construct `WHERE'
     statement (a Fortran 90 feature) may be followed (in the same,
     possibly continued, line) by a semicolon used as a statement
     separator.

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

          IF (VALIDP) CALL FOO; CALL BAR

     Some readers might think the `CALL BAR' is executed only if
     `VALIDP' is `.TRUE.', while others might assume its execution is
     unconditional.

     (At present, `g77' does not diagnose code that violates this
     restriction.)


File: g77.info,  Node: Scope of Names and Labels,  Prev: Statements Comments Lines,  Up: Terms and Concepts

8.5.3 Scope of Symbolic Names and Statement Labels
--------------------------------------------------

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

   Included in the list of entities that have a scope of a program unit
are construct names (a Fortran 90 feature).  *Note Construct Names::,
for more information.


File: g77.info,  Node: Characters Lines Sequence,  Next: Data Types and Constants,  Prev: Terms and Concepts,  Up: Language

8.6 Characters, Lines, and Execution Sequence
=============================================

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

* Menu:

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


File: g77.info,  Node: Character Set,  Next: Lines,  Up: Characters Lines Sequence

8.6.1 GNU Fortran Character Set
-------------------------------

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

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

   Special characters include:

   * Semicolon (`;')

   * Exclamation point (`!')

   * Double quote (`"')

   * Backslash (`\')

   * Question mark (`?')

   * Hash mark (`#')

   * Ampersand (`&')

   * Percent sign (`%')

   * Underscore (`_')

   * Open angle (`<')

   * Close angle (`>')

   * The FORTRAN 77 special characters (<SPC>, `=', `+', `-', `*', `/',
     `(', `)', `,', `.', `$', `'', and `:')

   Note that this document refers to <SPC> as "space", while X3.9-1978
FORTRAN 77 refers to it as "blank".


File: g77.info,  Node: Lines,  Next: Continuation Line,  Prev: Character Set,  Up: Characters Lines Sequence

8.6.2 Lines
-----------

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

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

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

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

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

   * A newline in the file is the character that represents the end of
     a line of text to the underlying system.  For example, on
     ASCII-based systems, a newline is the <NL> character, which has
     ASCII value 10 (decimal).

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

   * The end-of-file marker (`EOF') also serves to end the line of text
     that precedes it (and that does not contain a newline).

   * Any line of text that is shorter than 72 characters is padded to
     that length with spaces (called "blanks" in the standard).

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

   * Characters other than newline and the GNU Fortran character set
     are invalid.

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

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

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


File: g77.info,  Node: Continuation Line,  Next: Statements,  Prev: Lines,  Up: Characters Lines Sequence

8.6.3 Continuation Line
-----------------------

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

   A continuation line is any line that both

   * Contains a continuation character, and

   * Contains only spaces in columns 1 through 5

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

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

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


File: g77.info,  Node: Statements,  Next: Statement Labels,  Prev: Continuation Line,  Up: Characters Lines Sequence

8.6.4 Statements
----------------

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

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

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

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

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

           END
          &PROGRAM


File: g77.info,  Node: Statement Labels,  Next: Order,  Prev: Statements,  Up: Characters Lines Sequence

8.6.5 Statement Labels
----------------------

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

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

   * The semicolon is followed by the label for the statement, which in
     turn follows the label.

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

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

   A statement may have only one label defined for it.


File: g77.info,  Node: Order,  Next: INCLUDE,  Prev: Statement Labels,  Up: Characters Lines Sequence

8.6.6 Order of Statements and Lines
-----------------------------------

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

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

   The last line of a program unit may be an `END' statement, or may be:

   * An `END PROGRAM' statement, if the program unit is a main program.

   * An `END SUBROUTINE' statement, if the program unit is a subroutine.

   * An `END FUNCTION' statement, if the program unit is a function.

   * An `END BLOCK DATA' statement, if the program unit is a block data.


File: g77.info,  Node: INCLUDE,  Next: Cpp-style directives,  Prev: Order,  Up: Characters Lines Sequence

8.6.7 Including Source Text
---------------------------

Additional source text may be included in the processing of the source
file via the `INCLUDE' directive:

     INCLUDE FILENAME

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

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

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

   This virtual replacement treats the statements and `INCLUDE'
directives in the included text as syntactically distinct from those in
the including text.

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

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

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

     INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM

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

     A
     B
     C

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

   Included text must not include itself directly or indirectly,
regardless of whether the FILENAME used to reference the text is the
same.

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

   An `INCLUDE' directive may be continued across multiple lines as if
it were a statement.  This permits long names to be used for FILENAME.


File: g77.info,  Node: Cpp-style directives,  Prev: INCLUDE,  Up: Characters Lines Sequence

8.6.8 Cpp-style directives
--------------------------

`cpp' output-style `#' directives (*note C Preprocessor Output: (cpp)C
Preprocessor Output.)  are recognized by the compiler even when the
preprocessor isn't run on the input (as it is when compiling `.F'
files).  (Note the distinction between these `cpp' `#' _output_
directives and `#line' _input_ directives.)


File: g77.info,  Node: Data Types and Constants,  Next: Expressions,  Prev: Characters Lines Sequence,  Up: Language

8.7 Data Types and Constants
============================

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

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

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

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

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

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

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

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

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

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

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

* Menu:

* Types::
* Constants::
* Integer Type::
* Character Type::


File: g77.info,  Node: Types,  Next: Constants,  Up: Data Types and Constants

8.7.1 Data Types
----------------

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

   GNU Fortran supports these types:

  1. Integer (generic type `INTEGER')

  2. Real (generic type `REAL')

  3. Double precision

  4. Complex (generic type `COMPLEX')

  5. Logical (generic type `LOGICAL')

  6. Character (generic type `CHARACTER')

  7. Double Complex

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

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

   For example, a context described in this document as accepting the
`COMPLEX' type also is likely to accept the `DOUBLE COMPLEX' type.

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

* Menu:

* Double Notation::  As in `DOUBLE COMPLEX'.
* Star Notation::    As in `INTEGER*4'.
* Kind Notation::    As in `INTEGER(KIND=1)'.


File: g77.info,  Node: Double Notation,  Next: Star Notation,  Up: Types

8.7.1.1 Double Notation
.......................

The GNU Fortran language supports two uses of the keyword `DOUBLE' to
specify a specific kind of type:

   * `DOUBLE PRECISION', equivalent to `REAL(KIND=2)'

   * `DOUBLE COMPLEX', equivalent to `COMPLEX(KIND=2)'

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

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

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

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


File: g77.info,  Node: Star Notation,  Next: Kind Notation,  Prev: Double Notation,  Up: Types

8.7.1.2 Star Notation
.....................

The following notation specifies the storage size for a type:

     GENERIC-TYPE*N

GENERIC-TYPE must be a generic type--one of `INTEGER', `REAL',
`COMPLEX', `LOGICAL', or `CHARACTER'.  N must be one or more digits
comprising a decimal integer number greater than zero.

   Use the above form where a type name is valid.

   The `*N' notation specifies that the amount of storage occupied by
variables and array elements of that type is N times the storage
occupied by a `CHARACTER*1' variable.

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

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

   As a result, except for GENERIC-TYPE of `CHARACTER', uses of this
notation should be limited to isolated portions of a program that are
intended to handle system-specific tasks and are expected to be
non-portable.

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

   Specifications of types using the `*N' notation always are
interpreted as specifications of the appropriate types described in
this document using the `KIND=N' notation, described below.

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

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

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

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


File: g77.info,  Node: Kind Notation,  Prev: Star Notation,  Up: Types

8.7.1.3 Kind Notation
.....................

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

     GENERIC-TYPE(KIND=N)

Use the above form where a type name is valid.

   GENERIC-TYPE must be a generic type--one of `INTEGER', `REAL',
`COMPLEX', `LOGICAL', or `CHARACTER'.  N must be an integer
initialization expression that is a positive, nonzero value.

   Programmers are discouraged from writing these values directly into
their code.  Future versions of the GNU Fortran language will offer
facilities that will make the writing of code portable to `g77' _and_
Fortran 90 implementations simpler.

   However, writing code that ports to existing FORTRAN 77
implementations depends on avoiding the `KIND=' construct.

   The `KIND=' construct is thus useful in the context of GNU Fortran
for two reasons:

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

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

   The values of N in the GNU Fortran language are assigned using a
scheme that:

   * Attempts to maximize the ability of readers of this document to
     quickly familiarize themselves with assignments for popular types

   * Provides a unique value for each specific desired meaning

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

   * Avoids using values that are similar to values used in the
     existing, popular `*N' notation, to prevent readers from expecting
     that these implied correspondences work on all GNU Fortran
     implementations

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

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

   The values of N assigned so far are:

`KIND=0'
     This value is reserved for future use.

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

`KIND=1'
     This corresponds to the default types for `REAL', `INTEGER',
     `LOGICAL', `COMPLEX', and `CHARACTER', as appropriate.

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

     (Typically, these are `REAL*4', `INTEGER*4', `LOGICAL*4', and
     `COMPLEX*8'.)

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

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

     N of 4 thus corresponds to types that occupy four times as much
     storage as the default types, N of 8 to types that occupy eight
     times as much storage, and so on.

     The `INTEGER(KIND=2)' and `LOGICAL(KIND=2)' types are not
     necessarily supported by every GNU Fortran implementation.

`KIND=3'
     This corresponds to types that occupy as much storage as the
     default `CHARACTER' type, which is the same effective type as
     `CHARACTER(KIND=1)' (making that type effectively the same as
     `CHARACTER(KIND=3)').

     (Typically, these are `INTEGER*1' and `LOGICAL*1'.)

     N of 6 thus corresponds to types that occupy twice as much storage
     as the N=3 types, N of 12 to types that occupy four times as much
     storage, and so on.

     These are not necessarily supported by every GNU Fortran
     implementation.

`KIND=5'
     This corresponds to types that occupy half the storage as the
     default (N=1) types.

     (Typically, these are `INTEGER*2' and `LOGICAL*2'.)

     N of 25 thus corresponds to types that occupy one-quarter as much
     storage as the default types.

     These are not necessarily supported by every GNU Fortran
     implementation.

`KIND=7'
     This is valid only as `INTEGER(KIND=7)' and denotes the `INTEGER'
     type that has the smallest storage size that holds a pointer on
     the system.

     A pointer representable by this type is capable of uniquely
     addressing a `CHARACTER*1' variable, array, array element, or
     substring.

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

   Note that these are _proposed_ correspondences and might change in
future versions of `g77'--avoid writing code depending on them while
`g77', and therefore the GNU Fortran language it defines, is in beta
testing.

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

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

   Other meanings that might be given unique values are:

   * Types that make use of only half their storage size for
     representing precision and range.

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

   * The IEEE single floating-point type.

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

   Future _prime_ numbers should be given meanings in as incremental a
fashion as possible, to allow for flexibility and expressiveness in
combining types.

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

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

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

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


File: g77.info,  Node: Constants,  Next: Integer Type,  Prev: Types,  Up: Data Types and Constants

8.7.2 Constants
---------------

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

   A "typeless constant" has one of the following forms:

     'BINARY-DIGITS'B
     'OCTAL-DIGITS'O
     'HEXADECIMAL-DIGITS'Z
     'HEXADECIMAL-DIGITS'X

BINARY-DIGITS, OCTAL-DIGITS, and HEXADECIMAL-DIGITS are nonempty
strings of characters in the set `01', `01234567', and
`0123456789ABCDEFabcdef', respectively.  (The value for `A' (and `a')
is 10, for `B' and `b' is 11, and so on.)

   A prefix-radix constant, such as `Z'ABCD'', can optionally be
treated as typeless.  *Note Options Controlling Fortran Dialect:
Fortran Dialect Options, for information on the `-ftypeless-boz' option.

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

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

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


File: g77.info,  Node: Integer Type,  Next: Character Type,  Prev: Constants,  Up: Data Types and Constants

8.7.3 Integer Type
------------------

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

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

     B'BINARY-DIGITS'
     O'OCTAL-DIGITS'
     Z'HEXADECIMAL-DIGITS'
     X'HEXADECIMAL-DIGITS'

BINARY-DIGITS, OCTAL-DIGITS, and HEXADECIMAL-DIGITS are nonempty
strings of characters in the set `01', `01234567', and
`0123456789ABCDEFabcdef', respectively.  (The value for `A' (and `a')
is 10, for `B' and `b' is 11, and so on.)


File: g77.info,  Node: Character Type,  Prev: Integer Type,  Up: Data Types and Constants

8.7.4 Character Type
--------------------

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

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

   A character constant may be empty (have a length of zero).

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


File: g77.info,  Node: Expressions,  Next: Specification Statements,  Prev: Data Types and Constants,  Up: Language

8.8 Expressions
===============

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

* Menu:

* %LOC()::


File: g77.info,  Node: %LOC(),  Up: Expressions

8.8.1 The `%LOC()' Construct
----------------------------

     %LOC(ARG)

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

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

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

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

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

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

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

   *Note Debugging and Interfacing::, for detailed information on how
this particular version of `g77' implements various constructs.


File: g77.info,  Node: Specification Statements,  Next: Control Statements,  Prev: Expressions,  Up: Language

8.9 Specification Statements
============================

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

* Menu:

* NAMELIST::
* DOUBLE COMPLEX::


File: g77.info,  Node: NAMELIST,  Next: DOUBLE COMPLEX,  Up: Specification Statements

8.9.1 `NAMELIST' Statement
--------------------------

The `NAMELIST' statement, and related I/O constructs, are supported by
the GNU Fortran language in essentially the same way as they are by
`f2c'.

   This follows Fortran 90 with the restriction that on `NAMELIST'
input, subscripts must have the form
     SUBSCRIPT [ `:' SUBSCRIPT [ `:' STRIDE]]
   i.e.
     &xx x(1:3,8:10:2)=1,2,3,4,5,6/
   is allowed, but not, say,
     &xx x(:3,8::2)=1,2,3,4,5,6/

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


File: g77.info,  Node: DOUBLE COMPLEX,  Prev: NAMELIST,  Up: Specification Statements

8.9.2 `DOUBLE COMPLEX' Statement
--------------------------------

`DOUBLE COMPLEX' is a type-statement (and type) that specifies the type
`COMPLEX(KIND=2)' in GNU Fortran.


File: g77.info,  Node: Control Statements,  Next: Functions and Subroutines,  Prev: Specification Statements,  Up: Language

8.10 Control Statements
=======================

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

* Menu:

* DO WHILE::
* END DO::
* Construct Names::
* CYCLE and EXIT::


File: g77.info,  Node: DO WHILE,  Next: END DO,  Up: Control Statements

8.10.1 DO WHILE
---------------

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


File: g77.info,  Node: END DO,  Next: Construct Names,  Prev: DO WHILE,  Up: Control Statements

8.10.2 END DO
-------------

The `END DO' statement is provided by the GNU Fortran language.

   This statement is used in one of two ways:

   * The Fortran 90 meaning, in which it specifies the termination
     point of a single `DO' loop started with a `DO' statement that
     specifies no termination label.

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

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

     It is expected that this use of `END DO' will be removed from the
     GNU Fortran language in the future, though it is likely that it
     will long be supported by `g77' as a dialect form.


File: g77.info,  Node: Construct Names,  Next: CYCLE and EXIT,  Prev: END DO,  Up: Control Statements

8.10.3 Construct Names
----------------------

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

     CONSTRUCT-NAME: BLOCK-STATEMENT

Here, CONSTRUCT-NAME is the construct name itself; its definition is
connoted by the single colon (`:'); and BLOCK-STATEMENT is an `IF',
`DO', or `SELECT CASE' statement that begins a block.

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

     END BLOCK CONSTRUCT-NAME

Here, BLOCK must be `IF', `DO', or `SELECT', as appropriate.


File: g77.info,  Node: CYCLE and EXIT,  Prev: Construct Names,  Up: Control Statements

8.10.4 The `CYCLE' and `EXIT' Statements
----------------------------------------

The `CYCLE' and `EXIT' statements specify that the remaining statements
in the current iteration of a particular active (enclosing) `DO' loop
are to be skipped.

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

   `EXIT' specifies that the loop specified by the `DO' construct is
terminated.

   The `DO' loop affected by `CYCLE' and `EXIT' is the innermost
enclosing `DO' loop when the following forms are used:

     CYCLE
     EXIT

   Otherwise, the following forms specify the construct name of the
pertinent `DO' loop:

     CYCLE CONSTRUCT-NAME
     EXIT CONSTRUCT-NAME

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

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

In particular, neither the `EXIT' nor `CYCLE' statements above are
equivalent to a `GO TO' statement to either label `10' or `20'.

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

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

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

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

Thus, the `CYCLE' statement in the innermost loop skips over the
`PRINT' statement as it begins the next iteration of the loop, while
the `EXIT' statement in the middle loop ends that loop but _not_ the
outermost loop.


File: g77.info,  Node: Functions and Subroutines,  Next: Scope and Classes of Names,  Prev: Control Statements,  Up: Language

8.11 Functions and Subroutines
==============================

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

* Menu:

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


File: g77.info,  Node: %VAL(),  Next: %REF(),  Up: Functions and Subroutines

8.11.1 The `%VAL()' Construct
-----------------------------

     %VAL(ARG)

   The `%VAL()' construct specifies that an argument, ARG, is to be
passed by value, instead of by reference or descriptor.

   `%VAL()' is restricted to actual arguments in invocations of
external procedures.

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

   _Implementation Note:_ Currently, `g77' passes all arguments either
by reference or by descriptor.

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

   *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
information on how this particular version of `g77' passes arguments to
procedures.


File: g77.info,  Node: %REF(),  Next: %DESCR(),  Prev: %VAL(),  Up: Functions and Subroutines

8.11.2 The `%REF()' Construct
-----------------------------

     %REF(ARG)

   The `%REF()' construct specifies that an argument, ARG, is to be
passed by reference, instead of by value or descriptor.

   `%REF()' is restricted to actual arguments in invocations of
external procedures.

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

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

   _Implementation Note:_ Currently, `g77' passes all arguments (other
than variables and arrays of type `CHARACTER') by reference.  Future
versions of, or dialects supported by, `g77' might not pass `CHARACTER'
functions by reference.

   Thus, use of `%REF()' tends to be restricted to cases where ARG is
type `CHARACTER' but the called procedure accesses it via a means other
than the method used for Fortran `CHARACTER' arguments.

   *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
information on how this particular version of `g77' passes arguments to
procedures.


File: g77.info,  Node: %DESCR(),  Next: Generics and Specifics,  Prev: %REF(),  Up: Functions and Subroutines

8.11.3 The `%DESCR()' Construct
-------------------------------

     %DESCR(ARG)

   The `%DESCR()' construct specifies that an argument, ARG, is to be
passed by descriptor, instead of by value or reference.

   `%DESCR()' is restricted to actual arguments in invocations of
external procedures.

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

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

   _Implementation Note:_ Currently, `g77' passes all variables and
arrays of type `CHARACTER' by descriptor.  Future versions of, or
dialects supported by, `g77' might pass `CHARACTER' functions by
descriptor as well.

   Thus, use of `%DESCR()' tends to be restricted to cases where ARG is
not type `CHARACTER' but the called procedure accesses it via a means
similar to the method used for Fortran `CHARACTER' arguments.

   *Note Procedures (SUBROUTINE and FUNCTION): Procedures, for detailed
information on how this particular version of `g77' passes arguments to
procedures.


File: g77.info,  Node: Generics and Specifics,  Next: REAL() and AIMAG() of Complex,  Prev: %DESCR(),  Up: Functions and Subroutines

8.11.4 Generics and Specifics
-----------------------------

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

   * _Specific_ intrinsics have specific types for their arguments and
     a specific return type.

   * _Generic_ intrinsics are treated, on a case-by-case basis in the
     program's source code, as one of several possible specific
     intrinsics.

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

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

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

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

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

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

   * Convert `J' to `INTEGER(KIND=1)' first (as if `IABS(INT(J))' had
     been written).

   * Convert the result of the intrinsic to `INTEGER(KIND=1)' (as if
     `INT(ABS(J))' had been written).

   * No conversion (as if `ABS(J)' had been written).

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

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

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

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

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

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

   Specifically, it is believed that the new version of `JCB002' above
will confirm that:

   * Digital Semiconductor ("DEC") Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
     `f77' compilers all implement `Interp 1'.

   * IRIX 5.3 `f77' compiler implements `Interp 2'.

   * Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3, and IRIX 6.1
     `f77' compilers all implement `Interp 3'.

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


File: g77.info,  Node: REAL() and AIMAG() of Complex,  Next: CMPLX() of DOUBLE PRECISION,  Prev: Generics and Specifics,  Up: Functions and Subroutines

8.11.5 `REAL()' and `AIMAG()' of Complex
----------------------------------------

The GNU Fortran language disallows `REAL(EXPR)' and `AIMAG(EXPR)',
where EXPR is any `COMPLEX' type other than `COMPLEX(KIND=1)', except
when they are used in the following way:

     REAL(REAL(EXPR))
     REAL(AIMAG(EXPR))

The above forms explicitly specify that the desired effect is to
convert the real or imaginary part of EXPR, which might be some `REAL'
type other than `REAL(KIND=1)', to type `REAL(KIND=1)', and have that
serve as the value of the expression.

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

     REALPART(EXPR)
     IMAGPART(EXPR)

   To express the above using typical extended FORTRAN 77, use the
following constructs (when EXPR is `COMPLEX(KIND=2)'):

     DBLE(EXPR)
     DIMAG(EXPR)

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

   _Note:_ When `-ff90' is in effect, `g77' treats `REAL(EXPR)', where
EXPR is of type `COMPLEX', as `REALPART(EXPR)', whereas with
`-fugly-complex -fno-f90' in effect, it is treated as
`REAL(REALPART(EXPR))'.

   *Note Ugly Complex Part Extraction::, for more information.


File: g77.info,  Node: CMPLX() of DOUBLE PRECISION,  Next: MIL-STD 1753,  Prev: REAL() and AIMAG() of Complex,  Up: Functions and Subroutines

8.11.6 `CMPLX()' of `DOUBLE PRECISION'
--------------------------------------

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

   This means `CMPLX(D1,D2)', where `D1' and `D2' are `REAL(KIND=2)'
(`DOUBLE PRECISION'), is treated as:

     CMPLX(SNGL(D1), SNGL(D2))

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

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

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

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

     COMPLEX(REAL, IMAG)

   When REAL and IMAG are the same `REAL' types, `COMPLEX()' performs
no conversion other than to put them together to form a complex result
of the same (complex version of real) type.

   *Note Complex Intrinsic::, for more information.


File: g77.info,  Node: MIL-STD 1753,  Next: f77/f2c Intrinsics,  Prev: CMPLX() of DOUBLE PRECISION,  Up: Functions and Subroutines

8.11.7 MIL-STD 1753 Support
---------------------------

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


File: g77.info,  Node: f77/f2c Intrinsics,  Next: Table of Intrinsic Functions,  Prev: MIL-STD 1753,  Up: Functions and Subroutines

8.11.8 `f77'/`f2c' Intrinsics
-----------------------------

The bit-manipulation intrinsics supported by traditional `f77' and by
`f2c' are available in the GNU Fortran language.  These include `AND',
`LSHIFT', `OR', `RSHIFT', and `XOR'.

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

