Using GNU Fortran

James Craig Burley

Last updated 1998-01-11

for version 0.5.21

Copyright © 1995-1997 Free Software Foundation, Inc.

For GNU Fortran Version 0.5.21*

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

Permission is granted to make and distribute verbatim copies of this manual provided the copyright notice and this permission notice are preserved on all copies. Permission is granted to copy and distribute modified versions of this manual under the conditions for verbatim copying, provided also that the sections entitled “GNU General Public License,” “Funding for Free Software,” and “Protect Your Freedom—Fight ‘Look And Feel’” are included exactly as in the original, and provided that the entire resulting derived work is distributed under the terms of a permission notice identical to this one. Permission is granted to copy and distribute translations of this manual into another language, under the above conditions for modified versions, except that the sections entitled “GNU General Public License,” “Funding for Free Software,” and “Protect Your Freedom—Fight ‘Look And Feel’”, and this permission notice, may be included in translations approved by the Free Software Foundation instead of in the original English.

\gdef\set{\begingroup\catcode‘ =10 \parsearg\setxxx \gdef\setyyy#1 #2\endsetyyyContributed by James Craig Burley (burley@gnu.org). 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).

GNU GENERAL PUBLIC LICENSE

Version 2, June 1991

Copyright © 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

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.

1. 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.
2. 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.
3. 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:
   1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.
   2. 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.
   3. 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.

4. 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:
   1. 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,
   2. 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,
   3. 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.

5. 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.
6. 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.
7. 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.
8. 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.
9. 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.
10. 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.
11. 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.
12. 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.
13. 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.

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms. To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.

one line to give the program's name and a brief idea of what it does.
Copyright (C) 19yy  name of author
This program is free software; you can redistribute it and/or modify 
it under the terms of the GNU General Public License as published by 
the Free Software Foundation; either version 2 of the License, or 
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.

Also add information on how to contact you by electronic and paper mail. If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

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

The hypothetical commands ‘show w’ and ‘show c’ should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than ‘show w’ and ‘show c’; they could even be mouse-clicks or menu items—whatever suits your program. You should also get your employer (if you work as a programmer) or your school, if any, to sign a “copyright disclaimer” for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.
signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice

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

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. See Contributors to GNU CC in Using and Porting GNU CC, 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
• 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, because version 0.6 is still a ways off.
• 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.
• 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.

1 Funding Free Software

If you want to have more free software a few years from now, it makes sense for you to help encourage people to contribute funds for its development. The most effective approach known is to encourage commercial redistributors to donate. Users of free software systems can boost the pace of development by encouraging for-a-fee distributors to donate part of their selling price to free software developers—the Free Software Foundation, and others. The way to convince distributors to do this is to demand it and expect it from them. So when you compare distributors, judge them partly by how much they give to free software development. Show distributors they must compete to be the one who gives the most. To make this approach work, you must insist on numbers that you can compare, such as, “We will donate ten dollars to the Frobnitz project for each disk sold.” Don’t be satisfied with a vague promise, such as “A portion of the profits are donated,” since it doesn’t give a basis for comparison. Even a precise fraction “of the profits from this disk” is not very meaningful, since creative accounting and unrelated business decisions can greatly alter what fraction of the sales price counts as profit. If the price you pay is $50, ten percent of the profit is probably less than a dollar; it might be a few cents, or nothing at all. Some redistributors do development work themselves. This is useful too; but to keep everyone honest, you need to inquire how much they do, and what kind. Some kinds of development make much more long-term difference than others. For example, maintaining a separate version of a program contributes very little; maintaining the standard version of a program for the whole community contributes much. Easy new ports contribute little, since someone else would surely do them; difficult ports such as adding a new CPU to the GNU C compiler contribute more; major new features or packages contribute the most. By establishing the idea that supporting further development is “the proper thing to do” when distributing free software for a fee, we can assure a steady flow of resources into making more free software.

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

2 Funding GNU Fortran

Work on GNU Fortran is still being done mostly by its author, James Craig Burley (burley@gnu.org), who is a volunteer for, not an employee of, the Free Software Foundation (FSF). As with other GNU software, funding is important because it can pay for needed equipment, personnel, and so on. The FSF provides information on the best way to fund ongoing development of GNU software (such as GNU Fortran) in documents such as the “GNUS Bulletin”. Email gnu@prep.ai.mit.edu for information on funding the FSF. To fund specific GNU Fortran work in particular, the FSF might provide a means for that, but the FSF does not provide direct funding to the author of GNU Fortran to continue his work. The FSF has employee salary restrictions that can be incompatible with the financial needs of some volunteers, who therefore choose to remain volunteers and thus be able to be free to do contract work and otherwise make their own schedules for doing GNU work. Still, funding the FSF at least indirectly benefits work on specific projects like GNU Fortran because it ensures the continuing operation of the FSF offices, their workstations, their network connections, and so on, which are invaluable to volunteers. (Similarly, hiring Cygnus Support can help a project like GNU Fortran—Cygnus has been a long-time donor of equipment usage to the author of GNU Fortran, and this too has been invaluable—See section Contributors to GNU Fortran.) Currently, the only way to directly fund the author of GNU Fortran in his work on that project is to hire him for the work you want him to do, or donate money to him. Several people have done this already, with the result that he has not needed to immediately find contract work on a few occasions. If more people did this, he would be able to plan on not doing contract work for many months and could thus devote that time to work on projects (such as the planned changes for 0.6) that require longer timeframes to complete. For the latest information on the status of the author, do finger -l burley@gnu.org on a UNIX system (or any system with a command like UNIX finger). Another important way to support work on GNU Fortran is to volunteer to help out. Work is needed on documentation, testing, porting to various machines, and in some cases, coding (although major changes planned for version 0.6 make it difficult to add manpower to this area). Email fortran@gnu.org to volunteer for this work. See section Funding Free Software, for more information.

3 Protect Your Freedom—Fight “Look And Feel”

To preserve the ability to write free software, including replacements for proprietary software, authors must be free to replicate the user interface to which users of existing software have become accustomed. See Protect Your Freedom—Fight “Look And Feel” in Using and Porting GNU CC, for more information.

4 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 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 Compile Fortran, C, or Other Programs. Everyone except experienced g77 users should see GNU Fortran Command Options. If you’re acquainted with previous versions of g77, you should see @ref{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 User-visible 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 The GNU Fortran Language. If you don’t already have g77 installed on your system, you must see @ref{Installation}. If you run into trouble getting Fortran code to compile, link, run, or work properly, you might find answers if you see Debugging and Interfacing, see Collected Fortran Wisdom, and see Known Causes of Trouble with GNU Fortran. You might also find that the problems you are encountering are bugs in g77—see Reporting 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 How To Get Help with GNU Fortran. If you would like to help the g77 project, see Funding GNU Fortran, for information on helping financially, and see Projects, for information on helping in other ways. If you’re generally curious about the future of g77, see Projects. If you’re curious about its past, see Contributors to GNU Fortran, and see Funding GNU Fortran. To see a few of the questions maintainers of g77 have, and that you might be able to answer, see Open Questions.

5 What is GNU Fortran?

GNU Fortran, or g77, is designed initially as a free replacement for, or alternative to, the UNIX f77 command. (Similarly, gcc is designed as a replacement for the UNIX cc command.) g77 also is designed to fit in well with the other fine GNU compilers and tools. Sometimes these design goals conflict—in such cases, resolution often is made in favor of fitting in well with Project GNU. These cases are usually identified in the appropriate sections of this manual. As compilers, g77, gcc, and f77 share the following characteristics:

• They read a user’s program, stored in a file and containing instructions written in the appropriate language (Fortran, C, and so on). This file contains source code.
• They translate the user’s program into instructions a computer can carry out more quickly than it takes to translate the instructions in the first place. These instructions are called machine code—code designed to be efficiently translated and processed by a machine such as a computer. Humans usually aren’t as good writing machine code as they are at writing Fortran or C, because it is easy to make tiny mistakes writing machine code. When writing Fortran or C, it is easy to make big mistakes.
• They provide information in the generated machine code that can make it easier to find bugs in the program (using a debugging tool, called a debugger, such as gdb).
• They locate and gather machine code already generated to perform actions requested by statements in the user’s program. This machine code is organized into libraries and is located and gathered during the link phase of the compilation process. (Linking often is thought of as a separate step, because it can be directly invoked via the ld command. However, the g77 and gcc commands, as with most compiler commands, automatically perform the linking step by calling on ld directly, unless asked to not do so by the user.)
• They attempt to diagnose cases where the user’s program contains incorrect usages of the language. The diagnostics produced by the compiler indicate the problem and the location in the user’s source file where the problem was first noticed. The user can use this information to locate and fix the problem. (Sometimes an incorrect usage of the language leads to a situation where the compiler can no longer make any sense of what follows—while a human might be able to—and thus ends up complaining about many “problems” it encounters that, in fact, stem from just one problem, usually the first one reported.)
• They attempt to diagnose cases where the user’s program contains a correct usage of the language, but instructs the computer to do something questionable. These diagnostics often are in the form of warnings, instead of the errors that indicate incorrect usage of the language.

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

• A modified version of the gcc command, which also might be installed as the system’s cc command. (In many cases, cc refers to the system’s “native” C compiler, which might be a non-GNU compiler, or an older version of gcc considered more stable or that is used to build the operating system kernel.)
• The g77 command itself, which also might be installed as the system’s f77 command.
• The libf2c run-time library. This library contains the machine code needed to support capabilities of the Fortran language that are not directly provided by the machine code generated by the g77 compilation phase.
• The compiler itself, internally named f771. Note that f771 does not generate machine code directly—it generates assembly code that is a more readable form of machine code, leaving the conversion to actual machine code to an assembler, usually named as.

gcc is often thought of as “the C compiler” only, but it does more than that. Based on command-line options and the names given for files on the command line, gcc determines which actions to perform, including preprocessing, compiling (in a variety of possible languages), assembling, and linking. For example, the command ‘gcc foo.c’ drives the file ‘foo.c’ through the preprocessor cpp, then the C compiler (internally named cc1), then the assembler (usually as), then the linker (ld), producing an executable program named ‘a.out’ (on UNIX systems). As another example, the command ‘gcc foo.cc’ would do much the same as ‘gcc foo.c’, but instead of using the C compiler named cc1, gcc would use the C++ compiler (named cc1plus). In a GNU Fortran installation, gcc recognizes Fortran source files by name just like it does C and C++ source files. It knows to use the Fortran compiler named f771, instead of cc1 or cc1plus, to compile Fortran files. Non-Fortran-related operation of gcc is generally unaffected by installing the GNU Fortran version of gcc. However, without the installed version of gcc being the GNU Fortran version, gcc will not be able to compile and link Fortran programs—and since g77 uses gcc to do most of the actual work, neither will g77! The g77 command is essentially just a front-end for the gcc command. Fortran users will normally use g77 instead of gcc, because g77 knows how to specify the libraries needed to link with Fortran programs (libf2c and lm). g77 can still compile and link programs and source files written in other languages, just like gcc. The command ‘g77 -v’ is a quick way to display lots of version information for the various programs used to compile a typical preprocessed Fortran source file—this produces much more output than ‘gcc -v’ currently does. (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 libf2c, so libf2c must be linked with almost every useful program having any component compiled by GNU Fortran. (As mentioned above, the g77 command takes care of all this for you.) The f771 program represents most of what is unique to GNU Fortran. While much of the libf2c component is really part 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).

6 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. See Compile C; C++; or Objective-C in Using and Porting GNU CC, for information on the way different languages are handled by the GNU CC compiler (gcc). Also provided as part of GNU Fortran is the g77 command. The g77 command is designed to make compiling and linking Fortran programs somewhat easier than when using the gcc command for these tasks. It does this by analyzing the command line somewhat and changing it appropriately before submitting it to the gcc command. Use the ‘-v’ option with g77 to see what is going on—the first line of output is the invocation of the gcc command. Use ‘--driver=true’ to disable actual invocation of gcc (this works because ‘true’ is the name of a UNIX command that simply returns success status).

7 GNU Fortran Command Options

The g77 command supports all the options supported by the gcc command. See GNU CC Command Options in Using and Porting GNU CC, for information on the non-Fortran-specific aspects of the gcc command (and, therefore, the g77 command). The g77 command supports one option not supported by the gcc command:

--driver=command

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

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

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

See section Options Controlling the Kind of Output.

--driver  -fversion  -fset-g77-defaults  -fno-silent

Shorthand Options

See section Shorthand Options.

-ff66  -fno-f66  -ff77  -fno-f77  -fugly  -fno-ugly

Fortran Language Options

See section Options Controlling Fortran Dialect.

-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

See section Options to Request or Suppress Warnings.

-fsyntax-only  -pedantic  -pedantic-errors  -fpedantic
-w  -Wno-globals  -Wimplicit -Wunused  -Wuninitialized
-Wall  -Wsurprising
-Werror  -W

Debugging Options

See section Options for Debugging Your Program or GCC.

Optimization Options

See section Options that Control Optimization.

-malign-double
-ffloat-store  -fforce-mem  -fforce-addr  -fno-inline
-ffast-math  -fstrength-reduce  -frerun-cse-after-loop
-fexpensive-optimizations  -fdelayed-branch
-fschedule-insns  -fschedule-insn2  -fcaller-saves
-funroll-loops  -funroll-all-loops
-fno-move-all-movables  -fno-reduce-all-givs
-fno-rerun-loop-opt

Directory Options

See section Options for Directory Search.

-Idir  -I-

Code Generation Options

See section Options for Code Generation Conventions.

-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
-fdebug-kludge  -fno-emulate-complex
-falias-check  -fargument-alias
-fargument-noalias  -fno-argument-noalias-global
-fno-globals

7.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. See (Using and Porting GNU CC)gcc, for information on suffixes recognized by GNU CC.

file.f

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.

file.F

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

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 avoid unpleasant surprises. See Options Controlling the Preprocessor in Using and Porting GNU CC. 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. The following options that affect overall processing are recognized by the g77 and gcc commands in a GNU Fortran installation:

--driver=command

This works when invoking only the g77 command, not when invoking the gcc command. See section GNU Fortran Command Options, for information on this option.

-fversion

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

-fset-g77-defaults

Set up whatever gcc options are to apply to Fortran compilations, and avoid running internal consistency checks that might take some time. As of version 0.5.20, this is equivalent to ‘-fmove-all-movables -freduce-all-givs -frerun-loop-opt -fargument-noalias-global’. 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.

See Options Controlling the Kind of Output in Using and Porting GNU CC, for information on more options that control the overall operation of the gcc command (and, by extension, the g77 command).

7.3 Shorthand Options

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

-fugly

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. See section Distensions, for more information. Note: The ‘-fugly’ option is likely to be removed in a future version. Implicitly 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.

-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

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

7.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.) See section 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. See section 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. See section 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)’). See section 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’). See section 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(*)’. See section 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)’. See section 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. See section 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’. See section 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. See section Ugly Integer Conversions, for more information.

-fonetrip

Imperative executable 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 imperative 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 (imperative) 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'

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. See section 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. See section 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. See section 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. See section 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. See section 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. See section 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. See section 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’. See section Source Form, for more information.

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

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

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

See Options to Request or Suppress Warnings in Using and Porting GNU CC, for information on more options offered by the GBE shared by g77, gcc, and other GNU compilers. Some of these have no effect when compiling programs written in Fortran:

-Wcomment

-Wformat

-Wparentheses

-Wswitch

-Wtraditional

-Wshadow

-Wid-clash-len

-Wlarger-than-len

-Wconversion

-Waggregate-return

-Wredundant-decls

These options all could have some relevant meaning for GNU Fortran programs, but are not yet supported.

7.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. Support for this option in Fortran programs is incomplete. In particular, names of variables and arrays in common blocks or that are storage-associated via EQUIVALENCE are unavailable to the debugger. However, version 0.5.19 of g77 does provide this information in a rudimentary way, as controlled by the ‘-fdebug-kludge’ option. See section Options for Code Generation Conventions, for more information.

See Options for Debugging Your Program or GNU CC in Using and Porting GNU CC, for more information on debugging options.

7.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. The following flags have particular applicability when compiling Fortran programs:

-malign-double

(Intel 386 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. Also note: g77 fixes a gcc backend bug to allow ‘-malign-double’ to work generally, not just with statically-allocated data. 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.

-fforce-mem

-fforce-addr

Might improve optimization of loops.

-fno-inline

Don’t compile statement functions inline. Might reduce the size of a program unit—which might be at expense of some speed (though it should compile faster). Note that if you are not optimizing, no functions can be expanded inline.

-ffast-math

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

-fstrength-reduce

Might make some loops run faster.

-frerun-cse-after-loop

-fexpensive-optimizations

-fdelayed-branch

-fschedule-insns

-fschedule-insns2

-fcaller-saves

Might improve performance on some code.

-funroll-loops

Definitely improves performance on some code.

-funroll-all-loops

Definitely improves performance on some code.

-fno-move-all-movables

-fno-reduce-all-givs

-fno-rerun-loop-opt

Each of these might improve performance on some code. Analysis of Fortran code optimization and the resulting optimizations triggered by the above options were contributed by Toon Moene (toon@moene.indiv.nluug.nl). These three options are intended to be removed someday, once they have helped determine the efficacy of various approaches to improving the performance of Fortran code. Please let us know how use of these options affects the performance of your production code. We’re particularly interested in code that runs faster when these options are disabled, and in non-Fortran code that benefits when they are enabled via the above gcc command-line options.

See Options That Control Optimization in Using and Porting GNU CC, for more information on options to optimize the generated machine code.

7.8 Options Controlling the Preprocessor

These options control the C preprocessor, which is run on each C source file before actual compilation. See Options Controlling the Preprocessor in Using and Porting GNU CC, 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. See section Options for Directory Search, 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.

7.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 preproecssor 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. See Options for Directory Search in Using and Porting GNU CC, for information on the ‘-I’ option.

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

-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 libf2c library. However, because the libf2c 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-callable 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 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-compiled code with other languages. Note that just because the names match does not mean that the interface implemented by g77 for an external name matches the interface implemented by some other language for that same name. That is, getting code produced by g77 to link to code produced by some other compiler using this or any other method can be only a small part of the overall solution—getting the code generated by both compilers to agree on issues other than naming can require significant effort, and, unlike naming disagreements, linkers normally cannot detect disagreements in these other areas. Also, note that with ‘-fno-underscoring’, the lack of appended underscores introduces the very real possibility that a user-defined external name will conflict with a name in a system library, which could make finding unresolved-reference bugs quite difficult in some cases—they might occur at program run time, and show up only as buggy behavior at run time. In future versions of g77, we hope to improve naming and linking issues so that debugging always involves using the names as they appear in the source, even if the names as seen by the linker are mangled to prevent accidental linking between procedures with incompatible interfaces.

-fno-second-underscore

Do not append a second underscore to names of entities specified in the Fortran source file. This option has no effect if ‘-fno-underscoring’ is 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.

-fdebug-kludge

Emit information on COMMON and EQUIVALENCE members that might help users of debuggers work around lack of proper debugging information on such members. As of version 0.5.19, g77 offers this option to emit information on members of aggregate areas to help users while debugging. This information consists of establishing the type and contents of each such member so that, when a debugger is asked to print the contents, the printed information provides rudimentary debugging information. This information identifies the name of the aggregate area (either the COMMON block name, or the g77-assigned name for the EQUIVALENCE name) and the offset, in bytes, of the member from the beginning of the area. Using gdb, this information is not coherently displayed in the Fortran language mode, so temporarily switching to the C language mode to display the information is suggested. Use ‘set language c’ and ‘set language fortran’ to accomplish this. For example:

      COMMON /X/A,B
      EQUIVALENCE (C,D)
      CHARACTER XX*50
      EQUIVALENCE (I,XX(20:20))
      END
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
(gdb) b MAIN__
Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
(gdb) r
Starting program: /home/user/a.out
Breakpoint 1, MAIN__ () at cd.f:5
Current language:  auto; currently fortran
(gdb) set language c
Warning: the current language does not match this frame.
(gdb) p a
$2 = "At (COMMON) `x_' plus 0 bytes"
(gdb) p b
$3 = "At (COMMON) `x_' plus 4 bytes"
(gdb) p c
$4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
(gdb) p d
$5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
(gdb) p i
$6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
(gdb) p xx
$7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
(gdb) set language fortran
(gdb) 

Use ‘-fdebug-kludge’ to generate this information, which might make some programs noticeably larger. Caution: Future versions of g77 might disregard this option (and its negative form). Current plans call for this to happen when published versions of g77 and gdb exist that provide proper access to debugging information on COMMON and EQUIVALENCE members.

-fno-emulate-complex

Implement COMPLEX arithmetic using the facilities in the gcc back end that provide direct support of complex arithmetic, instead of emulating the arithmetic. gcc has some known problems in its back-end support for complex arithmetic, due primarily to the support not being completed as of version 2.7.2.2. Other front ends for the gcc back end avoid this problem by emulating complex arithmetic at a higher level, so the back end sees arithmetic on the real and imaginary components. To make g77 more portable to systems where complex support in the gcc back end is particularly troublesome, g77 now defaults to performing the same kinds of emulations done by these other front ends. Use ‘-fno-emulate-complex’ to try the complex support in the gcc back end, in case it works and produces faster programs. So far, all the known bugs seem to involve compile-time crashes, rather than 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. Caution: Future versions of g77 are likely to change the default for this option to ‘-fno-emulate-complex’, and perhaps someday ignore both forms of this option. Also, it is possible that use of the ‘-fno-emulate-complex’ option could result in incorrect code being silently produced by g77. But, this is generally true of compilers anyway, so, as usual, test the programs you compile before assuming they are working.

-falias-check

-fargument-alias

-fargument-noalias

-fno-argument-noalias-global

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). See section 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 g77 exposes via a diagnostic. 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.

See Options for Code Generation Conventions in Using and Porting GNU CC, for information on more options offered by the GBE shared by g77, gcc, and other GNU compilers. Some of these do not work when compiling programs written in Fortran:

-fpcc-struct-return

-freg-struct-return

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

-fshort-double

This probably either has no effect on Fortran programs, or makes them act loopy.

-fno-common

Do not use this when compiling Fortran programs, or there will be Trouble.

-fpack-struct

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

7.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. See Environment Variables Affecting GNU CC in Using and Porting GNU CC, for information on environment variables.

8 User-visible Changes

This section 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. @xref{News,,News About GNU Fortran}, for information on such changes to g77. To find out about existing bugs and ongoing plans for GNU Fortran, retrieve ftp://alpha.gnu.org/g77.plan or, if you cannot do that, email fortran@gnu.org asking for a recent copy of the GNU Fortran ‘.plan’ file.

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 names to strip trailing spaces from them, for consistency with other implementations.
• 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.
• CTIME intrinsic now accepts any INTEGER argument, not just INTEGER(KIND=2).

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.) See section Options Controlling Fortran Dialect, 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. See section 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 by 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. See section 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. See section 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. See section 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 systems, this won’t make a noticable 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. See section 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.) See section 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.

In 0.5.19:

• A temporary kludge option provides bare-bones information on COMMON and EQUIVALENCE members at debug time. See section Options for Code Generation Conventions, for information on the ‘-fdebug-kludge’ option.
• New ‘-fonetrip’ option specifies FORTRAN-66-style one-trip DO loops.
• New ‘-fno-silent’ option causes names of program units to be printed as they are compiled, in a fashion similar to UNIX f77 and f2c.
• New ‘-fugly-assumed’ option specifies that arrays dimensioned via ‘DIMENSION X(1)’, for example, are to be treated as assumed-size.
• New ‘-fno-typeless-boz’ 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.
• New ‘-ff66’ option is a “shorthand” option that specifies behaviors considered appropriate for FORTRAN 66 programs.
• New ‘-ff77’ option is a “shorthand” option that specifies behaviors considered appropriate for UNIX f77 programs.
• New ‘-fugly-comma’ and ‘-fugly-logint’ options provided to perform some of what ‘-fugly’ used to do. ‘-fugly’ and ‘-fno-ugly’ are now “shorthand” options, in that they do nothing more than enable (or disable) other ‘-fugly-*’ options.
• Change code generation for list-directed I/O so it allows for new versions of libf2c that might return non-zero status codes for some operations previously assumed to always return zero. This change not only affects how IOSTAT= variables are set by list-directed I/O, it also affects whether END= and ERR= labels are reached by these operations.
• Add intrinsic support for new FTELL and FSEEK procedures in libf2c.
• Add options ‘--help’ and ‘--version’ to the g77 command, to conform to GNU coding guidelines. Also add printing of g77 version number when the ‘--verbose’ (‘-v’) option is used.

In 0.5.18:

• The BYTE and WORD statements now are supported, to a limited extent.
• INTEGER*1, INTEGER*2, INTEGER*8, and their LOGICAL equivalents, now are supported to a limited extent. Among the missing elements are complete intrinsic and constant support.
• Support automatic arrays in procedures. For example, ‘REAL A(N)’, where ‘A’ is not a dummy argument, specifies that ‘A’ is an automatic array. The size of ‘A’ is calculated from the value of ‘N’ each time the procedure is called, that amount of space is allocated, and that space is freed when the procedure returns to its caller.
• Add ‘-fno-zeros’ option, enabled by default, to reduce compile-time CPU and memory usage for code that provides initial zero values for variables and arrays.
• Introduce three new options that apply to all compilations by g77-aware GNU compilers—‘-fmove-all-movables’, ‘-freduce-all-givs’, and ‘-frerun-loop-opt’—which can improve the run-time performance of some programs.
• Replace much of the existing documentation with a single Info document.
• New option ‘-fno-second-underscore’.

In 0.5.17:

• The ERF() and ERFC() intrinsics now are generic intrinsics, mapping to ERF/DERF and ERFC/DERFC, respectively. Note: Use ‘INTRINSIC ERF,ERFC’ in any code that might reference these as generic intrinsics, to improve the likelihood of diagnostics (instead of subtle run-time bugs) when using compilers that don’t support these as intrinsics.
• New option ‘-Wsurprising’.
• DO loops with non-INTEGER variables now diagnosed only when ‘-Wsurprising’ specified. Previously, this was diagnosed unless ‘-fpedantic’ or ‘-fugly’ was specified.

In 0.5.16:

• libf2c changed to output a leading zero (0) digit for floating-point values output via list-directed and formatted output (to bring g77 more into line with many existing Fortran implementations—the ANSI FORTRAN 77 standard leaves this choice to the implementation).
• libf2c no longer built with debugging information intact, making it much smaller.
• Automatic installation of the g77 command now works.
• Diagnostic messages now more informative, a la gcc, including messages like ‘In function `foo':’ and ‘In file included from...:’.
• New group of intrinsics called ‘unix’, including ABORT, DERF, DERFC, ERF, ERFC, EXIT, FLUSH, GETARG, GETENV, SIGNAL, and SYSTEM.
• ‘-funix-intrinsics-{delete,hide,disable,enable}’ options added.
• ‘-fno-underscoring’ option added.
• ‘--driver’ option added to the g77 command.
• Support for the gcc options ‘-fident’ and ‘-fno-ident’ added.
• ‘g77 -v’ returns much more version info, making the submission of better bug reports easily.
• Many improvements to the g77 command to better fulfill its role as a front-end to the gcc driver. For example, g77 now recognizes ‘--verbose’ as a verbose way of specifying ‘-v’.
• Compiling preprocessed (‘*.F’ and ‘*.fpp’) files now results in better diagnostics and debugging information, as the source-location info now is passed all the way through the compilation process instead of being lost.

9 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://kumo.swcp.com/fortran/F77_std/f77_std.html or in ftp://ftp.ast.cam.ac.uk/pub/michael/. 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/fortran/Books/.) 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. See section 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!

Relationship to the ANSI FORTRAN 77 standard:

9.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, heteregenous 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. See section 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).

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

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

It isn’t clear whether the standard considers this conforming.

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

It isn’t clear whether the standard considers this conforming.

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

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

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

9.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. See section 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).

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

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

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

9.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). See section Construct Names, for more information.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9.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(%LOC(I))’, and in fact might compile to identical code. However, ‘CALL FOO(%LOC(I))’ emphatically means “pass 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(%LOC(I))’ using the same version or compiler. See section Debugging and Interfacing, for detailed information on how this particular version of g77 implements various constructs.

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

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

9.9.2 DOUBLE COMPLEX Statement

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

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

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

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

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

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

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.

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

9.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.) See section Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

9.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. See section Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

9.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. See section Procedures (SUBROUTINE and FUNCTION), for detailed information on how this particular version of g77 passes arguments to procedures.

9.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 1997-05-21 (Burley) to accommodate compilers that implement
C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
C Version 0:
C Written by James Craig Burley 1997-02-20.
C Contact via Internet email: burley@gnu.org
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 If your compiler implements INTEGER*2 and INTEGER
C as the same type, change all INTEGER*2 below to
C INTEGER*1.
      INTEGER*2 I0, I4
      INTEGER I1, I2, I3
      INTEGER*2 ISMALL, ILARGE
      INTEGER*2 ITOOLG, ITWO
      INTEGER*2 ITMP
      LOGICAL L2, L3, L4
C Find smallest INTEGER*2 number.
      ISMALL=0
 10   I0 = ISMALL-1
      IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
      ISMALL = I0
      GOTO 10
 20   CONTINUE
C Find largest INTEGER*2 number.
      ILARGE=0
 30   I0 = ILARGE+1
      IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
      ILARGE = I0
      GOTO 30
 40   CONTINUE
C Multiplying by two adds stress to the situation.
      ITWO = 2
C Need a number that, added to -2, is too wide to fit in I*2.
      ITOOLG = ISMALL
C Use IDIM the straightforward way.
      I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
C Calculate result for first interpretation.
      I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
C Calculate result for second interpretation.
      ITMP = ILARGE - ISMALL
      I3 = (INT (ITMP)) * ITWO + ITOOLG
C Calculate result for third interpretation.
      I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
C Print results.
      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).

9.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))’. See section Ugly Complex Part Extraction, for more information.

9.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. @xref{Complex Intrinsic}, for more information.

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

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

9.11.9 Table of Intrinsic Functions

(Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.) The GNU Fortran language adds various functions, subroutines, types, and arguments to the set of intrinsic functions in ANSI FORTRAN 77. The complete set of intrinsics supported by the GNU Fortran language is described below. Note that a name is not treated as that of an intrinsic if it is specified in an EXTERNAL statement in the same program unit; if a command-line option is used to disable the groups to which the intrinsic belongs; or if the intrinsic is not named in an INTRINSIC statement and a command-line option is used to hide the groups to which the intrinsic belongs. So, it is recommended that any reference in a program unit to an intrinsic procedure that is not a standard FORTRAN 77 intrinsic be accompanied by an appropriate INTRINSIC statement in that program unit. This sort of defensive programming makes it more likely that an implementation will issue a diagnostic rather than generate incorrect code for such a reference. The terminology used below is based on that of the Fortran 90 standard, so that the text may be more concise and accurate:

• OPTIONAL means the argument may be omitted.
• ‘A-1, A-2, …, A-n’ means more than one argument (generally named ‘A’) may be specified.
• ‘scalar’ means the argument must not be an array (must be a variable or array element, or perhaps a constant if expressions are permitted).
• ‘DIMENSION(4)’ means the argument must be an array having 4 elements.
• INTENT(IN) means the argument must be an expression (such as a constant or a variable that is defined upon invocation of the intrinsic).
• INTENT(OUT) means the argument must be definable by the invocation of the intrinsic (that is, must not be a constant nor an expression involving operators other than array reference and substring reference).
• INTENT(INOUT) means the argument must be defined prior to, and definable by, invocation of the intrinsic (a combination of the requirements of INTENT(IN) and INTENT(OUT).
• See section Kind Notation for explanation of KIND.

9.12 Scope and Classes of Symbolic Names

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

9.12.1 Underscores in Symbol Names

Underscores (‘_’) are accepted in symbol names after the first character (which must be a letter).

10 Other Dialects

GNU Fortran supports a variety of features that are not considered part of the GNU Fortran language itself, but are representative of various dialects of Fortran that g77 supports in whole or in part. Any of the features listed below might be disallowed by g77 unless some command-line option is specified. Currently, some of the features are accepted using the default invocation of g77, but that might change in the future. Note: This portion of the documentation definitely needs a lot of work!

10.1 Source Form

GNU Fortran accepts programs written in either fixed form or free form. Fixed form corresponds to ANSI FORTRAN 77 (plus popular extensions, such as allowing tabs) and Fortran 90’s fixed form. Free form corresponds to Fortran 90’s free form (though possibly not entirely up-to-date, and without complaining about some things that for which Fortran 90 requires diagnostics, such as the spaces in the constant in ‘R = 3 . 1’). The way a Fortran compiler views source files depends entirely on the implementation choices made for the compiler, since those choices are explicitly left to the implementation by the published Fortran standards. GNU Fortran currently tries to be somewhat like a few popular compilers (f2c, Digital (“DEC”) Fortran, and so on), though a cleaner default definition along with more flexibility offered by command-line options is likely to be offered in version 0.6. This section describes how g77 interprets source lines.

10.1.1 Carriage Returns

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

10.1.2 Tabs

A source line with a <TAB> character anywhere in it is treated as entirely significant—however long it is—instead of ending in column 72 (for fixed-form source) or 132 (for free-form source). This also is different from f2c, which encodes tabs as ‘\t’ (the ASCII <TAB> character) inside character and Hollerith constants, but nevertheless seems to treat the column position as if it had been affected by the canonical tab positioning. g77 effectively translates tabs to the appropriate number of spaces (a la the default for the UNIX expand command) before doing any other processing, other than (currently) noting whether a tab was found on a line and using this information to decide how to interpret the length of the line and continued constants. Note that this default behavior probably will change for version 0.6, when it will presumably be available via a command-line option. The default as of version 0.6 is planned to be a “pure visual” model, where tabs are immediately converted to spaces and otherwise have no effect, so the way a typical user sees source lines produces a consistent result no matter how the spacing in those source lines is actually implemented via tabs, spaces, and trailing tabs/spaces before newline. Command-line options are likely to be added to specify whether all or just-tabbed lines are to be extended to 132 or full input-line length, and perhaps even an option will be added to specify the truncated-line behavior to which some Digital compilers default (and which affects the way continued character/Hollerith constants are interpreted).

10.1.3 Short Lines

Source lines shorter than the applicable fixed-form length are treated as if they were padded with spaces to that length. (None of this is relevant to source files written in free form.) This affects only continued character and Hollerith constants, and is a different interpretation than provided by some other popular compilers (although a bit more consistent with the traditional punched-card basis of Fortran and the way the Fortran standard expressed fixed source form). g77 might someday offer an option to warn about cases where differences might be seen as a result of this treatment, and perhaps an option to specify the alternate behavior as well. Note that this padding cannot apply to lines that are effectively of infinite length—such lines are specified using command-line options like ‘-ffixed-line-length-none’, for example.

10.1.4 Long Lines

Source lines longer than the applicable length are truncated to that length. Currently, g77 does not warn if the truncated characters are not spaces, to accommodate existing code written for systems that treated truncated text as commentary (especially in columns 73 through 80). See section Options Controlling Fortran Dialect, for information on the ‘-ffixed-line-length-n’ option, which can be used to set the line length applicable to fixed-form source files.

10.1.5 Ampersand Continuation Line

A ‘&’ in column 1 of fixed-form source denotes an arbitrary-length continuation line, imitating the behavior of f2c.

10.2 Trailing Comment

g77 supports use of ‘/*’ to start a trailing comment. In the GNU Fortran language, ‘!’ is used for this purpose. ‘/*’ is not in the GNU Fortran language because the use of ‘/*’ in a program might suggest to some readers that a block, not trailing, comment is started (and thus ended by ‘*/’, not end of line), since that is the meaning of ‘/*’ in C. Also, such readers might think they can use ‘//’ to start a trailing comment as an alternative to ‘/*’, but ‘//’ already denotes concatenation, and such a “comment” might actually result in a program that compiles without error (though it would likely behave incorrectly).

10.3 Debug Line

Use of ‘D’ or ‘d’ as the first character (column 1) of a source line denotes a debug line. In turn, a debug line is treated as either a comment line or a normal line, depending on whether debug lines are enabled. When treated as a comment line, a line beginning with ‘D’ or ‘d’ is treated as if it the first character was ‘C’ or ‘c’, respectively. When treated as a normal line, such a line is treated as if the first character was <SPC> (space). (Currently, g77 provides no means for treating debug lines as normal lines.)

10.4 Dollar Signs in Symbol Names

Dollar signs (‘$’) are allowed in symbol names (after the first character) when the ‘-fdollar-ok’ option is specified.

10.5 Case Sensitivity

GNU Fortran offers the programmer way too much flexibility in deciding how source files are to be treated vis-a-vis uppercase and lowercase characters. There are 66 useful settings that affect case sensitivity, plus 10 settings that are nearly useless, with the remaining 116 settings being either redundant or useless. None of these settings have any effect on the contents of comments (the text after a ‘c’ or ‘C’ in Column 1, for example) or of character or Hollerith constants. Note that things like the ‘E’ in the statement ‘CALL FOO(3.2E10)’ and the ‘TO’ in ‘ASSIGN 10 TO LAB’ are considered built-in keywords, and so are affected by these settings. Low-level switches are identified in this section as follows:

• A Source Case Conversion:
  • 0 Preserve (see Note 1)
  • 1 Convert to Upper Case
  • 2 Convert to Lower Case
• B Built-in Keyword Matching:
  • 0 Match Any Case (per-character basis)
  • 1 Match Upper Case Only
  • 2 Match Lower Case Only
  • 3 Match InitialCaps Only (see tables for spellings)
• C Built-in Intrinsic Matching:
  • 0 Match Any Case (per-character basis)
  • 1 Match Upper Case Only
  • 2 Match Lower Case Only
  • 3 Match InitialCaps Only (see tables for spellings)
• D User-defined Symbol Possibilities (warnings only):
  • 0 Allow Any Case (per-character basis)
  • 1 Allow Upper Case Only
  • 2 Allow Lower Case Only
  • 3 Allow InitialCaps Only (see Note 2)

Note 1: g77 eventually will support NAMELIST in a manner that is consistent with these source switches—in the sense that input will be expected to meet the same requirements as source code in terms of matching symbol names and keywords (for the exponent letters). Currently, however, NAMELIST is supported by libf2c, which uppercases NAMELIST input and symbol names for matching. This means not only that NAMELIST output currently shows symbol (and keyword) names in uppercase even if lower-case source conversion (option A2) is selected, but that NAMELIST cannot be adequately supported when source case preservation (option A0) is selected. If A0 is selected, a warning message will be output for each NAMELIST statement to this effect. The behavior of the program is undefined at run time if two or more symbol names appear in a given NAMELIST such that the names are identical when converted to upper case (e.g. ‘NAMELIST /X/ VAR, Var, var’). For complete and total elegance, perhaps there should be a warning when option A2 is selected, since the output of NAMELIST is currently in uppercase but will someday be lowercase (when a libg77 is written), but that seems to be overkill for a product in beta test. Note 2: Rules for InitialCaps names are:

• – Must be a single uppercase letter, or
• – Must start with an uppercase letter and contain at least one lowercase letter.

So ‘A’, ‘Ab’, ‘ABc’, ‘AbC’, and ‘Abc’ are valid InitialCaps names, but ‘AB’, ‘A2’, and ‘ABC’ are Note that most, but not all, built-in names meet these requirements—the exceptions are some of the two-letter format specifiers, such as ‘BN’ and ‘BZ’. Here are the names of the corresponding command-line options:

A0: -fsource-case-preserve
A1: -fsource-case-upper
A2: -fsource-case-lower
B0: -fmatch-case-any
B1: -fmatch-case-upper
B2: -fmatch-case-lower
B3: -fmatch-case-initcap
C0: -fintrin-case-any
C1: -fintrin-case-upper
C2: -fintrin-case-lower
C3: -fintrin-case-initcap
D0: -fsymbol-case-any
D1: -fsymbol-case-upper
D2: -fsymbol-case-lower
D3: -fsymbol-case-initcap

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

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

Number 22 is the “strict” ANSI FORTRAN 77 model wherein all input (except comments, character constants, and Hollerith strings) must be entered in uppercase. Use ‘-fcase-strict-upper’ to specify this combination. Number 43 is like Number 22 except all input must be lowercase. Use ‘-fcase-strict-lower’ to specify this combination. Number 65 is the “classic” ANSI FORTRAN 77 model as implemented on many non-UNIX machines whereby all the source is translated to uppercase. Use ‘-fcase-upper’ to specify this combination. Number 66 is the “canonical” UNIX model whereby all the source is translated to lowercase. Use ‘-fcase-lower’ to specify this combination. There are a few nearly useless combinations:

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

The above allow some programs to be compiled but with restrictions that make most useful programs impossible: Numbers 67 and 72 warn about any user-defined symbol names (such as ‘SUBROUTINE FOO’); Numbers 68 and 73 warn about any user-defined symbol names longer than one character that don’t have at least one non-alphabetic character after the first; Numbers 69 and 74 disallow any references to intrinsics; and Numbers 70, 71, 75, and 76 are combinations of the restrictions in 67+69, 68+69, 72+74, and 73+74, respectively. All redundant combinations are shown in the above tables anyplace where more than one setting is shown for a low-level switch. For example, ‘B0-2-’ means either setting 0 or 2 is valid for switch B. The “proper” setting in such a case is the one that copies the setting of switch A—any other setting might slightly reduce the speed of the compiler, though possibly to an unmeasurable extent. All remaining combinations are useless in that they prevent successful compilation of non-null source files (source files with something other than comments).

10.6 VXT Fortran

g77 supports certain constructs that have different meanings in VXT Fortran than they do in the GNU Fortran language. Generally, this manual uses the invented term VXT Fortran to refer VAX FORTRAN (circa v4). That compiler offered many popular features, though not necessarily those that are specific to the VAX processor architecture, the VMS operating system, or Digital Equipment Corporation’s Fortran product line. (VAX and VMS probably are trademarks of Digital Equipment Corporation.) An extension offered by a Digital Fortran product that also is offered by several other Fortran products for different kinds of systems is probably going to be considered for inclusion in g77 someday, and is considered a VXT Fortran feature. The ‘-fvxt’ option generally specifies that, where the meaning of a construct is ambiguous (means one thing in GNU Fortran and another in VXT Fortran), the VXT Fortran meaning is to be assumed.

10.6.1 Meaning of Double Quote

g77 treats double-quote (‘"’) as beginning an octal constant of INTEGER(KIND=1) type when the -fvxt option is specified. The form of this octal constant is

"octal-digits

where octal-digits is a nonempty string of characters in the set ‘01234567’. For example, the -fvxt option permits this:

PRINT *, "20

The above program would print the value ‘16’. See section Integer Type, for information on the preferred construct for integer constants specified using GNU Fortran’s octal notation. (In the GNU Fortran language, the double-quote character (‘"’) delimits a character constant just as does apostrophe (‘'’). There is no way to allow both constructs in the general case, since statements like ‘PRINT *,"2000 !comment?"’ would be ambiguous.)

10.6.2 Meaning of Exclamation Point in Column 6

g77 treats an exclamation point (‘!’) in column 6 of a fixed-form source file as a continuation character rather than as the beginning of a comment (as it does in any other column) when the -fvxt option is specified. The following program, when run, prints a message indicating whether it is interpreted according to GNU Fortran (and Fortran 90) rules or VXT Fortran rules:

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

(In the GNU Fortran and Fortran 90 languages, exclamation point is a valid character and, unlike space (<SPC>) or zero (‘0’), marks a line as a continuation line when it appears in column 6.)

10.7 Fortran 90

The GNU Fortran language includes a number of features that are part of Fortran 90, even when the ‘-ff90’ option is not specified. The features enabled by ‘-ff90’ are intended to be those that, when ‘-ff90’ is not specified, would have another meaning to g77—usually meaning something invalid in the GNU Fortran language. So, the purpose of ‘-ff90’ is not to specify whether g77 is to gratuitously reject Fortran 90 constructs. The ‘-pedantic’ option specified with ‘-fno-f90’ is intended to do that, although its implementation is certainly incomplete at this point. When ‘-ff90’ is specified:

• The type of ‘REAL(expr)’ and ‘AIMAG(expr)’, where expr is COMPLEX type, is the same type as the real part of expr. For example, assuming ‘Z’ is type COMPLEX(KIND=2), ‘REAL(Z)’ would return a value of type REAL(KIND=2), not of type REAL(KIND=1), since ‘-ff90’ is specified.

10.8 Pedantic Compilation

The ‘-fpedantic’ command-line option specifies that g77 is to warn about code that is not standard-conforming. This is useful for finding some extensions g77 accepts that other compilers might not accept. (Note that the ‘-pedantic’ and ‘-pedantic-errors’ options always imply ‘-fpedantic’.) With ‘-fno-f90’ in force, ANSI FORTRAN 77 is used as the standard for conforming code. With ‘-ff90’ in force, Fortran 90 is used. The constructs for which g77 issues diagnostics when ‘-fpedantic’ and ‘-fno-f90’ are in force are:

• Automatic arrays, as in

  SUBROUTINE X(N)
  REAL A(N)
  …
  

  where ‘A’ is not listed in any ENTRY statement, and thus is not a dummy argument.

• The commas in ‘READ (5), I’ and ‘WRITE (10), J’. These commas are disallowed by FORTRAN 77, but, while strictly superfluous, are syntactically elegant, especially given that commas are required in statements such as ‘READ 99, I’ and ‘PRINT *, J’. Many compilers permit the superfluous commas for this reason.
• DOUBLE COMPLEX, either explicitly or implicitly. An explicit use of this type is via a DOUBLE COMPLEX or IMPLICIT DOUBLE COMPLEX statement, for examples. An example of an implicit use is the expression ‘C*D’, where ‘C’ is COMPLEX(KIND=1) and ‘D’ is DOUBLE PRECISION. This expression is prohibited by ANSI FORTRAN 77 because the rules of promotion would suggest that it produce a DOUBLE COMPLEX result—a type not provided for by that standard.
• Automatic conversion of numeric expressions to INTEGER(KIND=1) in contexts such as:
  • – Array-reference indexes.
  • – Alternate-return values.
  • – Computed GOTO.
  • – FORMAT run-time expressions (not yet supported).
  • – Dimension lists in specification statements.
  • – Numbers for I/O statements (such as ‘READ (UNIT=3.2), I’)
  • – Sizes of CHARACTER entities in specification statements.
  • – Kind types in specification entities (a Fortran 90 feature).
  • – Initial, terminal, and incrementation parameters for implied-DO constructs in DATA statements.
• Automatic conversion of LOGICAL expressions to INTEGER in contexts such as arithmetic IF (where COMPLEX expressions are disallowed anyway).
• Zero-size array dimensions, as in:

  INTEGER I(10,20,4:2)
  

• Zero-length CHARACTER entities, as in:

  PRINT *, ''
  

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

  PRINT *, 'hello'(3:5)
  

• Null arguments passed to statement function, as in:

  PRINT *, FOO(,3)
  

• Disagreement among program units regarding whether a given COMMON area is SAVEd (for targets where program units in a single source file are “glued” together as they typically are for UNIX development environments).
• Disagreement among program units regarding the size of a named COMMON block.
• Specification statements following first DATA statement. (In the GNU Fortran language, ‘DATA I/1/’ may be followed by ‘INTEGER J’, but not ‘INTEGER I’. The ‘-fpedantic’ option disallows both of these.)
• Semicolon as statement separator, as in:

  CALL FOO; CALL BAR
  

• Use of ‘&’ in column 1 of fixed-form source (to indicate continuation).
• Use of CHARACTER constants to initialize numeric entities, and vice versa.
• Expressions having two arithmetic operators in a row, such as ‘X*-Y’.

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

• Use of semicolon as a statement separator on a line that has an INCLUDE directive.

10.9 Distensions

The ‘-fugly-*’ command-line options determine whether certain features supported by VAX FORTRAN and other such compilers, but considered too ugly to be in code that can be changed to use safer and/or more portable constructs, are accepted. These are humorously referred to as “distensions”, extensions that just plain look ugly in the harsh light of day. Note: The ‘-fugly’ option, which currently serves as shorthand to enable all of the distensions below, is likely to be removed in a future version of g77. That’s because it’s likely new distensions will be added that conflict with existing ones in terms of assigning meaning to a given chunk of code. (Also, it’s pretty clear that users should not use ‘-fugly’ as shorthand when the next release of g77 might add a distension to that that causes their existing code, when recompiled, to behave differently—perhaps even fail to compile or run correctly.)

10.9.1 Implicit Argument Conversion

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

CALL FOO(4HABCD)
CALL BAR('123'O)

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

10.9.2 Ugly Assumed-Size Arrays

The ‘-fugly-assumed’ option enables the treatment of any array with a final dimension specified as ‘1’ as an assumed-size array, as if ‘*’ had been specified instead. For example, ‘DIMENSION X(1)’ is treated as if it had read ‘DIMENSION X(*)’ if ‘X’ is listed as a dummy argument in a preceding SUBROUTINE, FUNCTION, or ENTRY statement in the same program unit. Use an explicit lower bound to avoid this interpretation. For example, ‘DIMENSION X(1:1)’ is never treated as if it had read ‘DIMENSION X(*)’ or ‘DIMENSION X(1:*)’. Nor is ‘DIMENSION X(2-1)’ affected by this option, since that kind of expression is unlikely to have been intended to designate an assumed-size array. This option is used to prevent warnings being issued about apparent out-of-bounds reference such as ‘X(2) = 99’. It also prevents the array from being used in contexts that disallow assumed-size arrays, such as ‘PRINT *,X’. In such cases, a diagnostic is generated and the source file is not compiled. The construct affected by this option is used only in old code that pre-exists the widespread acceptance of adjustable and assumed-size arrays in the Fortran community. Note: This option does not affect how ‘DIMENSION X(1)’ is treated if ‘X’ is listed as a dummy argument only after the DIMENSION statement (presumably in an ENTRY statement). For example, ‘-fugly-assumed’ has no effect on the following program unit:

SUBROUTINE X
REAL A(1)
RETURN
ENTRY Y(A)
PRINT *, A

10.9.3 Ugly Complex Part Extraction

The ‘-fugly-complex’ option enables use of the REAL() and AIMAG() intrinsics with arguments that are COMPLEX types other than COMPLEX(KIND=1). With ‘-ff90’ in effect, these intrinsics return the unconverted real and imaginary parts (respectively) of their argument. With ‘-fno-f90’ in effect, these intrinsics convert the real and imaginary parts to REAL(KIND=1), and return the result of that conversion. Due to this ambiguity, the GNU Fortran language defines these constructs as invalid, except in the specific case where they are entirely and solely passed as an argument to an invocation of the REAL() intrinsic. For example,

REAL(REAL(Z))

is permitted even when ‘Z’ is COMPLEX(KIND=2) and ‘-fno-ugly-complex’ is in effect, because the meaning is clear. g77 enforces this restriction, unless ‘-fugly-complex’ is specified, in which case the appropriate interpretation is chosen and no diagnostic is issued. See section CMPAMBIG, for information on how to cope with existing code with unclear expectations of REAL() and AIMAG() with COMPLEX(KIND=2) arguments. @xref{RealPart Intrinsic}, for information on the REALPART() intrinsic, used to extract the real part of a complex expression without conversion. @xref{ImagPart Intrinsic}, for information on the IMAGPART() intrinsic, used to extract the imaginary part of a complex expression without conversion.

10.9.4 Ugly Null Arguments

The ‘-fugly-comma’ option enables use of a single trailing comma to mean “pass an extra trailing null argument” in a list of actual arguments to an external procedure, and use of an empty list of arguments to such a procedure to mean “pass a single null argument”. (Null arguments often are used in some procedure-calling schemes to indicate omitted arguments.) For example, ‘CALL FOO(,)’ means “pass two null arguments”, rather than “pass one null argument”. Also, ‘CALL BAR()’ means “pass one null argument”. This construct is considered “ugly” because it does not provide an elegant way to pass a single null argument that is syntactically distinct from passing no arguments. That is, this construct changes the meaning of code that makes no use of the construct. So, with ‘-fugly-comma’ in force, ‘CALL FOO()’ and ‘I = JFUNC()’ pass a single null argument, instead of passing no arguments as required by the Fortran 77 and 90 standards. Note: Many systems gracefully allow the case where a procedure call passes one extra argument that the called procedure does not expect. So, in practice, there might be no difference in the behavior of a program that does ‘CALL FOO()’ or ‘I = JFUNC()’ and is compiled with ‘-fugly-comma’ in force as compared to its behavior when compiled with the default, ‘-fno-ugly-comma’, in force, assuming ‘FOO’ and ‘JFUNC’ do not expect any arguments to be passed.

10.9.5 Ugly Conversion of Initializers

The constructs disabled by ‘-fno-ugly-init’ are:

• Use of Hollerith and typeless constants in contexts where they set initial (compile-time) values for variables, arrays, and named constants—that is, DATA and PARAMETER statements, plus type-declaration statements specifying initial values. Here are some sample initializations that are disabled by the ‘-fno-ugly-init’ option:

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

• In the same contexts as above, use of character constants to initialize numeric items and vice versa (one constant per item). Here are more sample initializations that are disabled by the ‘-fno-ugly-init’ option:

  INTEGER IA
  CHARACTER BELL
  PARAMETER (IA = 'A')
  PARAMETER (BELL = 7)
  

• Use of Hollerith and typeless constants on the right-hand side of assignment statements to numeric types, and in other contexts (such as passing arguments in invocations of intrinsic procedures and statement functions) that are treated as assignments to known types (the dummy arguments, in these cases). Here are sample statements that are disabled by the ‘-fno-ugly-init’ option:

  IVAR = 4HABCD
  PRINT *, IMAX0(2HAB, 2HBA)
  

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

10.9.6 Ugly Integer Conversions

The constructs enabled via ‘-fugly-logint’ are:

• Automatic conversion between INTEGER and LOGICAL as dictated by context (typically implies nonportable dependencies on how a particular implementation encodes .TRUE. and .FALSE.).
• Use of a LOGICAL variable in ASSIGN and assigned-GOTO statements.

The above constructs are disabled by default because use of them tends to lead to non-portable code. Even existing Fortran code that uses that often turns out to be non-portable, if not outright buggy. Some of this is due to differences among implementations as far as how .TRUE. and .FALSE. are encoded as INTEGER values—Fortran code that assumes a particular coding is likely to use one of the above constructs, and is also likely to not work correctly on implementations using different encodings. See section Equivalence Versus Equality, for more information.

10.9.7 Ugly Assigned Labels

The ‘-fugly-assign’ option forces g77 to use the same storage for assigned labels as it would for a normal assignment to the same variable. For example, consider the following code fragment:

I = 3
ASSIGN 10 TO I

Normally, for portability and improved diagnostics, g77 reserves distinct storage for a “sibling” of ‘I’, used only for ASSIGN statements to that variable (along with the corresponding assigned-GOTO and assigned-‘FORMAT’-I/O statements that reference the variable). However, some code (that violates the ANSI FORTRAN 77 standard) attempts to copy assigned labels among variables involved with ASSIGN statements, as in:

ASSIGN 10 TO I
ISTATE(5) = I
…
J = ISTATE(ICUR)
GOTO J

Such code doesn’t work under g77 unless ‘-fugly-assign’ is specified on the command-line, ensuring that the value of I referenced in the second line is whatever value g77 uses to designate statement label ‘10’, so the value may be copied into the ‘ISTATE’ array, later retrieved into a variable of the appropriate type (‘J’), and used as the target of an assigned-GOTO statement. Note: To avoid subtle program bugs, when ‘-fugly-assign’ is specified, g77 requires the type of variables specified in assigned-label contexts must be the same type returned by %LOC(). On many systems, this type is effectively the same as INTEGER(KIND=1), while, on others, it is effectively the same as INTEGER(KIND=2). Do not depend on g77 actually writing valid pointers to these variables, however. While g77 currently chooses that implementation, it might be changed in the future. See section Assigned Statement Labels (ASSIGN and GOTO), for implementation details on assigned-statement labels.

11 The GNU Fortran Compiler

The GNU Fortran compiler, g77, supports programs written in the GNU Fortran language and in some other dialects of Fortran. Some aspects of how g77 works are universal regardless of dialect, and yet are not properly part of the GNU Fortran language itself. These are described below. Note: This portion of the documentation definitely needs a lot of work!

11.1 Compiler Limits

g77, as with GNU tools in general, imposes few arbitrary restrictions on lengths of identifiers, number of continuation lines, number of external symbols in a program, and so on. For example, some other Fortran compiler have an option (such as ‘-Nlx’) to increase the limit on the number of continuation lines. Also, some Fortran compilation systems have an option (such as ‘-Nxx’) to increase the limit on the number of external symbols. g77, gcc, and GNU ld (the GNU linker) have no equivalent options, since they do not impose arbitrary limits in these areas. g77 does currently limit the number of dimensions in an array to the same degree as do the Fortran standards—seven (7). This restriction might well be lifted in a future version.

11.2 Compiler Types

Fortran implementations have a fair amount of freedom given them by the standard as far as how much storage space is used and how much precision and range is offered by the various types such as LOGICAL(KIND=1), INTEGER(KIND=1), REAL(KIND=1), REAL(KIND=2), COMPLEX(KIND=1), and CHARACTER. Further, many compilers offer so-called ‘*n’ notation, but the interpretation of n varies across compilers and target architectures. The standard requires that LOGICAL(KIND=1), INTEGER(KIND=1), and REAL(KIND=1) occupy the same amount of storage space, and that COMPLEX(KIND=1) and REAL(KIND=2) take twice as much storage space as REAL(KIND=1). Further, it requires that COMPLEX(KIND=1) entities be ordered such that when a COMPLEX(KIND=1) variable is storage-associated (such as via EQUIVALENCE) with a two-element REAL(KIND=1) array named ‘R’, ‘R(1)’ corresponds to the real element and ‘R(2)’ to the imaginary element of the COMPLEX(KIND=1) variable. (Few requirements as to precision or ranges of any of these are placed on the implementation, nor is the relationship of storage sizes of these types to the CHARACTER type specified, by the standard.) g77 follows the above requirements, warning when compiling a program requires placement of items in memory that contradict the requirements of the target architecture. (For example, a program can require placement of a REAL(KIND=2) on a boundary that is not an even multiple of its size, but still an even multiple of the size of a REAL(KIND=1) variable. On some target architectures, using the canonical mapping of Fortran types to underlying architectural types, such placement is prohibited by the machine definition or the Application Binary Interface (ABI) in force for the configuration defined for building gcc and g77. g77 warns about such situations when it encounters them.) g77 follows consistent rules for configuring the mapping between Fortran types, including the ‘*n’ notation, and the underlying architectural types as accessed by a similarly-configured applicable version of the gcc compiler. These rules offer a widely portable, consistent Fortran/C environment, although they might well conflict with the expectations of users of Fortran compilers designed and written for particular architectures. These rules are based on the configuration that is in force for the version of gcc built in the same release as g77 (and which was therefore used to build both the g77 compiler components and the libf2c run-time library):

REAL(KIND=1)

Same as float type.

REAL(KIND=2)

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

INTEGER(KIND=1)

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

LOGICAL(KIND=1)

Same gcc type as INTEGER(KIND=1).

INTEGER(KIND=2)

Twice the size, and usually nearly twice the range, as INTEGER(KIND=1)—usually, this is either a long int or a long long int.

LOGICAL(KIND=2)

Same gcc type as INTEGER(KIND=2).

INTEGER(KIND=3)

Same gcc type as signed char.

LOGICAL(KIND=3)

Same gcc type as INTEGER(KIND=3).

INTEGER(KIND=6)

Twice the size, and usually nearly twice the range, as INTEGER(KIND=3)—usually, this is a short.

LOGICAL(KIND=6)

Same gcc type as INTEGER(KIND=6).

COMPLEX(KIND=1)

Two REAL(KIND=1) scalars (one for the real part followed by one for the imaginary part).

COMPLEX(KIND=2)

Two REAL(KIND=2) scalars.

numeric-type*n

(Where numeric-type is any type other than CHARACTER.)  Same as whatever gcc type occupies n times the storage space of a gcc char item.

DOUBLE PRECISION

Same as REAL(KIND=2).

DOUBLE COMPLEX

Same as COMPLEX(KIND=2).

Note that the above are proposed correspondences and might change in future versions of g77—avoid writing code depending on them. Other types supported by g77 are derived from gcc types such as char, short, int, long int, long long int, long double, and so on. That is, whatever types gcc already supports, g77 supports now or probably will support in a future version. The rules for the ‘numeric-type*n’ notation apply to these types, and new values for ‘numeric-type(KIND=n)’ will be assigned in a way that encourages clarity, consistency, and portability.

11.3 Compiler Constants

g77 strictly assigns types to all constants not documented as “typeless” (typeless constants including ‘'1'Z’, for example). Many other Fortran compilers attempt to assign types to typed constants based on their context. This results in hard-to-find bugs, nonportable code, and is not in the spirit (though it strictly follows the letter) of the 77 and 90 standards. g77 might offer, in a future release, explicit constructs by which a wider variety of typeless constants may be specified, and/or user-requested warnings indicating places where g77 might differ from how other compilers assign types to constants. See section Context-Sensitive Constants, for more information on this issue.

11.4 Compiler Intrinsics

g77 offers an ever-widening set of intrinsics. Currently these all are procedures (functions and subroutines). Some of these intrinsics are unimplemented, but their names reserved to reduce future problems with existing code as they are implemented. Others are implemented as part of the GNU Fortran language, while yet others are provided for compatibility with other dialects of Fortran but are not part of the GNU Fortran language. To manage these distinctions, g77 provides intrinsic groups, a facility that is simply an extension of the intrinsic groups provided by the GNU Fortran language.

11.4.1 Intrinsic Groups

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

Deleted

No intrinsics are recognized as belonging to that group.

Disabled

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

Hidden

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

Enabled

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

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

PRINT *, FOO()

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

EXTERNAL FOO

So, deleting a group tells g77 to pretend as though the intrinsics in that group do not exist at all, whereas disabling it tells g77 to recognize them as (disabled) intrinsics in intrinsic-like contexts. Hiding a group is like enabling it, but the intrinsic must be first named in an INTRINSIC statement to be considered a reference to the intrinsic rather than to an external procedure. This might be the “safest” way to treat a new group of intrinsics when compiling old code, because it allows the old code to be generally written as if those new intrinsics never existed, but to be changed to use them by inserting INTRINSIC statements in the appropriate places. However, it should be the goal of development to use EXTERNAL for all names of external procedures that might be intrinsic names. If an intrinsic is in more than one group, it is enabled if any of its containing groups are enabled; if not so enabled, it is hidden if any of its containing groups are hidden; if not so hidden, it is disabled if any of its containing groups are disabled; if not so disabled, it is deleted. This extra complication is necessary because some intrinsics, such as IBITS, belong to more than one group, and hence should be enabled if any of the groups to which they belong are enabled, and so The groups are:

badu77

UNIX intrinsics having inappropriate forms (usually functions that have intended side effects).

gnu

Intrinsics the GNU Fortran language supports that are extensions to the Fortran standards (77 and 90).

f2c

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

f90

Fortran 90 intrinsics.

mil

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

unix

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

vxt

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

11.4.2 Other Intrinsics

g77 supports intrinsics other than those in the GNU Fortran language proper. This set of intrinsics is described below.

12 Other Compilers

An individual Fortran source file can be compiled to an object (‘*.o’) file instead of to the final program executable. This allows several portions of a program to be compiled at different times and linked together whenever a new version of the program is needed. However, it introduces the issue of object compatibility across the various object files (and libraries, or ‘*.a’ files) that are linked together to produce any particular executable file. Object compatibility is an issue when combining, in one program, Fortran code compiled by more than one compiler (or more than one configuration of a compiler). If the compilers disagree on how to transform the names of procedures, there will normally be errors when linking such programs. Worse, if the compilers agree on naming, but disagree on issues like how to pass parameters, return arguments, and lay out COMMON areas, the earliest detected errors might be the incorrect results produced by the program (and that assumes these errors are detected, which is not always the case). Normally, g77 generates code that is object-compatible with code generated by a version of f2c configured (with, for example, ‘f2c.h’ definitions) to be generally compatible with g77 as built by gcc. (Normally, f2c will, by default, conform to the appropriate configuration, but it is possible that older or perhaps even newer versions of f2c, or versions having certain configuration changes to f2c internals, will produce object files that are incompatible with g77.) For example, a Fortran string subroutine argument will become two arguments on the C side: a char * and an int length. Much of this compatibility results from the fact that g77 uses the same run-time library, libf2c, used by f2c. Other compilers might or might not generate code that is object-compatible with libf2c and current g77, and some might offer such compatibility only when explicitly selected via a command-line option to the compiler. Note: This portion of the documentation definitely needs a lot of work!

12.1 Dropping f2c Compatibility

Specifying ‘-fno-f2c’ allows g77 to generate, in some cases, faster code, by not needing to allow to the possibility of linking with code compiled by f2c. For example, this affects how REAL(KIND=1), COMPLEX(KIND=1), and COMPLEX(KIND=2) functions are called. With ‘-fno-f2c’, they are compiled as returning the appropriate gcc type (float, __complex__ float, __complex__ double, in many configurations). With ‘-ff2c’ in force, they are compiled differently (with perhaps slower run-time performance) to accommodate the restrictions inherent in f2c’s use of K&R C as an intermediate language—REAL(KIND=1) functions return C’s double type, while COMPLEX functions return void and use an extra argument pointing to a place for the functions to return their values. It is possible that, in some cases, leaving ‘-ff2c’ in force might produce faster code than using ‘-fno-f2c’. Feel free to experiment, but remember to experiment with changing the way entire programs and their Fortran libraries are compiled at a time, since this sort of experimentation affects the interface of code generated for a Fortran source file—that is, it affects object compatibility. Note that f2c compatibility is a fairly static target to achieve, though not necessarily perfectly so, since, like g77, it is still being improved. However, specifying ‘-fno-f2c’ causes g77 to generate code that will probably be incompatible with code generated by future versions of g77 when the same option is in force. You should make sure you are always able to recompile complete programs from source code when upgrading to new versions of g77 or f2c, especially when using options such as ‘-fno-f2c’. Therefore, if you are using g77 to compile libraries and other object files for possible future use and you don’t want to require recompilation for future use with subsequent versions of g77, you might want to stick with f2c compatibility for now, and carefully watch for any announcements about changes to the f2c/libf2c interface that might affect existing programs (thus requiring recompilation). It is probable that a future version of g77 will not, by default, generate object files compatible with f2c, and that version probably would no longer use libf2c. If you expect to depend on this compatibility in the long term, use the options ‘-ff2c -ff2c-library’ when compiling all of the applicable code. This should cause future versions of g77 either to produce compatible code (at the expense of the availability of some features and performance), or at the very least, to produce diagnostics.