\input texinfo @c -*-texinfo-*- @c %**start of header @setfilename g77.info @set last-update 2002-04-29 @set copyrights-g77 1995,1996,1997,1998,1999,2000,2001,2002 @include root.texi @c This tells @include'd files that they're part of the overall G77 doc @c set. (They might be part of a higher-level doc set too.) @set DOC-G77 @c @setfilename useg77.info @c @setfilename portg77.info @c To produce the full manual, use the "g77.info" setfilename, and @c make sure the following do NOT begin with '@c' (and the @clear lines DO) @set INTERNALS @set USING @c To produce a user-only manual, use the "useg77.info" setfilename, and @c make sure the following does NOT begin with '@c': @c @clear INTERNALS @c To produce a porter-only manual, use the "portg77.info" setfilename, @c and make sure the following does NOT begin with '@c': @c @clear USING @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi) @c @smallbook @c i also commented out the finalout command, so if there *are* any @c overfulls, you'll (hopefully) see the rectangle in the right hand @c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi). @c @finalout @macro gcctabopt{body} @code{\body\} @end macro @macro gccoptlist{body} @smallexample \body\ @end smallexample @end macro @c Makeinfo handles the above macro OK, TeX needs manual line breaks; @c they get lost at some point in handling the macro. But if @macro is @c used here rather than @alias, it produces double line breaks. @iftex @alias gol = * @end iftex @ifnottex @macro gol @end macro @end ifnottex @ifset INTERNALS @ifset USING @settitle Using and Porting GNU Fortran @end ifset @end ifset @c seems reasonable to assume at least one of INTERNALS or USING is set... @ifclear INTERNALS @settitle Using GNU Fortran @end ifclear @ifclear USING @settitle Porting GNU Fortran @end ifclear @c then again, have some fun @ifclear INTERNALS @ifclear USING @settitle Doing Squat with GNU Fortran @end ifclear @end ifclear @syncodeindex fn cp @syncodeindex vr cp @c %**end of header @c Cause even numbered pages to be printed on the left hand side of @c the page and odd numbered pages to be printed on the right hand @c side of the page. Using this, you can print on both sides of a @c sheet of paper and have the text on the same part of the sheet. @c The text on right hand pages is pushed towards the right hand @c margin and the text on left hand pages is pushed toward the left @c hand margin. @c (To provide the reverse effect, set bindingoffset to -0.75in.) @c @tex @c \global\bindingoffset=0.75in @c \global\normaloffset =0.75in @c @end tex @ifinfo @dircategory Programming @direntry * g77: (g77). The GNU Fortran compiler. @end direntry @ifset INTERNALS @ifset USING This file documents the use and the internals of the GNU Fortran (@command{g77}) compiler. It corresponds to the @value{which-g77} version of @command{g77}. @end ifset @end ifset @ifclear USING This file documents the internals of the GNU Fortran (@command{g77}) compiler. It corresponds to the @value{which-g77} version of @command{g77}. @end ifclear @ifclear INTERNALS This file documents the use of the GNU Fortran (@command{g77}) compiler. It corresponds to the @value{which-g77} version of @command{g77}. @end ifclear Published by the Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307 USA Copyright (C) @value{copyrights-g77} Free Software Foundation, Inc. Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. @end ifinfo Contributed by James Craig Burley (@email{@value{email-burley}}). Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}). @setchapternewpage odd @c @finalout @titlepage @ifset INTERNALS @ifset USING @center @titlefont{Using and Porting GNU Fortran} @end ifset @end ifset @ifclear INTERNALS @title Using GNU Fortran @end ifclear @ifclear USING @title Porting GNU Fortran @end ifclear @sp 2 @center James Craig Burley @sp 3 @center Last updated @value{last-update} @sp 1 @center for version @value{which-g77} @page @vskip 0pt plus 1filll Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc. @sp 2 For the @value{which-g77} Version* @sp 1 Published by the Free Software Foundation @* 59 Temple Place - Suite 330@* Boston, MA 02111-1307, USA@* @c Last printed ??ber, 19??.@* @c Printed copies are available for $? each.@* @c ISBN ??? @sp 1 Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation; with the Invariant Sections being ``GNU General Public License'' and ``Funding Free Software'', the Front-Cover texts being (a) (see below), and with the Back-Cover Texts being (b) (see below). A copy of the license is included in the section entitled ``GNU Free Documentation License''. (a) The FSF's Front-Cover Text is: A GNU Manual (b) The FSF's Back-Cover Text is: You have freedom to copy and modify this GNU Manual, like GNU software. Copies published by the Free Software Foundation raise funds for GNU development. @end titlepage @summarycontents @contents @page @node Top, Copying,, (DIR) @top Introduction @cindex Introduction @ifset INTERNALS @ifset USING This manual documents how to run, install and port @command{g77}, as well as its new features and incompatibilities, and how to report bugs. It corresponds to the @value{which-g77} version of @command{g77}. @end ifset @end ifset @ifclear INTERNALS This manual documents how to run and install @command{g77}, as well as its new features and incompatibilities, and how to report bugs. It corresponds to the @value{which-g77} version of @command{g77}. @end ifclear @ifclear USING This manual documents how to port @command{g77}, as well as its new features and incompatibilities, and how to report bugs. It corresponds to the @value{which-g77} version of @command{g77}. @end ifclear @ifset DEVELOPMENT @emph{Warning:} This document is still under development, and might not accurately reflect the @command{g77} code base of which it is a part. Efforts are made to keep it somewhat up-to-date, but they are particularly concentrated on any version of this information that is distributed as part of a @emph{released} @command{g77}. In particular, while this document is intended to apply to the @value{which-g77} version of @command{g77}, only an official @emph{release} of that version is expected to contain documentation that is most consistent with the @command{g77} product in that version. @end ifset @menu * Copying:: GNU General Public License says how you can copy and share GNU Fortran. * GNU Free Documentation License:: How you can copy and share this manual. * Contributors:: People who have contributed to GNU Fortran. * Funding:: How to help assure continued work for free software. * Funding GNU Fortran:: How to help assure continued work on GNU Fortran. @ifset USING * Getting Started:: Finding your way around this manual. * What is GNU Fortran?:: How @command{g77} fits into the universe. * G77 and GCC:: You can compile Fortran, C, or other programs. * Invoking G77:: Command options supported by @command{g77}. * News:: News about recent releases of @command{g77}. * Changes:: User-visible changes to recent releases of @command{g77}. * Language:: The GNU Fortran language. * Compiler:: The GNU Fortran compiler. * Other Dialects:: Dialects of Fortran supported by @command{g77}. * Other Compilers:: Fortran compilers other than @command{g77}. * Other Languages:: Languages other than Fortran. * Debugging and Interfacing:: How @command{g77} generates code. * Collected Fortran Wisdom:: How to avoid Trouble. * Trouble:: If you have trouble with GNU Fortran. * Open Questions:: Things we'd like to know. * Bugs:: How, why, and where to report bugs. * Service:: How to find suppliers of support for GNU Fortran. @end ifset @ifset INTERNALS * Adding Options:: Guidance on teaching @command{g77} about new options. * Projects:: Projects for @command{g77} internals hackers. * Front End:: Design and implementation of the @command{g77} front end. @end ifset * M: Diagnostics. Diagnostics produced by @command{g77}. * Index:: Index of concepts and symbol names. @end menu @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)! @include gpl.texi @include fdl.texi @node Contributors @unnumbered Contributors to GNU Fortran @cindex contributors @cindex credits In addition to James Craig Burley, who wrote the front end, many people have helped create and improve GNU Fortran. @itemize @bullet @item The packaging and compiler portions of GNU Fortran are based largely on the GNU CC compiler. @xref{Contributors,,Contributors to GCC,gcc,Using the GNU Compiler Collection (GCC)}, for more information. @item The run-time library used by GNU Fortran is a repackaged version of the @code{libf2c} library (combined from the @code{libF77} and @code{libI77} libraries) provided as part of @command{f2c}, available for free from @code{netlib} sites on the Internet. @item Cygnus Support and The Free Software Foundation contributed significant money and/or equipment to Craig's efforts. @item The following individuals served as alpha testers prior to @command{g77}'s public release. This work consisted of testing, researching, sometimes debugging, and occasionally providing small amounts of code and fixes for @command{g77}, plus offering plenty of helpful advice to Craig: @itemize @w{} @item Jonathan Corbet @item Dr.@: Mark Fernyhough @item Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp} @item Kate Hedstrom @item Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr} @item Dr.@: A. O. V. Le Blanc @item Dave Love @item Rick Lutowski @item Toon Moene @item Rick Niles @item Derk Reefman @item Wayne K. Schroll @item Bill Thorson @item Pedro A. M. Vazquez @item Ian Watson @end itemize @item Dave Love (@email{d.love@@dl.ac.uk}) wrote the libU77 part of the run-time library. @item Scott Snyder (@email{snyder@@d0sgif.fnal.gov}) provided the patch to add rudimentary support for @code{INTEGER*1}, @code{INTEGER*2}, and @code{LOGICAL*1}. This inspired Craig to add further support, even though the resulting support would still be incomplete. @item David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired and encouraged Craig to rewrite the documentation in texinfo format by contributing a first pass at a translation of the old @file{g77-0.5.16/f/DOC} file. @item Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed some analysis of generated code as part of an overall project to improve @command{g77} code generation to at least be as good as @command{f2c} used in conjunction with @command{gcc}. So far, this has resulted in the three, somewhat experimental, options added by @command{g77} to the @command{gcc} compiler and its back end. (These, in turn, had made their way into the @code{egcs} version of the compiler, and do not exist in @command{gcc} version 2.8 or versions of @command{g77} based on that version of @command{gcc}.) @item John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements. @item Thanks to Mary Cortani and the staff at Craftwork Solutions (@email{support@@craftwork.com}) for all of their support. @item Many other individuals have helped debug, test, and improve @command{g77} over the past several years, and undoubtedly more people will be doing so in the future. If you have done so, and would like to see your name listed in the above list, please ask! The default is that people wish to remain anonymous. @end itemize @include funding.texi @node Funding GNU Fortran @chapter Funding GNU Fortran @cindex funding improvements @cindex improvements, funding James Craig Burley (@email{@value{email-burley}}), the original author of @command{g77}, stopped working on it in September 1999 (He has a web page at @uref{@value{www-burley}}.) GNU Fortran is currently maintained by Toon Moene (@email{toon@@moene.indiv.nluug.nl}), with the help of countless other volunteers. As with other GNU software, funding is important because it can pay for needed equipment, personnel, and so on. @cindex FSF, funding the @cindex funding the FSF The FSF provides information on the best way to fund ongoing development of GNU software (such as GNU Fortran) in documents such as the ``GNUS Bulletin''. Email @email{gnu@@gnu.org} for information on funding the FSF. Another important way to support work on GNU Fortran is to volunteer to help out. Email @email{@value{email-general}} to volunteer for this work. However, we strongly expect that there will never be a version 0.6 of @command{g77}. Work on this compiler has stopped as of the release of GCC 3.1, except for bug fixing. @command{g77} will be succeeded by @command{g95} - see @uref{http://g95.sourceforge.net}. @xref{Funding,,Funding Free Software}, for more information. @node Getting Started @chapter Getting Started @cindex getting started @cindex new users @cindex newbies @cindex beginners If you don't need help getting started reading the portions of this manual that are most important to you, you should skip this portion of the manual. If you are new to compilers, especially Fortran compilers, or new to how compilers are structured under UNIX and UNIX-like systems, you'll want to see @ref{What is GNU Fortran?}. If you are new to GNU compilers, or have used only one GNU compiler in the past and not had to delve into how it lets you manage various versions and configurations of @command{gcc}, you should see @ref{G77 and GCC}. Everyone except experienced @command{g77} users should see @ref{Invoking G77}. If you're acquainted with previous versions of @command{g77}, you should see @ref{News,,News About GNU Fortran}. Further, if you've actually used previous versions of @command{g77}, especially if you've written or modified Fortran code to be compiled by previous versions of @command{g77}, you should see @ref{Changes}. If you intend to write or otherwise compile code that is not already strictly conforming ANSI FORTRAN 77---and this is probably everyone---you should see @ref{Language}. If you run into trouble getting Fortran code to compile, link, run, or work properly, you might find answers if you see @ref{Debugging and Interfacing}, see @ref{Collected Fortran Wisdom}, and see @ref{Trouble}. You might also find that the problems you are encountering are bugs in @command{g77}---see @ref{Bugs}, for information on reporting them, after reading the other material. If you need further help with @command{g77}, or with freely redistributable software in general, see @ref{Service}. If you would like to help the @command{g77} project, see @ref{Funding GNU Fortran}, for information on helping financially, and see @ref{Projects}, for information on helping in other ways. If you're generally curious about the future of @command{g77}, see @ref{Projects}. If you're curious about its past, see @ref{Contributors}, and see @ref{Funding GNU Fortran}. To see a few of the questions maintainers of @command{g77} have, and that you might be able to answer, see @ref{Open Questions}. @ifset USING @node What is GNU Fortran? @chapter What is GNU Fortran? @cindex concepts, basic @cindex basic concepts GNU Fortran, or @command{g77}, is designed initially as a free replacement for, or alternative to, the UNIX @command{f77} command. (Similarly, @command{gcc} is designed as a replacement for the UNIX @command{cc} command.) @command{g77} also is designed to fit in well with the other fine GNU compilers and tools. Sometimes these design goals conflict---in such cases, resolution often is made in favor of fitting in well with Project GNU. These cases are usually identified in the appropriate sections of this manual. @cindex compilers As compilers, @command{g77}, @command{gcc}, and @command{f77} share the following characteristics: @itemize @bullet @cindex source code @cindex file, source @cindex code, source @cindex source file @item They read a user's program, stored in a file and containing instructions written in the appropriate language (Fortran, C, and so on). This file contains @dfn{source code}. @cindex translation of user programs @cindex machine code @cindex code, machine @cindex mistakes @item They translate the user's program into instructions a computer can carry out more quickly than it takes to translate the instructions in the first place. These instructions are called @dfn{machine code}---code designed to be efficiently translated and processed by a machine such as a computer. Humans usually aren't as good writing machine code as they are at writing Fortran or C, because it is easy to make tiny mistakes writing machine code. When writing Fortran or C, it is easy to make big mistakes. @cindex debugger @cindex bugs, finding @cindex @command{gdb}, command @cindex commands, @command{gdb} @item They provide information in the generated machine code that can make it easier to find bugs in the program (using a debugging tool, called a @dfn{debugger}, such as @command{gdb}). @cindex libraries @cindex linking @cindex @command{ld} command @cindex commands, @command{ld} @item They locate and gather machine code already generated to perform actions requested by statements in the user's program. This machine code is organized into @dfn{libraries} and is located and gathered during the @dfn{link} phase of the compilation process. (Linking often is thought of as a separate step, because it can be directly invoked via the @command{ld} command. However, the @command{g77} and @command{gcc} commands, as with most compiler commands, automatically perform the linking step by calling on @command{ld} directly, unless asked to not do so by the user.) @cindex language, incorrect use of @cindex incorrect use of language @item They attempt to diagnose cases where the user's program contains incorrect usages of the language. The @dfn{diagnostics} produced by the compiler indicate the problem and the location in the user's source file where the problem was first noticed. The user can use this information to locate and fix the problem. @cindex diagnostics, incorrect @cindex incorrect diagnostics @cindex error messages, incorrect @cindex incorrect error messages (Sometimes an incorrect usage of the language leads to a situation where the compiler can no longer make any sense of what follows---while a human might be able to---and thus ends up complaining about many ``problems'' it encounters that, in fact, stem from just one problem, usually the first one reported.) @cindex warnings @cindex questionable instructions @item They attempt to diagnose cases where the user's program contains a correct usage of the language, but instructs the computer to do something questionable. These diagnostics often are in the form of @dfn{warnings}, instead of the @dfn{errors} that indicate incorrect usage of the language. @end itemize How these actions are performed is generally under the control of the user. Using command-line options, the user can specify how persnickety the compiler is to be regarding the program (whether to diagnose questionable usage of the language), how much time to spend making the generated machine code run faster, and so on. @cindex components of @command{g77} @cindex @command{g77}, components of @command{g77} consists of several components: @cindex @command{gcc}, command @cindex commands, @command{gcc} @itemize @bullet @item A modified version of the @command{gcc} command, which also might be installed as the system's @command{cc} command. (In many cases, @command{cc} refers to the system's ``native'' C compiler, which might be a non-GNU compiler, or an older version of @command{gcc} considered more stable or that is used to build the operating system kernel.) @cindex @command{g77}, command @cindex commands, @command{g77} @item The @command{g77} command itself, which also might be installed as the system's @command{f77} command. @cindex libg2c library @cindex libf2c library @cindex libraries, libf2c @cindex libraries, libg2c @cindex run-time, library @item The @code{libg2c} run-time library. This library contains the machine code needed to support capabilities of the Fortran language that are not directly provided by the machine code generated by the @command{g77} compilation phase. @code{libg2c} is just the unique name @command{g77} gives to its version of @code{libf2c} to distinguish it from any copy of @code{libf2c} installed from @command{f2c} (or versions of @command{g77} that built @code{libf2c} under that same name) on the system. The maintainer of @code{libf2c} currently is @email{dmg@@bell-labs.com}. @cindex @code{f771}, program @cindex programs, @code{f771} @cindex assembler @cindex @command{as} command @cindex commands, @command{as} @cindex assembly code @cindex code, assembly @item The compiler itself, internally named @code{f771}. Note that @code{f771} does not generate machine code directly---it generates @dfn{assembly code} that is a more readable form of machine code, leaving the conversion to actual machine code to an @dfn{assembler}, usually named @command{as}. @end itemize @command{gcc} is often thought of as ``the C compiler'' only, but it does more than that. Based on command-line options and the names given for files on the command line, @command{gcc} determines which actions to perform, including preprocessing, compiling (in a variety of possible languages), assembling, and linking. @cindex driver, gcc command as @cindex @command{gcc}, command as driver @cindex executable file @cindex files, executable @cindex cc1 program @cindex programs, cc1 @cindex preprocessor @cindex cpp program @cindex programs, cpp For example, the command @samp{gcc foo.c} @dfn{drives} the file @file{foo.c} through the preprocessor @command{cpp}, then the C compiler (internally named @code{cc1}), then the assembler (usually @command{as}), then the linker (@command{ld}), producing an executable program named @file{a.out} (on UNIX systems). @cindex cc1plus program @cindex programs, cc1plus As another example, the command @samp{gcc foo.cc} would do much the same as @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1}, @command{gcc} would use the C++ compiler (named @code{cc1plus}). @cindex @code{f771}, program @cindex programs, @code{f771} In a GNU Fortran installation, @command{gcc} recognizes Fortran source files by name just like it does C and C++ source files. It knows to use the Fortran compiler named @code{f771}, instead of @code{cc1} or @code{cc1plus}, to compile Fortran files. @cindex @command{gcc}, not recognizing Fortran source @cindex unrecognized file format @cindex file format not recognized Non-Fortran-related operation of @command{gcc} is generally unaffected by installing the GNU Fortran version of @command{gcc}. However, without the installed version of @command{gcc} being the GNU Fortran version, @command{gcc} will not be able to compile and link Fortran programs---and since @command{g77} uses @command{gcc} to do most of the actual work, neither will @command{g77}! @cindex @command{g77}, command @cindex commands, @command{g77} The @command{g77} command is essentially just a front-end for the @command{gcc} command. Fortran users will normally use @command{g77} instead of @command{gcc}, because @command{g77} knows how to specify the libraries needed to link with Fortran programs (@code{libg2c} and @code{lm}). @command{g77} can still compile and link programs and source files written in other languages, just like @command{gcc}. @cindex printing version information @cindex version information, printing The command @samp{g77 -v} is a quick way to display lots of version information for the various programs used to compile a typical preprocessed Fortran source file---this produces much more output than @samp{gcc -v} currently does. (If it produces an error message near the end of the output---diagnostics from the linker, usually @command{ld}---you might have an out-of-date @code{libf2c} that improperly handles complex arithmetic.) In the output of this command, the line beginning @samp{GNU Fortran Front End} identifies the version number of GNU Fortran; immediately preceding that line is a line identifying the version of @command{gcc} with which that version of @command{g77} was built. @cindex libf2c library @cindex libraries, libf2c The @code{libf2c} library is distributed with GNU Fortran for the convenience of its users, but is not part of GNU Fortran. It contains the procedures needed by Fortran programs while they are running. @cindex in-line code @cindex code, in-line For example, while code generated by @command{g77} is likely to do additions, subtractions, and multiplications @dfn{in line}---in the actual compiled code---it is not likely to do trigonometric functions this way. Instead, operations like trigonometric functions are compiled by the @code{f771} compiler (invoked by @command{g77} when compiling Fortran code) into machine code that, when run, calls on functions in @code{libg2c}, so @code{libg2c} must be linked with almost every useful program having any component compiled by GNU Fortran. (As mentioned above, the @command{g77} command takes care of all this for you.) The @code{f771} program represents most of what is unique to GNU Fortran. While much of the @code{libg2c} component comes from the @code{libf2c} component of @command{f2c}, a free Fortran-to-C converter distributed by Bellcore (AT&T), plus @code{libU77}, provided by Dave Love, and the @command{g77} command is just a small front-end to @command{gcc}, @code{f771} is a combination of two rather large chunks of code. @cindex GNU Back End (GBE) @cindex GBE @cindex @command{gcc}, back end @cindex back end, gcc @cindex code generator One chunk is the so-called @dfn{GNU Back End}, or GBE, which knows how to generate fast code for a wide variety of processors. The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1}, @code{cc1plus}, and @code{f771}, plus others. Often the GBE is referred to as the ``gcc back end'' or even just ``gcc''---in this manual, the term GBE is used whenever the distinction is important. @cindex GNU Fortran Front End (FFE) @cindex FFE @cindex @command{g77}, front end @cindex front end, @command{g77} The other chunk of @code{f771} is the majority of what is unique about GNU Fortran---the code that knows how to interpret Fortran programs to determine what they are intending to do, and then communicate that knowledge to the GBE for actual compilation of those programs. This chunk is called the @dfn{Fortran Front End} (FFE). The @code{cc1} and @code{cc1plus} programs have their own front ends, for the C and C++ languages, respectively. These fronts ends are responsible for diagnosing incorrect usage of their respective languages by the programs the process, and are responsible for most of the warnings about questionable constructs as well. (The GBE handles producing some warnings, like those concerning possible references to undefined variables.) Because so much is shared among the compilers for various languages, much of the behavior and many of the user-selectable options for these compilers are similar. For example, diagnostics (error messages and warnings) are similar in appearance; command-line options like @option{-Wall} have generally similar effects; and the quality of generated code (in terms of speed and size) is roughly similar (since that work is done by the shared GBE). @node G77 and GCC @chapter Compile Fortran, C, or Other Programs @cindex compiling programs @cindex programs, compiling @cindex @command{gcc}, command @cindex commands, @command{gcc} A GNU Fortran installation includes a modified version of the @command{gcc} command. In a non-Fortran installation, @command{gcc} recognizes C, C++, and Objective-C source files. In a GNU Fortran installation, @command{gcc} also recognizes Fortran source files and accepts Fortran-specific command-line options, plus some command-line options that are designed to cater to Fortran users but apply to other languages as well. @xref{G++ and GCC,,Compile C; C++; Objective-C; Ada; Fortran; or Java,gcc,Using the GNU Compiler Collection (GCC)}, for information on the way different languages are handled by the GNU CC compiler (@command{gcc}). @cindex @command{g77}, command @cindex commands, @command{g77} Also provided as part of GNU Fortran is the @command{g77} command. The @command{g77} command is designed to make compiling and linking Fortran programs somewhat easier than when using the @command{gcc} command for these tasks. It does this by analyzing the command line somewhat and changing it appropriately before submitting it to the @command{gcc} command. @cindex -v option @cindex @command{g77} options, -v @cindex options, -v Use the @option{-v} option with @command{g77} to see what is going on---the first line of output is the invocation of the @command{gcc} command. @include invoke.texi @include news.texi @set USERVISONLY @include news.texi @clear USERVISONLY @node Language @chapter The GNU Fortran Language @cindex standard, ANSI FORTRAN 77 @cindex ANSI FORTRAN 77 standard @cindex reference works GNU Fortran supports a variety of extensions to, and dialects of, the Fortran language. Its primary base is the ANSI FORTRAN 77 standard, currently available on the network at @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html} or as monolithic text at @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}. It offers some extensions that are popular among users of UNIX @command{f77} and @command{f2c} compilers, some that are popular among users of other compilers (such as Digital products), some that are popular among users of the newer Fortran 90 standard, and some that are introduced by GNU Fortran. @cindex textbooks (If you need a text on Fortran, a few freely available electronic references have pointers from @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative net project', @cite{User Notes on Fortran Programming} at @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this material might not apply specifically to @command{g77}.) Part of what defines a particular implementation of a Fortran system, such as @command{g77}, is the particular characteristics of how it supports types, constants, and so on. Much of this is left up to the implementation by the various Fortran standards and accepted practice in the industry. The GNU Fortran @emph{language} is described below. Much of the material is organized along the same lines as the ANSI FORTRAN 77 standard itself. @xref{Other Dialects}, for information on features @command{g77} supports that are not part of the GNU Fortran language. @emph{Note}: This portion of the documentation definitely needs a lot of work! @menu Relationship to the ANSI FORTRAN 77 standard: * Direction of Language Development:: Where GNU Fortran is headed. * Standard Support:: Degree of support for the standard. Extensions to the ANSI FORTRAN 77 standard: * Conformance:: * Notation Used:: * Terms and Concepts:: * Characters Lines Sequence:: * Data Types and Constants:: * Expressions:: * Specification Statements:: * Control Statements:: * Functions and Subroutines:: * Scope and Classes of Names:: * I/O:: * Fortran 90 Features:: @end menu @node Direction of Language Development @section Direction of Language Development @cindex direction of language development @cindex features, language @cindex language, features The purpose of the following description of the GNU Fortran language is to promote wide portability of GNU Fortran programs. GNU Fortran is an evolving language, due to the fact that @command{g77} itself is in beta test. Some current features of the language might later be redefined as dialects of Fortran supported by @command{g77} when better ways to express these features are added to @command{g77}, for example. Such features would still be supported by @command{g77}, but would be available only when one or more command-line options were used. The GNU Fortran @emph{language} is distinct from the GNU Fortran @emph{compilation system} (@command{g77}). For example, @command{g77} supports various dialects of Fortran---in a sense, these are languages other than GNU Fortran---though its primary purpose is to support the GNU Fortran language, which also is described in its documentation and by its implementation. On the other hand, non-GNU compilers might offer support for the GNU Fortran language, and are encouraged to do so. Currently, the GNU Fortran language is a fairly fuzzy object. It represents something of a cross between what @command{g77} accepts when compiling using the prevailing defaults and what this document describes as being part of the language. Future versions of @command{g77} are expected to clarify the definition of the language in the documentation. Often, this will mean adding new features to the language, in the form of both new documentation and new support in @command{g77}. However, it might occasionally mean removing a feature from the language itself to ``dialect'' status. In such a case, the documentation would be adjusted to reflect the change, and @command{g77} itself would likely be changed to require one or more command-line options to continue supporting the feature. The development of the GNU Fortran language is intended to strike a balance between: @itemize @bullet @item Serving as a mostly-upwards-compatible language from the de facto UNIX Fortran dialect as supported by @command{f77}. @item Offering new, well-designed language features. Attributes of such features include not making existing code any harder to read (for those who might be unaware that the new features are not in use) and not making state-of-the-art compilers take longer to issue diagnostics, among others. @item Supporting existing, well-written code without gratuitously rejecting non-standard constructs, regardless of the origin of the code (its dialect). @item Offering default behavior and command-line options to reduce and, where reasonable, eliminate the need for programmers to make any modifications to code that already works in existing production environments. @item Diagnosing constructs that have different meanings in different systems, languages, and dialects, while offering clear, less ambiguous ways to express each of the different meanings so programmers can change their code appropriately. @end itemize One of the biggest practical challenges for the developers of the GNU Fortran language is meeting the sometimes contradictory demands of the above items. For example, a feature might be widely used in one popular environment, but the exact same code that utilizes that feature might not work as expected---perhaps it might mean something entirely different---in another popular environment. Traditionally, Fortran compilers---even portable ones---have solved this problem by simply offering the appropriate feature to users of the respective systems. This approach treats users of various Fortran systems and dialects as remote ``islands'', or camps, of programmers, and assume that these camps rarely come into contact with each other (or, especially, with each other's code). Project GNU takes a radically different approach to software and language design, in that it assumes that users of GNU software do not necessarily care what kind of underlying system they are using, regardless of whether they are using software (at the user-interface level) or writing it (for example, writing Fortran or C code). As such, GNU users rarely need consider just what kind of underlying hardware (or, in many cases, operating system) they are using at any particular time. They can use and write software designed for a general-purpose, widely portable, heterogenous environment---the GNU environment. In line with this philosophy, GNU Fortran must evolve into a product that is widely ported and portable not only in the sense that it can be successfully built, installed, and run by users, but in the larger sense that its users can use it in the same way, and expect largely the same behaviors from it, regardless of the kind of system they are using at any particular time. This approach constrains the solutions @command{g77} can use to resolve conflicts between various camps of Fortran users. If these two camps disagree about what a particular construct should mean, @command{g77} cannot simply be changed to treat that particular construct as having one meaning without comment (such as a warning), lest the users expecting it to have the other meaning are unpleasantly surprised that their code misbehaves when executed. The use of the ASCII backslash character in character constants is an excellent (and still somewhat unresolved) example of this kind of controversy. @xref{Backslash in Constants}. Other examples are likely to arise in the future, as @command{g77} developers strive to improve its ability to accept an ever-wider variety of existing Fortran code without requiring significant modifications to said code. Development of GNU Fortran is further constrained by the desire to avoid requiring programmers to change their code. This is important because it allows programmers, administrators, and others to more faithfully evaluate and validate @command{g77} (as an overall product and as new versions are distributed) without having to support multiple versions of their programs so that they continue to work the same way on their existing systems (non-GNU perhaps, but possibly also earlier versions of @command{g77}). @node Standard Support @section ANSI FORTRAN 77 Standard Support @cindex ANSI FORTRAN 77 support @cindex standard, support for @cindex support, FORTRAN 77 @cindex compatibility, FORTRAN 77 @cindex FORTRAN 77 compatibility GNU Fortran supports ANSI FORTRAN 77 with the following caveats. In summary, the only ANSI FORTRAN 77 features @command{g77} doesn't support are those that are probably rarely used in actual code, some of which are explicitly disallowed by the Fortran 90 standard. @menu * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction. * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction. * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}. * No Useless Implied-DO:: No @samp{(A, I=1, 1)}. @end menu @node No Passing External Assumed-length @subsection No Passing External Assumed-length @command{g77} disallows passing of an external procedure as an actual argument if the procedure's type is declared @code{CHARACTER*(*)}. For example: @example CHARACTER*(*) CFUNC EXTERNAL CFUNC CALL FOO(CFUNC) END @end example @noindent It isn't clear whether the standard considers this conforming. @node No Passing Dummy Assumed-length @subsection No Passing Dummy Assumed-length @command{g77} disallows passing of a dummy procedure as an actual argument if the procedure's type is declared @code{CHARACTER*(*)}. @example SUBROUTINE BAR(CFUNC) CHARACTER*(*) CFUNC EXTERNAL CFUNC CALL FOO(CFUNC) END @end example @noindent It isn't clear whether the standard considers this conforming. @node No Pathological Implied-DO @subsection No Pathological Implied-DO The @code{DO} variable for an implied-@code{DO} construct in a @code{DATA} statement may not be used as the @code{DO} variable for an outer implied-@code{DO} construct. For example, this fragment is disallowed by @command{g77}: @smallexample DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/ @end smallexample @noindent This also is disallowed by Fortran 90, as it offers no additional capabilities and would have a variety of possible meanings. Note that it is @emph{very} unlikely that any production Fortran code tries to use this unsupported construct. @node No Useless Implied-DO @subsection No Useless Implied-DO An array element initializer in an implied-@code{DO} construct in a @code{DATA} statement must contain at least one reference to the @code{DO} variables of each outer implied-@code{DO} construct. For example, this fragment is disallowed by @command{g77}: @smallexample DATA (A, I= 1, 1) /1./ @end smallexample @noindent This also is disallowed by Fortran 90, as FORTRAN 77's more permissive requirements offer no additional capabilities. However, @command{g77} doesn't necessarily diagnose all cases where this requirement is not met. Note that it is @emph{very} unlikely that any production Fortran code tries to use this unsupported construct. @node Conformance @section Conformance (The following information augments or overrides the information in Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 1 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) The definition of the GNU Fortran language is akin to that of the ANSI FORTRAN 77 language in that it does not generally require conforming implementations to diagnose cases where programs do not conform to the language. However, @command{g77} as a compiler is being developed in a way that is intended to enable it to diagnose such cases in an easy-to-understand manner. A program that conforms to the GNU Fortran language should, when compiled, linked, and executed using a properly installed @command{g77} system, perform as described by the GNU Fortran language definition. Reasons for different behavior include, among others: @itemize @bullet @item Use of resources (memory---heap, stack, and so on; disk space; CPU time; etc.) exceeds those of the system. @item Range and/or precision of calculations required by the program exceeds that of the system. @item Excessive reliance on behaviors that are system-dependent (non-portable Fortran code). @item Bugs in the program. @item Bug in @command{g77}. @item Bugs in the system. @end itemize Despite these ``loopholes'', the availability of a clear specification of the language of programs submitted to @command{g77}, as this document is intended to provide, is considered an important aspect of providing a robust, clean, predictable Fortran implementation. The definition of the GNU Fortran language, while having no special legal status, can therefore be viewed as a sort of contract, or agreement. This agreement says, in essence, ``if you write a program in this language, and run it in an environment (such as a @command{g77} system) that supports this language, the program should behave in a largely predictable way''. @node Notation Used @section Notation Used in This Chapter (The following information augments or overrides the information in Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 1 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) In this chapter, ``must'' denotes a requirement, ``may'' denotes permission, and ``must not'' and ``may not'' denote prohibition. Terms such as ``might'', ``should'', and ``can'' generally add little or nothing in the way of weight to the GNU Fortran language itself, but are used to explain or illustrate the language. For example: @display ``The @code{FROBNITZ} statement must precede all executable statements in a program unit, and may not specify any dummy arguments. It may specify local or common variables and arrays. Its use should be limited to portions of the program designed to be non-portable and system-specific, because it might cause the containing program unit to behave quite differently on different systems.'' @end display Insofar as the GNU Fortran language is specified, the requirements and permissions denoted by the above sample statement are limited to the placement of the statement and the kinds of things it may specify. The rest of the statement---the content regarding non-portable portions of the program and the differing behavior of program units containing the @code{FROBNITZ} statement---does not pertain the GNU Fortran language itself. That content offers advice and warnings about the @code{FROBNITZ} statement. @emph{Remember:} The GNU Fortran language definition specifies both what constitutes a valid GNU Fortran program and how, given such a program, a valid GNU Fortran implementation is to interpret that program. It is @emph{not} incumbent upon a valid GNU Fortran implementation to behave in any particular way, any consistent way, or any predictable way when it is asked to interpret input that is @emph{not} a valid GNU Fortran program. Such input is said to have @dfn{undefined} behavior when interpreted by a valid GNU Fortran implementation, though an implementation may choose to specify behaviors for some cases of inputs that are not valid GNU Fortran programs. Other notation used herein is that of the GNU texinfo format, which is used to generate printed hardcopy, on-line hypertext (Info), and on-line HTML versions, all from a single source document. This notation is used as follows: @itemize @bullet @item Keywords defined by the GNU Fortran language are shown in uppercase, as in: @code{COMMON}, @code{INTEGER}, and @code{BLOCK DATA}. Note that, in practice, many Fortran programs are written in lowercase---uppercase is used in this manual as a means to readily distinguish keywords and sample Fortran-related text from the prose in this document. @item Portions of actual sample program, input, or output text look like this: @samp{Actual program text}. Generally, uppercase is used for all Fortran-specific and Fortran-related text, though this does not always include literal text within Fortran code. For example: @samp{PRINT *, 'My name is Bob'}. @item A metasyntactic variable---that is, a name used in this document to serve as a placeholder for whatever text is used by the user or programmer---appears as shown in the following example: ``The @code{INTEGER @var{ivar}} statement specifies that @var{ivar} is a variable or array of type @code{INTEGER}.'' In the above example, any valid text may be substituted for the metasyntactic variable @var{ivar} to make the statement apply to a specific instance, as long as the same text is substituted for @emph{both} occurrences of @var{ivar}. @item Ellipses (``@dots{}'') are used to indicate further text that is either unimportant or expanded upon further, elsewhere. @item Names of data types are in the style of Fortran 90, in most cases. @xref{Kind Notation}, for information on the relationship between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)}) and the more traditional, less portably concise nomenclature (such as @code{INTEGER*4}). @end itemize @node Terms and Concepts @section Fortran Terms and Concepts (The following information augments or overrides the information in Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 2 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * Syntactic Items:: * Statements Comments Lines:: * Scope of Names and Labels:: @end menu @node Syntactic Items @subsection Syntactic Items (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.) @cindex limits, lengths of names In GNU Fortran, a symbolic name is at least one character long, and has no arbitrary upper limit on length. However, names of entities requiring external linkage (such as external functions, external subroutines, and @code{COMMON} areas) might be restricted to some arbitrary length by the system. Such a restriction is no more constrained than that of one through six characters. Underscores (@samp{_}) are accepted in symbol names after the first character (which must be a letter). @node Statements Comments Lines @subsection Statements, Comments, and Lines (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.) @cindex trailing comment @cindex comment @cindex characters, comment @cindex ! @cindex exclamation point @cindex continuation character @cindex characters, continuation Use of an exclamation point (@samp{!}) to begin a trailing comment (a comment that extends to the end of the same source line) is permitted under the following conditions: @itemize @bullet @item The exclamation point does not appear in column 6. Otherwise, it is treated as an indicator of a continuation line. @item The exclamation point appears outside a character or Hollerith constant. Otherwise, the exclamation point is considered part of the constant. @item The exclamation point appears to the left of any other possible trailing comment. That is, a trailing comment may contain exclamation points in their commentary text. @end itemize @cindex ; @cindex semicolon @cindex statements, separated by semicolon Use of a semicolon (@samp{;}) as a statement separator is permitted under the following conditions: @itemize @bullet @item The semicolon appears outside a character or Hollerith constant. Otherwise, the semicolon is considered part of the constant. @item The semicolon appears to the left of a trailing comment. Otherwise, the semicolon is considered part of that comment. @item Neither a logical @code{IF} statement nor a non-construct @code{WHERE} statement (a Fortran 90 feature) may be followed (in the same, possibly continued, line) by a semicolon used as a statement separator. This restriction avoids the confusion that can result when reading a line such as: @smallexample IF (VALIDP) CALL FOO; CALL BAR @end smallexample @noindent Some readers might think the @samp{CALL BAR} is executed only if @samp{VALIDP} is @code{.TRUE.}, while others might assume its execution is unconditional. (At present, @command{g77} does not diagnose code that violates this restriction.) @end itemize @node Scope of Names and Labels @subsection Scope of Symbolic Names and Statement Labels @cindex scope (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.) Included in the list of entities that have a scope of a program unit are construct names (a Fortran 90 feature). @xref{Construct Names}, for more information. @node Characters Lines Sequence @section Characters, Lines, and Execution Sequence (The following information augments or overrides the information in Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 3 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * Character Set:: * Lines:: * Continuation Line:: * Statements:: * Statement Labels:: * Order:: * INCLUDE:: * Cpp-style directives:: @end menu @node Character Set @subsection GNU Fortran Character Set @cindex characters (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.) Letters include uppercase letters (the twenty-six characters of the English alphabet) and lowercase letters (their lowercase equivalent). Generally, lowercase letters may be used in place of uppercase letters, though in character and Hollerith constants, they are distinct. Special characters include: @itemize @bullet @item @cindex ; @cindex semicolon Semicolon (@samp{;}) @item @cindex ! @cindex exclamation point Exclamation point (@samp{!}) @item @cindex " @cindex double quote Double quote (@samp{"}) @item @cindex \ @cindex backslash Backslash (@samp{\}) @item @cindex ? @cindex question mark Question mark (@samp{?}) @item @cindex # @cindex hash mark @cindex pound sign Hash mark (@samp{#}) @item @cindex & @cindex ampersand Ampersand (@samp{&}) @item @cindex % @cindex percent sign Percent sign (@samp{%}) @item @cindex _ @cindex underscore Underscore (@samp{_}) @item @cindex < @cindex open angle @cindex left angle @cindex open bracket @cindex left bracket Open angle (@samp{<}) @item @cindex > @cindex close angle @cindex right angle @cindex close bracket @cindex right bracket Close angle (@samp{>}) @item The FORTRAN 77 special characters (@key{SPC}, @samp{=}, @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(}, @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'}, and @samp{:}) @end itemize @cindex blank @cindex space @cindex SPC Note that this document refers to @key{SPC} as @dfn{space}, while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}. @node Lines @subsection Lines @cindex lines @cindex source file format @cindex source format @cindex file, source @cindex source code @cindex code, source @cindex fixed form @cindex free form (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.) The way a Fortran compiler views source files depends entirely on the implementation choices made for the compiler, since those choices are explicitly left to the implementation by the published Fortran standards. The GNU Fortran language mandates a view applicable to UNIX-like text files---files that are made up of an arbitrary number of lines, each with an arbitrary number of characters (sometimes called stream-based files). This view does not apply to types of files that are specified as having a particular number of characters on every single line (sometimes referred to as record-based files). Because a ``line in a program unit is a sequence of 72 characters'', to quote X3.9-1978, the GNU Fortran language specifies that a stream-based text file is translated to GNU Fortran lines as follows: @itemize @bullet @item A newline in the file is the character that represents the end of a line of text to the underlying system. For example, on ASCII-based systems, a newline is the @key{NL} character, which has ASCII value 10 (decimal). @item Each newline in the file serves to end the line of text that precedes it (and that does not contain a newline). @item The end-of-file marker (@code{EOF}) also serves to end the line of text that precedes it (and that does not contain a newline). @item @cindex blank @cindex space @cindex SPC Any line of text that is shorter than 72 characters is padded to that length with spaces (called ``blanks'' in the standard). @item Any line of text that is longer than 72 characters is truncated to that length, but the truncated remainder must consist entirely of spaces. @item Characters other than newline and the GNU Fortran character set are invalid. @end itemize For the purposes of the remainder of this description of the GNU Fortran language, the translation described above has already taken place, unless otherwise specified. The result of the above translation is that the source file appears, in terms of the remainder of this description of the GNU Fortran language, as if it had an arbitrary number of 72-character lines, each character being among the GNU Fortran character set. For example, if the source file itself has two newlines in a row, the second newline becomes, after the above translation, a single line containing 72 spaces. @node Continuation Line @subsection Continuation Line @cindex continuation line, number of @cindex lines, continuation @cindex number of continuation lines @cindex limits, continuation lines (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.) A continuation line is any line that both @itemize @bullet @item Contains a continuation character, and @item Contains only spaces in columns 1 through 5 @end itemize A continuation character is any character of the GNU Fortran character set other than space (@key{SPC}) or zero (@samp{0}) in column 6, or a digit (@samp{0} through @samp{9}) in column 7 through 72 of a line that has only spaces to the left of that digit. The continuation character is ignored as far as the content of the statement is concerned. The GNU Fortran language places no limit on the number of continuation lines in a statement. In practice, the limit depends on a variety of factors, such as available memory, statement content, and so on, but no GNU Fortran system may impose an arbitrary limit. @node Statements @subsection Statements (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.) Statements may be written using an arbitrary number of continuation lines. Statements may be separated using the semicolon (@samp{;}), except that the logical @code{IF} and non-construct @code{WHERE} statements may not be separated from subsequent statements using only a semicolon as statement separator. The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION}, and @code{END BLOCK DATA} statements are alternatives to the @code{END} statement. These alternatives may be written as normal statements---they are not subject to the restrictions of the @code{END} statement. However, no statement other than @code{END} may have an initial line that appears to be an @code{END} statement---even @code{END PROGRAM}, for example, must not be written as: @example END &PROGRAM @end example @node Statement Labels @subsection Statement Labels (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.) A statement separated from its predecessor via a semicolon may be labeled as follows: @itemize @bullet @item The semicolon is followed by the label for the statement, which in turn follows the label. @item The label must be no more than five digits in length. @item The first digit of the label for the statement is not the first non-space character on a line. Otherwise, that character is treated as a continuation character. @end itemize A statement may have only one label defined for it. @node Order @subsection Order of Statements and Lines (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.) Generally, @code{DATA} statements may precede executable statements. However, specification statements pertaining to any entities initialized by a @code{DATA} statement must precede that @code{DATA} statement. For example, after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but @samp{INTEGER J} is permitted. The last line of a program unit may be an @code{END} statement, or may be: @itemize @bullet @item An @code{END PROGRAM} statement, if the program unit is a main program. @item An @code{END SUBROUTINE} statement, if the program unit is a subroutine. @item An @code{END FUNCTION} statement, if the program unit is a function. @item An @code{END BLOCK DATA} statement, if the program unit is a block data. @end itemize @node INCLUDE @subsection Including Source Text @cindex INCLUDE directive Additional source text may be included in the processing of the source file via the @code{INCLUDE} directive: @example INCLUDE @var{filename} @end example @noindent The source text to be included is identified by @var{filename}, which is a literal GNU Fortran character constant. The meaning and interpretation of @var{filename} depends on the implementation, but typically is a filename. (@command{g77} treats it as a filename that it searches for in the current directory and/or directories specified via the @option{-I} command-line option.) The effect of the @code{INCLUDE} directive is as if the included text directly replaced the directive in the source file prior to interpretation of the program. Included text may itself use @code{INCLUDE}. The depth of nested @code{INCLUDE} references depends on the implementation, but typically is a positive integer. This virtual replacement treats the statements and @code{INCLUDE} directives in the included text as syntactically distinct from those in the including text. Therefore, the first non-comment line of the included text must not be a continuation line. The included text must therefore have, after the non-comment lines, either an initial line (statement), an @code{INCLUDE} directive, or nothing (the end of the included text). Similarly, the including text may end the @code{INCLUDE} directive with a semicolon or the end of the line, but it cannot follow an @code{INCLUDE} directive at the end of its line with a continuation line. Thus, the last statement in an included text may not be continued. Any statements between two @code{INCLUDE} directives on the same line are treated as if they appeared in between the respective included texts. For example: @smallexample INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM @end smallexample @noindent If the text included by @samp{INCLUDE 'A'} constitutes a @samp{PRINT *, 'A'} statement and the text included by @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement, then the output of the above sample program would be @example A B C @end example @noindent (with suitable allowances for how an implementation defines its handling of output). Included text must not include itself directly or indirectly, regardless of whether the @var{filename} used to reference the text is the same. Note that @code{INCLUDE} is @emph{not} a statement. As such, it is neither a non-executable or executable statement. However, if the text it includes constitutes one or more executable statements, then the placement of @code{INCLUDE} is subject to effectively the same restrictions as those on executable statements. An @code{INCLUDE} directive may be continued across multiple lines as if it were a statement. This permits long names to be used for @var{filename}. @node Cpp-style directives @subsection Cpp-style directives @cindex # @cindex preprocessor @code{cpp} output-style @code{#} directives (@pxref{C Preprocessor Output,,, cpp, The C Preprocessor}) are recognized by the compiler even when the preprocessor isn't run on the input (as it is when compiling @samp{.F} files). (Note the distinction between these @command{cpp} @code{#} @emph{output} directives and @code{#line} @emph{input} directives.) @node Data Types and Constants @section Data Types and Constants (The following information augments or overrides the information in Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 4 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) To more concisely express the appropriate types for entities, this document uses the more concise Fortran 90 nomenclature such as @code{INTEGER(KIND=1)} instead of the more traditional, but less portably concise, byte-size-based nomenclature such as @code{INTEGER*4}, wherever reasonable. When referring to generic types---in contexts where the specific precision and range of a type are not important---this document uses the generic type names @code{INTEGER}, @code{LOGICAL}, @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}. In some cases, the context requires specification of a particular type. This document uses the @samp{KIND=} notation to accomplish this throughout, sometimes supplying the more traditional notation for clarification, though the traditional notation might not work the same way on all GNU Fortran implementations. Use of @samp{KIND=} makes this document more concise because @command{g77} is able to define values for @samp{KIND=} that have the same meanings on all systems, due to the way the Fortran 90 standard specifies these values are to be used. (In particular, that standard permits an implementation to arbitrarily assign nonnegative values. There are four distinct sets of assignments: one to the @code{CHARACTER} type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type; and the fourth to both the @code{REAL} and @code{COMPLEX} types. Implementations are free to assign these values in any order, leave gaps in the ordering of assignments, and assign more than one value to a representation.) This makes @samp{KIND=} values superior to the values used in non-standard statements such as @samp{INTEGER*4}, because the meanings of the values in those statements vary from machine to machine, compiler to compiler, even operating system to operating system. However, use of @samp{KIND=} is @emph{not} generally recommended when writing portable code (unless, for example, the code is going to be compiled only via @command{g77}, which is a widely ported compiler). GNU Fortran does not yet have adequate language constructs to permit use of @samp{KIND=} in a fashion that would make the code portable to Fortran 90 implementations; and, this construct is known to @emph{not} be accepted by many popular FORTRAN 77 implementations, so it cannot be used in code that is to be ported to those. The distinction here is that this document is able to use specific values for @samp{KIND=} to concisely document the types of various operations and operands. A Fortran program should use the FORTRAN 77 designations for the appropriate GNU Fortran types---such as @code{INTEGER} for @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)}, and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and, where no such designations exist, make use of appropriate techniques (preprocessor macros, parameters, and so on) to specify the types in a fashion that may be easily adjusted to suit each particular implementation to which the program is ported. (These types generally won't need to be adjusted for ports of @command{g77}.) Further details regarding GNU Fortran data types and constants are provided below. @menu * Types:: * Constants:: * Integer Type:: * Character Type:: @end menu @node Types @subsection Data Types (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.) GNU Fortran supports these types: @enumerate @item Integer (generic type @code{INTEGER}) @item Real (generic type @code{REAL}) @item Double precision @item Complex (generic type @code{COMPLEX}) @item Logical (generic type @code{LOGICAL}) @item Character (generic type @code{CHARACTER}) @item Double Complex @end enumerate (The types numbered 1 through 6 above are standard FORTRAN 77 types.) The generic types shown above are referred to in this document using only their generic type names. Such references usually indicate that any specific type (kind) of that generic type is valid. For example, a context described in this document as accepting the @code{COMPLEX} type also is likely to accept the @code{DOUBLE COMPLEX} type. The GNU Fortran language supports three ways to specify a specific kind of a generic type. @menu * Double Notation:: As in @code{DOUBLE COMPLEX}. * Star Notation:: As in @code{INTEGER*4}. * Kind Notation:: As in @code{INTEGER(KIND=1)}. @end menu @node Double Notation @subsubsection Double Notation The GNU Fortran language supports two uses of the keyword @code{DOUBLE} to specify a specific kind of type: @itemize @bullet @item @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)} @item @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)} @end itemize Use one of the above forms where a type name is valid. While use of this notation is popular, it doesn't scale well in a language or dialect rich in intrinsic types, as is the case for the GNU Fortran language (especially planned future versions of it). After all, one rarely sees type names such as @samp{DOUBLE INTEGER}, @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}. Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1} often are substituted for these, respectively, even though they do not always have the same meanings on all systems. (And, the fact that @samp{DOUBLE REAL} does not exist as such is an inconsistency.) Therefore, this document uses ``double notation'' only on occasion for the benefit of those readers who are accustomed to it. @node Star Notation @subsubsection Star Notation @cindex *@var{n} notation The following notation specifies the storage size for a type: @smallexample @var{generic-type}*@var{n} @end smallexample @noindent @var{generic-type} must be a generic type---one of @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL}, or @code{CHARACTER}. @var{n} must be one or more digits comprising a decimal integer number greater than zero. Use the above form where a type name is valid. The @samp{*@var{n}} notation specifies that the amount of storage occupied by variables and array elements of that type is @var{n} times the storage occupied by a @code{CHARACTER*1} variable. This notation might indicate a different degree of precision and/or range for such variables and array elements, and the functions that return values of types using this notation. It does not limit the precision or range of values of that type in any particular way---use explicit code to do that. Further, the GNU Fortran language requires no particular values for @var{n} to be supported by an implementation via the @samp{*@var{n}} notation. @command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)}) on all systems, for example, but not all implementations are required to do so, and @command{g77} is known to not support @code{REAL*1} on most (or all) systems. As a result, except for @var{generic-type} of @code{CHARACTER}, uses of this notation should be limited to isolated portions of a program that are intended to handle system-specific tasks and are expected to be non-portable. (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for only @code{CHARACTER}, where it signifies not only the amount of storage occupied, but the number of characters in entities of that type. However, almost all Fortran compilers have supported this notation for generic types, though with a variety of meanings for @var{n}.) Specifications of types using the @samp{*@var{n}} notation always are interpreted as specifications of the appropriate types described in this document using the @samp{KIND=@var{n}} notation, described below. While use of this notation is popular, it doesn't serve well in the context of a widely portable dialect of Fortran, such as the GNU Fortran language. For example, even on one particular machine, two or more popular Fortran compilers might well disagree on the size of a type declared @code{INTEGER*2} or @code{REAL*16}. Certainly there is known to be disagreement over such things among Fortran compilers on @emph{different} systems. Further, this notation offers no elegant way to specify sizes that are not even multiples of the ``byte size'' typically designated by @code{INTEGER*1}. Use of ``absurd'' values (such as @code{INTEGER*1000}) would certainly be possible, but would perhaps be stretching the original intent of this notation beyond the breaking point in terms of widespread readability of documentation and code making use of it. Therefore, this document uses ``star notation'' only on occasion for the benefit of those readers who are accustomed to it. @node Kind Notation @subsubsection Kind Notation @cindex KIND= notation The following notation specifies the kind-type selector of a type: @smallexample @var{generic-type}(KIND=@var{n}) @end smallexample @noindent Use the above form where a type name is valid. @var{generic-type} must be a generic type---one of @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL}, or @code{CHARACTER}. @var{n} must be an integer initialization expression that is a positive, nonzero value. Programmers are discouraged from writing these values directly into their code. Future versions of the GNU Fortran language will offer facilities that will make the writing of code portable to @command{g77} @emph{and} Fortran 90 implementations simpler. However, writing code that ports to existing FORTRAN 77 implementations depends on avoiding the @samp{KIND=} construct. The @samp{KIND=} construct is thus useful in the context of GNU Fortran for two reasons: @itemize @bullet @item It provides a means to specify a type in a fashion that is portable across all GNU Fortran implementations (though not other FORTRAN 77 and Fortran 90 implementations). @item It provides a sort of Rosetta stone for this document to use to concisely describe the types of various operations and operands. @end itemize The values of @var{n} in the GNU Fortran language are assigned using a scheme that: @itemize @bullet @item Attempts to maximize the ability of readers of this document to quickly familiarize themselves with assignments for popular types @item Provides a unique value for each specific desired meaning @item Provides a means to automatically assign new values so they have a ``natural'' relationship to existing values, if appropriate, or, if no such relationship exists, will not interfere with future values assigned on the basis of such relationships @item Avoids using values that are similar to values used in the existing, popular @samp{*@var{n}} notation, to prevent readers from expecting that these implied correspondences work on all GNU Fortran implementations @end itemize The assignment system accomplishes this by assigning to each ``fundamental meaning'' of a specific type a unique prime number. Combinations of fundamental meanings---for example, a type that is two times the size of some other type---are assigned values of @var{n} that are the products of the values for those fundamental meanings. A prime value of @var{n} is never given more than one fundamental meaning, to avoid situations where some code or system cannot reasonably provide those meanings in the form of a single type. The values of @var{n} assigned so far are: @table @code @item KIND=0 This value is reserved for future use. The planned future use is for this value to designate, explicitly, context-sensitive kind-type selection. For example, the expression @samp{1D0 * 0.1_0} would be equivalent to @samp{1D0 * 0.1D0}. @item KIND=1 This corresponds to the default types for @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX}, and @code{CHARACTER}, as appropriate. These are the ``default'' types described in the Fortran 90 standard, though that standard does not assign any particular @samp{KIND=} value to these types. (Typically, these are @code{REAL*4}, @code{INTEGER*4}, @code{LOGICAL*4}, and @code{COMPLEX*8}.) @item KIND=2 This corresponds to types that occupy twice as much storage as the default types. @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}), @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}), These are the ``double precision'' types described in the Fortran 90 standard, though that standard does not assign any particular @samp{KIND=} value to these types. @var{n} of 4 thus corresponds to types that occupy four times as much storage as the default types, @var{n} of 8 to types that occupy eight times as much storage, and so on. The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types are not necessarily supported by every GNU Fortran implementation. @item KIND=3 This corresponds to types that occupy as much storage as the default @code{CHARACTER} type, which is the same effective type as @code{CHARACTER(KIND=1)} (making that type effectively the same as @code{CHARACTER(KIND=3)}). (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.) @var{n} of 6 thus corresponds to types that occupy twice as much storage as the @var{n}=3 types, @var{n} of 12 to types that occupy four times as much storage, and so on. These are not necessarily supported by every GNU Fortran implementation. @item KIND=5 This corresponds to types that occupy half the storage as the default (@var{n}=1) types. (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.) @var{n} of 25 thus corresponds to types that occupy one-quarter as much storage as the default types. These are not necessarily supported by every GNU Fortran implementation. @item KIND=7 @cindex pointers This is valid only as @code{INTEGER(KIND=7)} and denotes the @code{INTEGER} type that has the smallest storage size that holds a pointer on the system. A pointer representable by this type is capable of uniquely addressing a @code{CHARACTER*1} variable, array, array element, or substring. (Typically this is equivalent to @code{INTEGER*4} or, on 64-bit systems, @code{INTEGER*8}. In a compatible C implementation, it typically would be the same size and semantics of the C type @code{void *}.) @end table Note that these are @emph{proposed} correspondences and might change in future versions of @command{g77}---avoid writing code depending on them while @command{g77}, and therefore the GNU Fortran language it defines, is in beta testing. Values not specified in the above list are reserved to future versions of the GNU Fortran language. Implementation-dependent meanings will be assigned new, unique prime numbers so as to not interfere with other implementation-dependent meanings, and offer the possibility of increasing the portability of code depending on such types by offering support for them in other GNU Fortran implementations. Other meanings that might be given unique values are: @itemize @bullet @item Types that make use of only half their storage size for representing precision and range. For example, some compilers offer options that cause @code{INTEGER} types to occupy the amount of storage that would be needed for @code{INTEGER(KIND=2)} types, but the range remains that of @code{INTEGER(KIND=1)}. @item The IEEE single floating-point type. @item Types with a specific bit pattern (endianness), such as the little-endian form of @code{INTEGER(KIND=1)}. These could permit, conceptually, use of portable code and implementations on data files written by existing systems. @end itemize Future @emph{prime} numbers should be given meanings in as incremental a fashion as possible, to allow for flexibility and expressiveness in combining types. For example, instead of defining a prime number for little-endian IEEE doubles, one prime number might be assigned the meaning ``little-endian'', another the meaning ``IEEE double'', and the value of @var{n} for a little-endian IEEE double would thus naturally be the product of those two respective assigned values. (It could even be reasonable to have IEEE values result from the products of prime values denoting exponent and fraction sizes and meanings, hidden bit usage, availability and representations of special values such as subnormals, infinities, and Not-A-Numbers (NaNs), and so on.) This assignment mechanism, while not inherently required for future versions of the GNU Fortran language, is worth using because it could ease management of the ``space'' of supported types much easier in the long run. The above approach suggests a mechanism for specifying inheritance of intrinsic (built-in) types for an entire, widely portable product line. It is certainly reasonable that, unlike programmers of other languages offering inheritance mechanisms that employ verbose names for classes and subclasses, along with graphical browsers to elucidate the relationships, Fortran programmers would employ a mechanism that works by multiplying prime numbers together and finding the prime factors of such products. Most of the advantages for the above scheme have been explained above. One disadvantage is that it could lead to the defining, by the GNU Fortran language, of some fairly large prime numbers. This could lead to the GNU Fortran language being declared ``munitions'' by the United States Department of Defense. @node Constants @subsection Constants @cindex constants @cindex types, constants (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.) A @dfn{typeless constant} has one of the following forms: @smallexample '@var{binary-digits}'B '@var{octal-digits}'O '@var{hexadecimal-digits}'Z '@var{hexadecimal-digits}'X @end smallexample @noindent @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits} are nonempty strings of characters in the set @samp{01}, @samp{01234567}, and @samp{0123456789ABCDEFabcdef}, respectively. (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b} is 11, and so on.) A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be treated as typeless. @xref{Fortran Dialect Options,, Options Controlling Fortran Dialect}, for information on the @option{-ftypeless-boz} option. Typeless constants have values that depend on the context in which they are used. All other constants, called @dfn{typed constants}, are interpreted---converted to internal form---according to their inherent type. Thus, context is @emph{never} a determining factor for the type, and hence the interpretation, of a typed constant. (All constants in the ANSI FORTRAN 77 language are typed constants.) For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU Fortran (called default INTEGER in Fortran 90), @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the additional precision specified is lost, and even when used in a @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)}, and @samp{1D0} is always type @code{REAL(KIND=2)}. @node Integer Type @subsection Integer Type (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.) An integer constant also may have one of the following forms: @smallexample B'@var{binary-digits}' O'@var{octal-digits}' Z'@var{hexadecimal-digits}' X'@var{hexadecimal-digits}' @end smallexample @noindent @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits} are nonempty strings of characters in the set @samp{01}, @samp{01234567}, and @samp{0123456789ABCDEFabcdef}, respectively. (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b} is 11, and so on.) @node Character Type @subsection Character Type (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.) @cindex double quoted character constants A character constant may be delimited by a pair of double quotes (@samp{"}) instead of apostrophes. In this case, an apostrophe within the constant represents a single apostrophe, while a double quote is represented in the source text of the constant by two consecutive double quotes with no intervening spaces. @cindex zero-length CHARACTER @cindex null CHARACTER strings @cindex empty CHARACTER strings @cindex strings, empty @cindex CHARACTER, null A character constant may be empty (have a length of zero). A character constant may include a substring specification, The value of such a constant is the value of the substring---for example, the value of @samp{'hello'(3:5)} is the same as the value of @samp{'llo'}. @node Expressions @section Expressions (The following information augments or overrides the information in Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 6 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * %LOC():: @end menu @node %LOC() @subsection The @code{%LOC()} Construct @cindex %LOC() construct @example %LOC(@var{arg}) @end example The @code{%LOC()} construct is an expression that yields the value of the location of its argument, @var{arg}, in memory. The size of the type of the expression depends on the system---typically, it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)}, though it is actually type @code{INTEGER(KIND=7)}. The argument to @code{%LOC()} must be suitable as the left-hand side of an assignment statement. That is, it may not be a general expression involving operators such as addition, subtraction, and so on, nor may it be a constant. Use of @code{%LOC()} is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions that deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler. Do not depend on @code{%LOC()} returning a pointer that can be safely used to @emph{define} (change) the argument. While this might work in some circumstances, it is hard to predict whether it will continue to work when a program (that works using this unsafe behavior) is recompiled using different command-line options or a different version of @command{g77}. Generally, @code{%LOC()} is safe when used as an argument to a procedure that makes use of the value of the corresponding dummy argument only during its activation, and only when such use is restricted to referencing (reading) the value of the argument to @code{%LOC()}. @emph{Implementation Note:} Currently, @command{g77} passes arguments (those not passed using a construct such as @code{%VAL()}) by reference or descriptor, depending on the type of the actual argument. Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and in fact might compile to identical code. However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means ``pass, by value, the address of @samp{I} in memory''. While @samp{CALL FOO(I)} might use that same approach in a particular version of @command{g77}, another version or compiler might choose a different implementation, such as copy-in/copy-out, to effect the desired behavior---and which will therefore not necessarily compile to the same code as would @samp{CALL FOO(%VAL(%LOC(I)))} using the same version or compiler. @xref{Debugging and Interfacing}, for detailed information on how this particular version of @command{g77} implements various constructs. @node Specification Statements @section Specification Statements (The following information augments or overrides the information in Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 8 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * NAMELIST:: * DOUBLE COMPLEX:: @end menu @node NAMELIST @subsection @code{NAMELIST} Statement @cindex NAMELIST statement @cindex statements, NAMELIST The @code{NAMELIST} statement, and related I/O constructs, are supported by the GNU Fortran language in essentially the same way as they are by @command{f2c}. This follows Fortran 90 with the restriction that on @code{NAMELIST} input, subscripts must have the form @smallexample @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]] @end smallexample i.e.@: @smallexample &xx x(1:3,8:10:2)=1,2,3,4,5,6/ @end smallexample is allowed, but not, say, @smallexample &xx x(:3,8::2)=1,2,3,4,5,6/ @end smallexample As an extension of the Fortran 90 form, @code{$} and @code{$END} may be used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that @smallexample $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end @end smallexample could be used instead of the example above. @node DOUBLE COMPLEX @subsection @code{DOUBLE COMPLEX} Statement @cindex DOUBLE COMPLEX @code{DOUBLE COMPLEX} is a type-statement (and type) that specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran. @node Control Statements @section Control Statements (The following information augments or overrides the information in Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 11 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * DO WHILE:: * END DO:: * Construct Names:: * CYCLE and EXIT:: @end menu @node DO WHILE @subsection DO WHILE @cindex DO WHILE @cindex DO @cindex MIL-STD 1753 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and Fortran 90 standards, is provided by the GNU Fortran language. The Fortran 90 ``do forever'' statement comprising just @code{DO} is also supported. @node END DO @subsection END DO @cindex END DO @cindex MIL-STD 1753 The @code{END DO} statement is provided by the GNU Fortran language. This statement is used in one of two ways: @itemize @bullet @item The Fortran 90 meaning, in which it specifies the termination point of a single @code{DO} loop started with a @code{DO} statement that specifies no termination label. @item The MIL-STD 1753 meaning, in which it specifies the termination point of one or more @code{DO} loops, all of which start with a @code{DO} statement that specify the label defined for the @code{END DO} statement. This kind of @code{END DO} statement is merely a synonym for @code{CONTINUE}, except it is permitted only when the statement is labeled and a target of one or more labeled @code{DO} loops. It is expected that this use of @code{END DO} will be removed from the GNU Fortran language in the future, though it is likely that it will long be supported by @command{g77} as a dialect form. @end itemize @node Construct Names @subsection Construct Names @cindex construct names The GNU Fortran language supports construct names as defined by the Fortran 90 standard. These names are local to the program unit and are defined as follows: @smallexample @var{construct-name}: @var{block-statement} @end smallexample @noindent Here, @var{construct-name} is the construct name itself; its definition is connoted by the single colon (@samp{:}); and @var{block-statement} is an @code{IF}, @code{DO}, or @code{SELECT CASE} statement that begins a block. A block that is given a construct name must also specify the same construct name in its termination statement: @example END @var{block} @var{construct-name} @end example @noindent Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT}, as appropriate. @node CYCLE and EXIT @subsection The @code{CYCLE} and @code{EXIT} Statements @cindex CYCLE statement @cindex EXIT statement @cindex statements, CYCLE @cindex statements, EXIT The @code{CYCLE} and @code{EXIT} statements specify that the remaining statements in the current iteration of a particular active (enclosing) @code{DO} loop are to be skipped. @code{CYCLE} specifies that these statements are skipped, but the @code{END DO} statement that marks the end of the @code{DO} loop be executed---that is, the next iteration, if any, is to be started. If the statement marking the end of the @code{DO} loop is not @code{END DO}---in other words, if the loop is not a block @code{DO}---the @code{CYCLE} statement does not execute that statement, but does start the next iteration (if any). @code{EXIT} specifies that the loop specified by the @code{DO} construct is terminated. The @code{DO} loop affected by @code{CYCLE} and @code{EXIT} is the innermost enclosing @code{DO} loop when the following forms are used: @example CYCLE EXIT @end example Otherwise, the following forms specify the construct name of the pertinent @code{DO} loop: @example CYCLE @var{construct-name} EXIT @var{construct-name} @end example @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO} statements. However, they cannot be easily thought of as @code{GO TO} statements in obscure cases involving FORTRAN 77 loops. For example: @smallexample DO 10 I = 1, 5 DO 10 J = 1, 5 IF (J .EQ. 5) EXIT DO 10 K = 1, 5 IF (K .EQ. 3) CYCLE 10 PRINT *, 'I=', I, ' J=', J, ' K=', K 20 CONTINUE @end smallexample @noindent In particular, neither the @code{EXIT} nor @code{CYCLE} statements above are equivalent to a @code{GO TO} statement to either label @samp{10} or @samp{20}. To understand the effect of @code{CYCLE} and @code{EXIT} in the above fragment, it is helpful to first translate it to its equivalent using only block @code{DO} loops: @smallexample DO I = 1, 5 DO J = 1, 5 IF (J .EQ. 5) EXIT DO K = 1, 5 IF (K .EQ. 3) CYCLE 10 PRINT *, 'I=', I, ' J=', J, ' K=', K END DO END DO END DO 20 CONTINUE @end smallexample Adding new labels allows translation of @code{CYCLE} and @code{EXIT} to @code{GO TO} so they may be more easily understood by programmers accustomed to FORTRAN coding: @smallexample DO I = 1, 5 DO J = 1, 5 IF (J .EQ. 5) GOTO 18 DO K = 1, 5 IF (K .EQ. 3) GO TO 12 10 PRINT *, 'I=', I, ' J=', J, ' K=', K 12 END DO END DO 18 END DO 20 CONTINUE @end smallexample @noindent Thus, the @code{CYCLE} statement in the innermost loop skips over the @code{PRINT} statement as it begins the next iteration of the loop, while the @code{EXIT} statement in the middle loop ends that loop but @emph{not} the outermost loop. @node Functions and Subroutines @section Functions and Subroutines (The following information augments or overrides the information in Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 15 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * %VAL():: * %REF():: * %DESCR():: * Generics and Specifics:: * REAL() and AIMAG() of Complex:: * CMPLX() of DOUBLE PRECISION:: * MIL-STD 1753:: * f77/f2c Intrinsics:: * Table of Intrinsic Functions:: @end menu @node %VAL() @subsection The @code{%VAL()} Construct @cindex %VAL() construct @example %VAL(@var{arg}) @end example The @code{%VAL()} construct specifies that an argument, @var{arg}, is to be passed by value, instead of by reference or descriptor. @code{%VAL()} is restricted to actual arguments in invocations of external procedures. Use of @code{%VAL()} is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler. @emph{Implementation Note:} Currently, @command{g77} passes all arguments either by reference or by descriptor. Thus, use of @code{%VAL()} tends to be restricted to cases where the called procedure is written in a language other than Fortran that supports call-by-value semantics. (C is an example of such a language.) @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on how this particular version of @command{g77} passes arguments to procedures. @node %REF() @subsection The @code{%REF()} Construct @cindex %REF() construct @example %REF(@var{arg}) @end example The @code{%REF()} construct specifies that an argument, @var{arg}, is to be passed by reference, instead of by value or descriptor. @code{%REF()} is restricted to actual arguments in invocations of external procedures. Use of @code{%REF()} is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler. Do not depend on @code{%REF()} supplying a pointer to the procedure being invoked. While that is a likely implementation choice, other implementation choices are available that preserve Fortran pass-by-reference semantics without passing a pointer to the argument, @var{arg}. (For example, a copy-in/copy-out implementation.) @emph{Implementation Note:} Currently, @command{g77} passes all arguments (other than variables and arrays of type @code{CHARACTER}) by reference. Future versions of, or dialects supported by, @command{g77} might not pass @code{CHARACTER} functions by reference. Thus, use of @code{%REF()} tends to be restricted to cases where @var{arg} is type @code{CHARACTER} but the called procedure accesses it via a means other than the method used for Fortran @code{CHARACTER} arguments. @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on how this particular version of @command{g77} passes arguments to procedures. @node %DESCR() @subsection The @code{%DESCR()} Construct @cindex %DESCR() construct @example %DESCR(@var{arg}) @end example The @code{%DESCR()} construct specifies that an argument, @var{arg}, is to be passed by descriptor, instead of by value or reference. @code{%DESCR()} is restricted to actual arguments in invocations of external procedures. Use of @code{%DESCR()} is recommended only for code that is accessing facilities outside of GNU Fortran, such as operating system or windowing facilities. It is best to constrain such uses to isolated portions of a program---portions the deal specifically and exclusively with low-level, system-dependent facilities. Such portions might well provide a portable interface for use by the program as a whole, but are themselves not portable, and should be thoroughly tested each time they are rebuilt using a new compiler or version of a compiler. Do not depend on @code{%DESCR()} supplying a pointer and/or a length passed by value to the procedure being invoked. While that is a likely implementation choice, other implementation choices are available that preserve the pass-by-reference semantics without passing a pointer to the argument, @var{arg}. (For example, a copy-in/copy-out implementation.) And, future versions of @command{g77} might change the way descriptors are implemented, such as passing a single argument pointing to a record containing the pointer/length information instead of passing that same information via two arguments as it currently does. @emph{Implementation Note:} Currently, @command{g77} passes all variables and arrays of type @code{CHARACTER} by descriptor. Future versions of, or dialects supported by, @command{g77} might pass @code{CHARACTER} functions by descriptor as well. Thus, use of @code{%DESCR()} tends to be restricted to cases where @var{arg} is not type @code{CHARACTER} but the called procedure accesses it via a means similar to the method used for Fortran @code{CHARACTER} arguments. @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on how this particular version of @command{g77} passes arguments to procedures. @node Generics and Specifics @subsection Generics and Specifics @cindex generic intrinsics @cindex intrinsics, generic The ANSI FORTRAN 77 language defines generic and specific intrinsics. In short, the distinctions are: @itemize @bullet @item @emph{Specific} intrinsics have specific types for their arguments and a specific return type. @item @emph{Generic} intrinsics are treated, on a case-by-case basis in the program's source code, as one of several possible specific intrinsics. Typically, a generic intrinsic has a return type that is determined by the type of one or more of its arguments. @end itemize The GNU Fortran language generalizes these concepts somewhat, especially by providing intrinsic subroutines and generic intrinsics that are treated as either a specific intrinsic subroutine or a specific intrinsic function (e.g. @code{SECOND}). However, GNU Fortran avoids generalizing this concept to the point where existing code would be accepted as meaning something possibly different than what was intended. For example, @code{ABS} is a generic intrinsic, so all working code written using @code{ABS} of an @code{INTEGER} argument expects an @code{INTEGER} return value. Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2} argument returns an @code{INTEGER*2} return value. Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only an @code{INTEGER(KIND=1)} argument. Code that passes something other than an @code{INTEGER(KIND=1)} argument to @code{IABS} is not valid GNU Fortran code, because it is not clear what the author intended. For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)} is not defined by the GNU Fortran language, because the programmer might have used that construct to mean any of the following, subtly different, things: @itemize @bullet @item Convert @samp{J} to @code{INTEGER(KIND=1)} first (as if @samp{IABS(INT(J))} had been written). @item Convert the result of the intrinsic to @code{INTEGER(KIND=1)} (as if @samp{INT(ABS(J))} had been written). @item No conversion (as if @samp{ABS(J)} had been written). @end itemize The distinctions matter especially when types and values wider than @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when operations performing more ``arithmetic'' than absolute-value, are involved. The following sample program is not a valid GNU Fortran program, but might be accepted by other compilers. If so, the output is likely to be revealing in terms of how a given compiler treats intrinsics (that normally are specific) when they are given arguments that do not conform to their stated requirements: @cindex JCB002 program @smallexample PROGRAM JCB002 C Version 1: C Modified 1999-02-15 (Burley) to delete my email address. C Modified 1997-05-21 (Burley) to accommodate compilers that implement C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2. C C Version 0: C Written by James Craig Burley 1997-02-20. C C Purpose: C Determine how compilers handle non-standard IDIM C on INTEGER*2 operands, which presumably can be C extrapolated into understanding how the compiler C generally treats specific intrinsics that are passed C arguments not of the correct types. C C If your compiler implements INTEGER*2 and INTEGER C as the same type, change all INTEGER*2 below to C INTEGER*1. C INTEGER*2 I0, I4 INTEGER I1, I2, I3 INTEGER*2 ISMALL, ILARGE INTEGER*2 ITOOLG, ITWO INTEGER*2 ITMP LOGICAL L2, L3, L4 C C Find smallest INTEGER*2 number. C ISMALL=0 10 I0 = ISMALL-1 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20 ISMALL = I0 GOTO 10 20 CONTINUE C C Find largest INTEGER*2 number. C ILARGE=0 30 I0 = ILARGE+1 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40 ILARGE = I0 GOTO 30 40 CONTINUE C C Multiplying by two adds stress to the situation. C ITWO = 2 C C Need a number that, added to -2, is too wide to fit in I*2. C ITOOLG = ISMALL C C Use IDIM the straightforward way. C I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG C C Calculate result for first interpretation. C I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG C C Calculate result for second interpretation. C ITMP = ILARGE - ISMALL I3 = (INT (ITMP)) * ITWO + ITOOLG C C Calculate result for third interpretation. C I4 = (ILARGE - ISMALL) * ITWO + ITOOLG C C Print results. C PRINT *, 'ILARGE=', ILARGE PRINT *, 'ITWO=', ITWO PRINT *, 'ITOOLG=', ITOOLG PRINT *, 'ISMALL=', ISMALL PRINT *, 'I1=', I1 PRINT *, 'I2=', I2 PRINT *, 'I3=', I3 PRINT *, 'I4=', I4 PRINT * L2 = (I1 .EQ. I2) L3 = (I1 .EQ. I3) L4 = (I1 .EQ. I4) IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))' STOP END IF IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))' STOP END IF IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)' STOP END IF PRINT *, 'Results need careful analysis.' END @end smallexample No future version of the GNU Fortran language will likely permit specific intrinsic invocations with wrong-typed arguments (such as @code{IDIM} in the above example), since it has been determined that disagreements exist among many production compilers on the interpretation of such invocations. These disagreements strongly suggest that Fortran programmers, and certainly existing Fortran programs, disagree about the meaning of such invocations. The first version of @code{JCB002} didn't accommodate some compilers' treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are @code{INTEGER*2}. In such a case, these compilers apparently convert both operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction, instead of doing an @code{INTEGER*2} subtraction on the original values in @samp{I1} and @samp{I2}. However, the results of the careful analyses done on the outputs of programs compiled by these various compilers show that they all implement either @samp{Interp 1} or @samp{Interp 2} above. Specifically, it is believed that the new version of @code{JCB002} above will confirm that: @itemize @bullet @item Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5 @command{f77} compilers all implement @samp{Interp 1}. @item IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}. @item Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3, and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}. @end itemize If you get different results than the above for the stated compilers, or have results for other compilers that might be worth adding to the above list, please let us know the details (compiler product, version, machine, results, and so on). @node REAL() and AIMAG() of Complex @subsection @code{REAL()} and @code{AIMAG()} of Complex @cindex @code{Real} intrinsic @cindex intrinsics, @code{Real} @cindex @code{AImag} intrinsic @cindex intrinsics, @code{AImag} The GNU Fortran language disallows @code{REAL(@var{expr})} and @code{AIMAG(@var{expr})}, where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}, except when they are used in the following way: @example REAL(REAL(@var{expr})) REAL(AIMAG(@var{expr})) @end example @noindent The above forms explicitly specify that the desired effect is to convert the real or imaginary part of @var{expr}, which might be some @code{REAL} type other than @code{REAL(KIND=1)}, to type @code{REAL(KIND=1)}, and have that serve as the value of the expression. The GNU Fortran language offers clearly named intrinsics to extract the real and imaginary parts of a complex entity without any conversion: @example REALPART(@var{expr}) IMAGPART(@var{expr}) @end example To express the above using typical extended FORTRAN 77, use the following constructs (when @var{expr} is @code{COMPLEX(KIND=2)}): @example DBLE(@var{expr}) DIMAG(@var{expr}) @end example The FORTRAN 77 language offers no way to explicitly specify the real and imaginary parts of a complex expression of arbitrary type, apparently as a result of requiring support for only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}). The concepts of converting an expression to type @code{REAL(KIND=1)} and of extracting the real part of a complex expression were thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since they happened to have the exact same effect in that language (due to having only one @code{COMPLEX} type). @emph{Note:} When @option{-ff90} is in effect, @command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of type @code{COMPLEX}, as @samp{REALPART(@var{expr})}, whereas with @samp{-fugly-complex -fno-f90} in effect, it is treated as @samp{REAL(REALPART(@var{expr}))}. @xref{Ugly Complex Part Extraction}, for more information. @node CMPLX() of DOUBLE PRECISION @subsection @code{CMPLX()} of @code{DOUBLE PRECISION} @cindex @code{Cmplx} intrinsic @cindex intrinsics, @code{Cmplx} In accordance with Fortran 90 and at least some (perhaps all) other compilers, the GNU Fortran language defines @code{CMPLX()} as always returning a result that is type @code{COMPLEX(KIND=1)}. This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2} are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as: @example CMPLX(SNGL(D1), SNGL(D2)) @end example (It was necessary for Fortran 90 to specify this behavior for @code{DOUBLE PRECISION} arguments, since that is the behavior mandated by FORTRAN 77.) The GNU Fortran language also provides the @code{DCMPLX()} intrinsic, which is provided by some FORTRAN 77 compilers to construct a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION} operands. However, this solution does not scale well when more @code{COMPLEX} types (having various precisions and ranges) are offered by Fortran implementations. Fortran 90 extends the @code{CMPLX()} intrinsic by adding an extra argument used to specify the desired kind of complex result. However, this solution is somewhat awkward to use, and @command{g77} currently does not support it. The GNU Fortran language provides a simple way to build a complex value out of two numbers, with the precise type of the value determined by the types of the two numbers (via the usual type-promotion mechanism): @example COMPLEX(@var{real}, @var{imag}) @end example When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()} performs no conversion other than to put them together to form a complex result of the same (complex version of real) type. @xref{Complex Intrinsic}, for more information. @node MIL-STD 1753 @subsection MIL-STD 1753 Support @cindex MIL-STD 1753 The GNU Fortran language includes the MIL-STD 1753 intrinsics @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS}, @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT}, @code{ISHFTC}, @code{MVBITS}, and @code{NOT}. @node f77/f2c Intrinsics @subsection @command{f77}/@command{f2c} Intrinsics The bit-manipulation intrinsics supported by traditional @command{f77} and by @command{f2c} are available in the GNU Fortran language. These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT}, and @code{XOR}. Also supported are the intrinsics @code{CDABS}, @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN}, @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT}, @code{DIMAG}, @code{DREAL}, and @code{IMAG}, @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN}, and @code{ZSQRT}. @node Table of Intrinsic Functions @subsection Table of Intrinsic Functions @cindex intrinsics, table of @cindex table of intrinsics (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.) The GNU Fortran language adds various functions, subroutines, types, and arguments to the set of intrinsic functions in ANSI FORTRAN 77. The complete set of intrinsics supported by the GNU Fortran language is described below. Note that a name is not treated as that of an intrinsic if it is specified in an @code{EXTERNAL} statement in the same program unit; if a command-line option is used to disable the groups to which the intrinsic belongs; or if the intrinsic is not named in an @code{INTRINSIC} statement and a command-line option is used to hide the groups to which the intrinsic belongs. So, it is recommended that any reference in a program unit to an intrinsic procedure that is not a standard FORTRAN 77 intrinsic be accompanied by an appropriate @code{INTRINSIC} statement in that program unit. This sort of defensive programming makes it more likely that an implementation will issue a diagnostic rather than generate incorrect code for such a reference. The terminology used below is based on that of the Fortran 90 standard, so that the text may be more concise and accurate: @itemize @bullet @item @code{OPTIONAL} means the argument may be omitted. @item @samp{A-1, A-2, @dots{}, A-n} means more than one argument (generally named @samp{A}) may be specified. @item @samp{scalar} means the argument must not be an array (must be a variable or array element, or perhaps a constant if expressions are permitted). @item @samp{DIMENSION(4)} means the argument must be an array having 4 elements. @item @code{INTENT(IN)} means the argument must be an expression (such as a constant or a variable that is defined upon invocation of the intrinsic). @item @code{INTENT(OUT)} means the argument must be definable by the invocation of the intrinsic (that is, must not be a constant nor an expression involving operators other than array reference and substring reference). @item @code{INTENT(INOUT)} means the argument must be defined prior to, and definable by, invocation of the intrinsic (a combination of the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}. @item @xref{Kind Notation}, for an explanation of @code{KIND}. @end itemize @ifinfo (Note that the empty lines appearing in the menu below are not intentional---they result from a bug in the GNU @command{makeinfo} program@dots{}a program that, if it did not exist, would leave this document in far worse shape!) @end ifinfo @c The actual documentation for intrinsics comes from @c intdoc.texi, which in turn is automatically generated @c from the internal g77 tables in intrin.def _and_ the @c largely hand-written text in intdoc.h. So, if you want @c to change or add to existing documentation on intrinsics, @c you probably want to edit intdoc.h. @c @set familyF77 @set familyGNU @set familyASC @set familyMIL @set familyF90 @clear familyVXT @clear familyFVZ @set familyF2C @set familyF2U @clear familyBADU77 @include intdoc.texi @node Scope and Classes of Names @section Scope and Classes of Symbolic Names @cindex symbol names, scope and classes @cindex scope (The following information augments or overrides the information in Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran language. Chapter 18 of that document otherwise serves as the basis for the relevant aspects of GNU Fortran.) @menu * Underscores in Symbol Names:: @end menu @node Underscores in Symbol Names @subsection Underscores in Symbol Names @cindex underscore Underscores (@samp{_}) are accepted in symbol names after the first character (which must be a letter). @node I/O @section I/O @cindex dollar sign A dollar sign at the end of an output format specification suppresses the newline at the end of the output. @cindex <> edit descriptor @cindex edit descriptor, <> Edit descriptors in @code{FORMAT} statements may contain compile-time @code{INTEGER} constant expressions in angle brackets, such as @smallexample 10 FORMAT (I) @end smallexample The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}. These Fortran 90 features are supported: @itemize @bullet @item @cindex FORMAT descriptors @cindex Z edit descriptor @cindex edit descriptor, Z @cindex O edit descriptor @cindex edit descriptor, O The @code{O} and @code{Z} edit descriptors are supported for I/O of integers in octal and hexadecimal formats, respectively. @item The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'} specifier is supported. @end itemize @node Fortran 90 Features @section Fortran 90 Features @cindex Fortran 90 @cindex extensions, from Fortran 90 For convenience this section collects a list (probably incomplete) of the Fortran 90 features supported by the GNU Fortran language, even if they are documented elsewhere. @xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}}, for information on additional fixed source form lexical issues. @cindex @option{-ffree-form} Further, the free source form is supported through the @option{-ffree-form} option. @cindex @option{-ff90} Other Fortran 90 features can be turned on by the @option{-ff90} option; see @ref{Fortran 90}. For information on the Fortran 90 intrinsics available, see @ref{Table of Intrinsic Functions}. @table @asis @item Automatic arrays in procedures @item Character assignments @cindex character assignments In character assignments, the variable being assigned may occur on the right hand side of the assignment. @item Character strings @cindex double quoted character constants Strings may have zero length and substrings of character constants are permitted. Character constants may be enclosed in double quotes (@code{"}) as well as single quotes. @xref{Character Type}. @item Construct names (Symbolic tags on blocks.) @xref{Construct Names}. @item @code{CYCLE} and @code{EXIT} @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}. @item @code{DOUBLE COMPLEX} @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}. @item @code{DO WHILE} @xref{DO WHILE}. @item @code{END} decoration @xref{Statements}. @item @code{END DO} @xref{END DO}. @item @code{KIND} @item @code{IMPLICIT NONE} @item @code{INCLUDE} statements @xref{INCLUDE}. @item List-directed and namelist I/O on internal files @item Binary, octal and hexadecimal constants These are supported more generally than required by Fortran 90. @xref{Integer Type}. @item @samp{O} and @samp{Z} edit descriptors @item @code{NAMELIST} @xref{NAMELIST}. @item @code{OPEN} specifiers @code{STATUS='REPLACE'} is supported. The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if @code{STATUS='SCRATCH'} is supplied. @item @code{FORMAT} edit descriptors @cindex FORMAT descriptors @cindex Z edit descriptor @cindex edit descriptor, Z The @code{Z} edit descriptor is supported. @item Relational operators The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.}, @code{.NE.}, @code{.GT.} and @code{.GE.} respectively. @item @code{SELECT CASE} Not fully implemented. @xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}. @item Specification statements A limited subset of the Fortran 90 syntax and semantics for variable declarations is supported, including @code{KIND}. @xref{Kind Notation}. (@code{KIND} is of limited usefulness in the absence of the @code{KIND}-related intrinsics, since these intrinsics permit writing more widely portable code.) An example of supported @code{KIND} usage is: @smallexample INTEGER (KIND=1) :: FOO=1, BAR=2 CHARACTER (LEN=3) FOO @end smallexample @code{PARAMETER} and @code{DIMENSION} attributes aren't supported. @end table @node Other Dialects @chapter Other Dialects GNU Fortran supports a variety of features that are not considered part of the GNU Fortran language itself, but are representative of various dialects of Fortran that @command{g77} supports in whole or in part. Any of the features listed below might be disallowed by @command{g77} unless some command-line option is specified. Currently, some of the features are accepted using the default invocation of @command{g77}, but that might change in the future. @emph{Note: This portion of the documentation definitely needs a lot of work!} @menu * Source Form:: Details of fixed-form and free-form source. * Trailing Comment:: Use of @samp{/*} to start a comment. * Debug Line:: Use of @samp{D} in column 1. * Dollar Signs:: Use of @samp{$} in symbolic names. * Case Sensitivity:: Uppercase and lowercase in source files. * VXT Fortran:: @dots{}versus the GNU Fortran language. * Fortran 90:: @dots{}versus the GNU Fortran language. * Pedantic Compilation:: Enforcing the standard. * Distensions:: Misfeatures supported by GNU Fortran. @end menu @node Source Form @section Source Form @cindex source file format @cindex source format @cindex file, source @cindex source code @cindex code, source @cindex fixed form @cindex free form GNU Fortran accepts programs written in either fixed form or free form. Fixed form corresponds to ANSI FORTRAN 77 (plus popular extensions, such as allowing tabs) and Fortran 90's fixed form. Free form corresponds to Fortran 90's free form (though possibly not entirely up-to-date, and without complaining about some things that for which Fortran 90 requires diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}). The way a Fortran compiler views source files depends entirely on the implementation choices made for the compiler, since those choices are explicitly left to the implementation by the published Fortran standards. GNU Fortran currently tries to be somewhat like a few popular compilers (@command{f2c}, Digital (``DEC'') Fortran, and so on). This section describes how @command{g77} interprets source lines. @menu * Carriage Returns:: Carriage returns ignored. * Tabs:: Tabs converted to spaces. * Short Lines:: Short lines padded with spaces (fixed-form only). * Long Lines:: Long lines truncated. * Ampersands:: Special Continuation Lines. @end menu @node Carriage Returns @subsection Carriage Returns @cindex carriage returns Carriage returns (@samp{\r}) in source lines are ignored. This is somewhat different from @command{f2c}, which seems to treat them as spaces outside character/Hollerith constants, and encodes them as @samp{\r} inside such constants. @node Tabs @subsection Tabs @cindex tab character @cindex horizontal tab A source line with a @key{TAB} character anywhere in it is treated as entirely significant---however long it is---instead of ending in column 72 (for fixed-form source) or 132 (for free-form source). This also is different from @command{f2c}, which encodes tabs as @samp{\t} (the ASCII @key{TAB} character) inside character and Hollerith constants, but nevertheless seems to treat the column position as if it had been affected by the canonical tab positioning. @command{g77} effectively translates tabs to the appropriate number of spaces (a la the default for the UNIX @command{expand} command) before doing any other processing, other than (currently) noting whether a tab was found on a line and using this information to decide how to interpret the length of the line and continued constants. @node Short Lines @subsection Short Lines @cindex short source lines @cindex space, padding with @cindex source lines, short @cindex lines, short Source lines shorter than the applicable fixed-form length are treated as if they were padded with spaces to that length. (None of this is relevant to source files written in free form.) This affects only continued character and Hollerith constants, and is a different interpretation than provided by some other popular compilers (although a bit more consistent with the traditional punched-card basis of Fortran and the way the Fortran standard expressed fixed source form). @command{g77} might someday offer an option to warn about cases where differences might be seen as a result of this treatment, and perhaps an option to specify the alternate behavior as well. Note that this padding cannot apply to lines that are effectively of infinite length---such lines are specified using command-line options like @option{-ffixed-line-length-none}, for example. @node Long Lines @subsection Long Lines @cindex long source lines @cindex truncation, of long lines @cindex lines, long @cindex source lines, long Source lines longer than the applicable length are truncated to that length. Currently, @command{g77} does not warn if the truncated characters are not spaces, to accommodate existing code written for systems that treated truncated text as commentary (especially in columns 73 through 80). @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect}, for information on the @option{-ffixed-line-length-@var{n}} option, which can be used to set the line length applicable to fixed-form source files. @node Ampersands @subsection Ampersand Continuation Line @cindex ampersand continuation line @cindex continuation line, ampersand A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length continuation line, imitating the behavior of @command{f2c}. @node Trailing Comment @section Trailing Comment @cindex trailing comment @cindex comment @cindex characters, comment @cindex /* @cindex ! @cindex exclamation point @command{g77} supports use of @samp{/*} to start a trailing comment. In the GNU Fortran language, @samp{!} is used for this purpose. @samp{/*} is not in the GNU Fortran language because the use of @samp{/*} in a program might suggest to some readers that a block, not trailing, comment is started (and thus ended by @samp{*/}, not end of line), since that is the meaning of @samp{/*} in C. Also, such readers might think they can use @samp{//} to start a trailing comment as an alternative to @samp{/*}, but @samp{//} already denotes concatenation, and such a ``comment'' might actually result in a program that compiles without error (though it would likely behave incorrectly). @node Debug Line @section Debug Line @cindex debug line @cindex comment line, debug Use of @samp{D} or @samp{d} as the first character (column 1) of a source line denotes a debug line. In turn, a debug line is treated as either a comment line or a normal line, depending on whether debug lines are enabled. When treated as a comment line, a line beginning with @samp{D} or @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively. When treated as a normal line, such a line is treated as if the first character was @key{SPC} (space). (Currently, @command{g77} provides no means for treating debug lines as normal lines.) @node Dollar Signs @section Dollar Signs in Symbol Names @cindex dollar sign @cindex $ Dollar signs (@samp{$}) are allowed in symbol names (after the first character) when the @option{-fdollar-ok} option is specified. @node Case Sensitivity @section Case Sensitivity @cindex case sensitivity @cindex source file format @cindex code, source @cindex source code @cindex uppercase letters @cindex lowercase letters @cindex letters, uppercase @cindex letters, lowercase GNU Fortran offers the programmer way too much flexibility in deciding how source files are to be treated vis-a-vis uppercase and lowercase characters. There are 66 useful settings that affect case sensitivity, plus 10 settings that are nearly useless, with the remaining 116 settings being either redundant or useless. None of these settings have any effect on the contents of comments (the text after a @samp{c} or @samp{C} in Column 1, for example) or of character or Hollerith constants. Note that things like the @samp{E} in the statement @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB} are considered built-in keywords, and so are affected by these settings. Low-level switches are identified in this section as follows: @itemize @w{} @item A Source Case Conversion: @itemize @w{} @item 0 Preserve (see Note 1) @item 1 Convert to Upper Case @item 2 Convert to Lower Case @end itemize @item B Built-in Keyword Matching: @itemize @w{} @item 0 Match Any Case (per-character basis) @item 1 Match Upper Case Only @item 2 Match Lower Case Only @item 3 Match InitialCaps Only (see tables for spellings) @end itemize @item C Built-in Intrinsic Matching: @itemize @w{} @item 0 Match Any Case (per-character basis) @item 1 Match Upper Case Only @item 2 Match Lower Case Only @item 3 Match InitialCaps Only (see tables for spellings) @end itemize @item D User-defined Symbol Possibilities (warnings only): @itemize @w{} @item 0 Allow Any Case (per-character basis) @item 1 Allow Upper Case Only @item 2 Allow Lower Case Only @item 3 Allow InitialCaps Only (see Note 2) @end itemize @end itemize Note 1: @command{g77} eventually will support @code{NAMELIST} in a manner that is consistent with these source switches---in the sense that input will be expected to meet the same requirements as source code in terms of matching symbol names and keywords (for the exponent letters). Currently, however, @code{NAMELIST} is supported by @code{libg2c}, which uppercases @code{NAMELIST} input and symbol names for matching. This means not only that @code{NAMELIST} output currently shows symbol (and keyword) names in uppercase even if lower-case source conversion (option A2) is selected, but that @code{NAMELIST} cannot be adequately supported when source case preservation (option A0) is selected. If A0 is selected, a warning message will be output for each @code{NAMELIST} statement to this effect. The behavior of the program is undefined at run time if two or more symbol names appear in a given @code{NAMELIST} such that the names are identical when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}). For complete and total elegance, perhaps there should be a warning when option A2 is selected, since the output of NAMELIST is currently in uppercase but will someday be lowercase (when a @code{libg77} is written), but that seems to be overkill for a product in beta test. Note 2: Rules for InitialCaps names are: @itemize @minus @item Must be a single uppercase letter, @strong{or} @item Must start with an uppercase letter and contain at least one lowercase letter. @end itemize So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are not. Note that most, but not all, built-in names meet these requirements---the exceptions are some of the two-letter format specifiers, such as @code{BN} and @code{BZ}. Here are the names of the corresponding command-line options: @smallexample A0: -fsource-case-preserve A1: -fsource-case-upper A2: -fsource-case-lower B0: -fmatch-case-any B1: -fmatch-case-upper B2: -fmatch-case-lower B3: -fmatch-case-initcap C0: -fintrin-case-any C1: -fintrin-case-upper C2: -fintrin-case-lower C3: -fintrin-case-initcap D0: -fsymbol-case-any D1: -fsymbol-case-upper D2: -fsymbol-case-lower D3: -fsymbol-case-initcap @end smallexample Useful combinations of the above settings, along with abbreviated option names that set some of these combinations all at once: @smallexample 1: A0-- B0--- C0--- D0--- -fcase-preserve 2: A0-- B0--- C0--- D-1-- 3: A0-- B0--- C0--- D--2- 4: A0-- B0--- C0--- D---3 5: A0-- B0--- C-1-- D0--- 6: A0-- B0--- C-1-- D-1-- 7: A0-- B0--- C-1-- D--2- 8: A0-- B0--- C-1-- D---3 9: A0-- B0--- C--2- D0--- 10: A0-- B0--- C--2- D-1-- 11: A0-- B0--- C--2- D--2- 12: A0-- B0--- C--2- D---3 13: A0-- B0--- C---3 D0--- 14: A0-- B0--- C---3 D-1-- 15: A0-- B0--- C---3 D--2- 16: A0-- B0--- C---3 D---3 17: A0-- B-1-- C0--- D0--- 18: A0-- B-1-- C0--- D-1-- 19: A0-- B-1-- C0--- D--2- 20: A0-- B-1-- C0--- D---3 21: A0-- B-1-- C-1-- D0--- 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper 23: A0-- B-1-- C-1-- D--2- 24: A0-- B-1-- C-1-- D---3 25: A0-- B-1-- C--2- D0--- 26: A0-- B-1-- C--2- D-1-- 27: A0-- B-1-- C--2- D--2- 28: A0-- B-1-- C--2- D---3 29: A0-- B-1-- C---3 D0--- 30: A0-- B-1-- C---3 D-1-- 31: A0-- B-1-- C---3 D--2- 32: A0-- B-1-- C---3 D---3 33: A0-- B--2- C0--- D0--- 34: A0-- B--2- C0--- D-1-- 35: A0-- B--2- C0--- D--2- 36: A0-- B--2- C0--- D---3 37: A0-- B--2- C-1-- D0--- 38: A0-- B--2- C-1-- D-1-- 39: A0-- B--2- C-1-- D--2- 40: A0-- B--2- C-1-- D---3 41: A0-- B--2- C--2- D0--- 42: A0-- B--2- C--2- D-1-- 43: A0-- B--2- C--2- D--2- -fcase-strict-lower 44: A0-- B--2- C--2- D---3 45: A0-- B--2- C---3 D0--- 46: A0-- B--2- C---3 D-1-- 47: A0-- B--2- C---3 D--2- 48: A0-- B--2- C---3 D---3 49: A0-- B---3 C0--- D0--- 50: A0-- B---3 C0--- D-1-- 51: A0-- B---3 C0--- D--2- 52: A0-- B---3 C0--- D---3 53: A0-- B---3 C-1-- D0--- 54: A0-- B---3 C-1-- D-1-- 55: A0-- B---3 C-1-- D--2- 56: A0-- B---3 C-1-- D---3 57: A0-- B---3 C--2- D0--- 58: A0-- B---3 C--2- D-1-- 59: A0-- B---3 C--2- D--2- 60: A0-- B---3 C--2- D---3 61: A0-- B---3 C---3 D0--- 62: A0-- B---3 C---3 D-1-- 63: A0-- B---3 C---3 D--2- 64: A0-- B---3 C---3 D---3 -fcase-initcap 65: A-1- B01-- C01-- D01-- -fcase-upper 66: A--2 B0-2- C0-2- D0-2- -fcase-lower @end smallexample Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input (except comments, character constants, and Hollerith strings) must be entered in uppercase. Use @option{-fcase-strict-upper} to specify this combination. Number 43 is like Number 22 except all input must be lowercase. Use @option{-fcase-strict-lower} to specify this combination. Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many non-UNIX machines whereby all the source is translated to uppercase. Use @option{-fcase-upper} to specify this combination. Number 66 is the ``canonical'' UNIX model whereby all the source is translated to lowercase. Use @option{-fcase-lower} to specify this combination. There are a few nearly useless combinations: @smallexample 67: A-1- B01-- C01-- D--2- 68: A-1- B01-- C01-- D---3 69: A-1- B01-- C--23 D01-- 70: A-1- B01-- C--23 D--2- 71: A-1- B01-- C--23 D---3 72: A--2 B01-- C0-2- D-1-- 73: A--2 B01-- C0-2- D---3 74: A--2 B01-- C-1-3 D0-2- 75: A--2 B01-- C-1-3 D-1-- 76: A--2 B01-- C-1-3 D---3 @end smallexample The above allow some programs to be compiled but with restrictions that make most useful programs impossible: Numbers 67 and 72 warn about @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO}); Numbers 68 and 73 warn about any user-defined symbol names longer than one character that don't have at least one non-alphabetic character after the first; Numbers 69 and 74 disallow any references to intrinsics; and Numbers 70, 71, 75, and 76 are combinations of the restrictions in 67+69, 68+69, 72+74, and 73+74, respectively. All redundant combinations are shown in the above tables anyplace where more than one setting is shown for a low-level switch. For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B. The ``proper'' setting in such a case is the one that copies the setting of switch A---any other setting might slightly reduce the speed of the compiler, though possibly to an unmeasurable extent. All remaining combinations are useless in that they prevent successful compilation of non-null source files (source files with something other than comments). @node VXT Fortran @section VXT Fortran @cindex VXT extensions @cindex extensions, VXT @command{g77} supports certain constructs that have different meanings in VXT Fortran than they do in the GNU Fortran language. Generally, this manual uses the invented term VXT Fortran to refer VAX FORTRAN (circa v4). That compiler offered many popular features, though not necessarily those that are specific to the VAX processor architecture, the VMS operating system, or Digital Equipment Corporation's Fortran product line. (VAX and VMS probably are trademarks of Digital Equipment Corporation.) An extension offered by a Digital Fortran product that also is offered by several other Fortran products for different kinds of systems is probably going to be considered for inclusion in @command{g77} someday, and is considered a VXT Fortran feature. The @option{-fvxt} option generally specifies that, where the meaning of a construct is ambiguous (means one thing in GNU Fortran and another in VXT Fortran), the VXT Fortran meaning is to be assumed. @menu * Double Quote Meaning:: @samp{"2000} as octal constant. * Exclamation Point:: @samp{!} in column 6. @end menu @node Double Quote Meaning @subsection Meaning of Double Quote @cindex double quotes @cindex character constants @cindex constants, character @cindex octal constants @cindex constants, octal @command{g77} treats double-quote (@samp{"}) as beginning an octal constant of @code{INTEGER(KIND=1)} type when the @option{-fvxt} option is specified. The form of this octal constant is @example "@var{octal-digits} @end example @noindent where @var{octal-digits} is a nonempty string of characters in the set @samp{01234567}. For example, the @option{-fvxt} option permits this: @example PRINT *, "20 END @end example @noindent The above program would print the value @samp{16}. @xref{Integer Type}, for information on the preferred construct for integer constants specified using GNU Fortran's octal notation. (In the GNU Fortran language, the double-quote character (@samp{"}) delimits a character constant just as does apostrophe (@samp{'}). There is no way to allow both constructs in the general case, since statements like @samp{PRINT *,"2000 !comment?"} would be ambiguous.) @node Exclamation Point @subsection Meaning of Exclamation Point in Column 6 @cindex ! @cindex exclamation point @cindex continuation character @cindex characters, continuation @cindex comment character @cindex characters, comment @command{g77} treats an exclamation point (@samp{!}) in column 6 of a fixed-form source file as a continuation character rather than as the beginning of a comment (as it does in any other column) when the @option{-fvxt} option is specified. The following program, when run, prints a message indicating whether it is interpreted according to GNU Fortran (and Fortran 90) rules or VXT Fortran rules: @smallexample C234567 (This line begins in column 1.) I = 0 !1 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program' IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program' IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer' END @end smallexample (In the GNU Fortran and Fortran 90 languages, exclamation point is a valid character and, unlike space (@key{SPC}) or zero (@samp{0}), marks a line as a continuation line when it appears in column 6.) @node Fortran 90 @section Fortran 90 @cindex compatibility, Fortran 90 @cindex Fortran 90, compatibility The GNU Fortran language includes a number of features that are part of Fortran 90, even when the @option{-ff90} option is not specified. The features enabled by @option{-ff90} are intended to be those that, when @option{-ff90} is not specified, would have another meaning to @command{g77}---usually meaning something invalid in the GNU Fortran language. So, the purpose of @option{-ff90} is not to specify whether @command{g77} is to gratuitously reject Fortran 90 constructs. The @option{-pedantic} option specified with @option{-fno-f90} is intended to do that, although its implementation is certainly incomplete at this point. When @option{-ff90} is specified: @itemize @bullet @item The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})}, where @var{expr} is @code{COMPLEX} type, is the same type as the real part of @var{expr}. For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)}, @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)}, not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified. @end itemize @node Pedantic Compilation @section Pedantic Compilation @cindex pedantic compilation @cindex compilation, pedantic The @option{-fpedantic} command-line option specifies that @command{g77} is to warn about code that is not standard-conforming. This is useful for finding some extensions @command{g77} accepts that other compilers might not accept. (Note that the @option{-pedantic} and @option{-pedantic-errors} options always imply @option{-fpedantic}.) With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard for conforming code. With @option{-ff90} in force, Fortran 90 is used. The constructs for which @command{g77} issues diagnostics when @option{-fpedantic} and @option{-fno-f90} are in force are: @itemize @bullet @item Automatic arrays, as in @example SUBROUTINE X(N) REAL A(N) @dots{} @end example @noindent where @samp{A} is not listed in any @code{ENTRY} statement, and thus is not a dummy argument. @item The commas in @samp{READ (5), I} and @samp{WRITE (10), J}. These commas are disallowed by FORTRAN 77, but, while strictly superfluous, are syntactically elegant, especially given that commas are required in statements such as @samp{READ 99, I} and @samp{PRINT *, J}. Many compilers permit the superfluous commas for this reason. @item @code{DOUBLE COMPLEX}, either explicitly or implicitly. An explicit use of this type is via a @code{DOUBLE COMPLEX} or @code{IMPLICIT DOUBLE COMPLEX} statement, for examples. An example of an implicit use is the expression @samp{C*D}, where @samp{C} is @code{COMPLEX(KIND=1)} and @samp{D} is @code{DOUBLE PRECISION}. This expression is prohibited by ANSI FORTRAN 77 because the rules of promotion would suggest that it produce a @code{DOUBLE COMPLEX} result---a type not provided for by that standard. @item Automatic conversion of numeric expressions to @code{INTEGER(KIND=1)} in contexts such as: @itemize @minus @item Array-reference indexes. @item Alternate-return values. @item Computed @code{GOTO}. @item @code{FORMAT} run-time expressions (not yet supported). @item Dimension lists in specification statements. @item Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I}) @item Sizes of @code{CHARACTER} entities in specification statements. @item Kind types in specification entities (a Fortran 90 feature). @item Initial, terminal, and incrementation parameters for implied-@code{DO} constructs in @code{DATA} statements. @end itemize @item Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER} in contexts such as arithmetic @code{IF} (where @code{COMPLEX} expressions are disallowed anyway). @item Zero-size array dimensions, as in: @example INTEGER I(10,20,4:2) @end example @item Zero-length @code{CHARACTER} entities, as in: @example PRINT *, '' @end example @item Substring operators applied to character constants and named constants, as in: @example PRINT *, 'hello'(3:5) @end example @item Null arguments passed to statement function, as in: @example PRINT *, FOO(,3) @end example @item Disagreement among program units regarding whether a given @code{COMMON} area is @code{SAVE}d (for targets where program units in a single source file are ``glued'' together as they typically are for UNIX development environments). @item Disagreement among program units regarding the size of a named @code{COMMON} block. @item Specification statements following first @code{DATA} statement. (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J}, but not @samp{INTEGER I}. The @option{-fpedantic} option disallows both of these.) @item Semicolon as statement separator, as in: @example CALL FOO; CALL BAR @end example @c @c @item @c Comma before list of I/O items in @code{WRITE} @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE} @c statements, as with @code{READ} (as explained above). @item Use of @samp{&} in column 1 of fixed-form source (to indicate continuation). @item Use of @code{CHARACTER} constants to initialize numeric entities, and vice versa. @item Expressions having two arithmetic operators in a row, such as @samp{X*-Y}. @end itemize If @option{-fpedantic} is specified along with @option{-ff90}, the following constructs result in diagnostics: @itemize @bullet @item Use of semicolon as a statement separator on a line that has an @code{INCLUDE} directive. @end itemize @node Distensions @section Distensions @cindex distensions @cindex ugly features @cindex features, ugly The @option{-fugly-*} command-line options determine whether certain features supported by VAX FORTRAN and other such compilers, but considered too ugly to be in code that can be changed to use safer and/or more portable constructs, are accepted. These are humorously referred to as ``distensions'', extensions that just plain look ugly in the harsh light of day. @menu * Ugly Implicit Argument Conversion:: Disabled via @option{-fno-ugly-args}. * Ugly Assumed-Size Arrays:: Enabled via @option{-fugly-assumed}. * Ugly Null Arguments:: Enabled via @option{-fugly-comma}. * Ugly Complex Part Extraction:: Enabled via @option{-fugly-complex}. * Ugly Conversion of Initializers:: Disabled via @option{-fno-ugly-init}. * Ugly Integer Conversions:: Enabled via @option{-fugly-logint}. * Ugly Assigned Labels:: Enabled via @option{-fugly-assign}. @end menu @node Ugly Implicit Argument Conversion @subsection Implicit Argument Conversion @cindex Hollerith constants @cindex constants, Hollerith The @option{-fno-ugly-args} option disables passing typeless and Hollerith constants as actual arguments in procedure invocations. For example: @example CALL FOO(4HABCD) CALL BAR('123'O) @end example @noindent These constructs can be too easily used to create non-portable code, but are not considered as ``ugly'' as others. Further, they are widely used in existing Fortran source code in ways that often are quite portable. Therefore, they are enabled by default. @node Ugly Assumed-Size Arrays @subsection Ugly Assumed-Size Arrays @cindex arrays, assumed-size @cindex assumed-size arrays @cindex DIMENSION X(1) The @option{-fugly-assumed} option enables the treatment of any array with a final dimension specified as @samp{1} as an assumed-size array, as if @samp{*} had been specified instead. For example, @samp{DIMENSION X(1)} is treated as if it had read @samp{DIMENSION X(*)} if @samp{X} is listed as a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION}, or @code{ENTRY} statement in the same program unit. Use an explicit lower bound to avoid this interpretation. For example, @samp{DIMENSION X(1:1)} is never treated as if it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}. Nor is @samp{DIMENSION X(2-1)} affected by this option, since that kind of expression is unlikely to have been intended to designate an assumed-size array. This option is used to prevent warnings being issued about apparent out-of-bounds reference such as @samp{X(2) = 99}. It also prevents the array from being used in contexts that disallow assumed-size arrays, such as @samp{PRINT *,X}. In such cases, a diagnostic is generated and the source file is not compiled. The construct affected by this option is used only in old code that pre-exists the widespread acceptance of adjustable and assumed-size arrays in the Fortran community. @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is treated if @samp{X} is listed as a dummy argument only @emph{after} the @code{DIMENSION} statement (presumably in an @code{ENTRY} statement). For example, @option{-fugly-assumed} has no effect on the following program unit: @example SUBROUTINE X REAL A(1) RETURN ENTRY Y(A) PRINT *, A END @end example @node Ugly Complex Part Extraction @subsection Ugly Complex Part Extraction @cindex complex values @cindex real part @cindex imaginary part The @option{-fugly-complex} option enables use of the @code{REAL()} and @code{AIMAG()} intrinsics with arguments that are @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}. With @option{-ff90} in effect, these intrinsics return the unconverted real and imaginary parts (respectively) of their argument. With @option{-fno-f90} in effect, these intrinsics convert the real and imaginary parts to @code{REAL(KIND=1)}, and return the result of that conversion. Due to this ambiguity, the GNU Fortran language defines these constructs as invalid, except in the specific case where they are entirely and solely passed as an argument to an invocation of the @code{REAL()} intrinsic. For example, @example REAL(REAL(Z)) @end example @noindent is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)} and @option{-fno-ugly-complex} is in effect, because the meaning is clear. @command{g77} enforces this restriction, unless @option{-fugly-complex} is specified, in which case the appropriate interpretation is chosen and no diagnostic is issued. @xref{CMPAMBIG}, for information on how to cope with existing code with unclear expectations of @code{REAL()} and @code{AIMAG()} with @code{COMPLEX(KIND=2)} arguments. @xref{RealPart Intrinsic}, for information on the @code{REALPART()} intrinsic, used to extract the real part of a complex expression without conversion. @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()} intrinsic, used to extract the imaginary part of a complex expression without conversion. @node Ugly Null Arguments @subsection Ugly Null Arguments @cindex trailing comma @cindex comma, trailing @cindex characters, comma @cindex null arguments @cindex arguments, null The @option{-fugly-comma} option enables use of a single trailing comma to mean ``pass an extra trailing null argument'' in a list of actual arguments to an external procedure, and use of an empty list of arguments to such a procedure to mean ``pass a single null argument''. @cindex omitting arguments @cindex arguments, omitting (Null arguments often are used in some procedure-calling schemes to indicate omitted arguments.) For example, @samp{CALL FOO(,)} means ``pass two null arguments'', rather than ``pass one null argument''. Also, @samp{CALL BAR()} means ``pass one null argument''. This construct is considered ``ugly'' because it does not provide an elegant way to pass a single null argument that is syntactically distinct from passing no arguments. That is, this construct changes the meaning of code that makes no use of the construct. So, with @option{-fugly-comma} in force, @samp{CALL FOO()} and @samp{I = JFUNC()} pass a single null argument, instead of passing no arguments as required by the Fortran 77 and 90 standards. @emph{Note:} Many systems gracefully allow the case where a procedure call passes one extra argument that the called procedure does not expect. So, in practice, there might be no difference in the behavior of a program that does @samp{CALL FOO()} or @samp{I = JFUNC()} and is compiled with @option{-fugly-comma} in force as compared to its behavior when compiled with the default, @option{-fno-ugly-comma}, in force, assuming @samp{FOO} and @samp{JFUNC} do not expect any arguments to be passed. @node Ugly Conversion of Initializers @subsection Ugly Conversion of Initializers The constructs disabled by @option{-fno-ugly-init} are: @itemize @bullet @cindex Hollerith constants @cindex constants, Hollerith @item Use of Hollerith and typeless constants in contexts where they set initial (compile-time) values for variables, arrays, and named constants---that is, @code{DATA} and @code{PARAMETER} statements, plus type-declaration statements specifying initial values. Here are some sample initializations that are disabled by the @option{-fno-ugly-init} option: @example PARAMETER (VAL='9A304FFE'X) REAL*8 STRING/8HOUTPUT00/ DATA VAR/4HABCD/ @end example @cindex character constants @cindex constants, character @item In the same contexts as above, use of character constants to initialize numeric items and vice versa (one constant per item). Here are more sample initializations that are disabled by the @option{-fno-ugly-init} option: @example INTEGER IA CHARACTER BELL PARAMETER (IA = 'A') PARAMETER (BELL = 7) @end example @item Use of Hollerith and typeless constants on the right-hand side of assignment statements to numeric types, and in other contexts (such as passing arguments in invocations of intrinsic procedures and statement functions) that are treated as assignments to known types (the dummy arguments, in these cases). Here are sample statements that are disabled by the @option{-fno-ugly-init} option: @example IVAR = 4HABCD PRINT *, IMAX0(2HAB, 2HBA) @end example @end itemize The above constructs, when used, can tend to result in non-portable code. But, they are widely used in existing Fortran code in ways that often are quite portable. Therefore, they are enabled by default. @node Ugly Integer Conversions @subsection Ugly Integer Conversions The constructs enabled via @option{-fugly-logint} are: @itemize @bullet @item Automatic conversion between @code{INTEGER} and @code{LOGICAL} as dictated by context (typically implies nonportable dependencies on how a particular implementation encodes @code{.TRUE.} and @code{.FALSE.}). @item Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO} statements. @end itemize The above constructs are disabled by default because use of them tends to lead to non-portable code. Even existing Fortran code that uses that often turns out to be non-portable, if not outright buggy. Some of this is due to differences among implementations as far as how @code{.TRUE.} and @code{.FALSE.} are encoded as @code{INTEGER} values---Fortran code that assumes a particular coding is likely to use one of the above constructs, and is also likely to not work correctly on implementations using different encodings. @xref{Equivalence Versus Equality}, for more information. @node Ugly Assigned Labels @subsection Ugly Assigned Labels @cindex ASSIGN statement @cindex statements, ASSIGN @cindex assigned labels @cindex pointers The @option{-fugly-assign} option forces @command{g77} to use the same storage for assigned labels as it would for a normal assignment to the same variable. For example, consider the following code fragment: @example I = 3 ASSIGN 10 TO I @end example @noindent Normally, for portability and improved diagnostics, @command{g77} reserves distinct storage for a ``sibling'' of @samp{I}, used only for @code{ASSIGN} statements to that variable (along with the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements that reference the variable). However, some code (that violates the ANSI FORTRAN 77 standard) attempts to copy assigned labels among variables involved with @code{ASSIGN} statements, as in: @example ASSIGN 10 TO I ISTATE(5) = I @dots{} J = ISTATE(ICUR) GOTO J @end example @noindent Such code doesn't work under @command{g77} unless @option{-fugly-assign} is specified on the command-line, ensuring that the value of @code{I} referenced in the second line is whatever value @command{g77} uses to designate statement label @samp{10}, so the value may be copied into the @samp{ISTATE} array, later retrieved into a variable of the appropriate type (@samp{J}), and used as the target of an assigned-@code{GOTO} statement. @emph{Note:} To avoid subtle program bugs, when @option{-fugly-assign} is specified, @command{g77} requires the type of variables specified in assigned-label contexts @emph{must} be the same type returned by @code{%LOC()}. On many systems, this type is effectively the same as @code{INTEGER(KIND=1)}, while, on others, it is effectively the same as @code{INTEGER(KIND=2)}. Do @emph{not} depend on @command{g77} actually writing valid pointers to these variables, however. While @command{g77} currently chooses that implementation, it might be changed in the future. @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)}, for implementation details on assigned-statement labels. @node Compiler @chapter The GNU Fortran Compiler The GNU Fortran compiler, @command{g77}, supports programs written in the GNU Fortran language and in some other dialects of Fortran. Some aspects of how @command{g77} works are universal regardless of dialect, and yet are not properly part of the GNU Fortran language itself. These are described below. @emph{Note: This portion of the documentation definitely needs a lot of work!} @menu * Compiler Limits:: * Run-time Environment Limits:: * Compiler Types:: * Compiler Constants:: * Compiler Intrinsics:: @end menu @node Compiler Limits @section Compiler Limits @cindex limits, compiler @cindex compiler limits @command{g77}, as with GNU tools in general, imposes few arbitrary restrictions on lengths of identifiers, number of continuation lines, number of external symbols in a program, and so on. @cindex options, -Nl @cindex -Nl option @cindex options, -Nx @cindex -Nx option @cindex limits, continuation lines @cindex limits, lengths of names For example, some other Fortran compiler have an option (such as @option{-Nl@var{x}}) to increase the limit on the number of continuation lines. Also, some Fortran compilation systems have an option (such as @option{-Nx@var{x}}) to increase the limit on the number of external symbols. @command{g77}, @command{gcc}, and GNU @command{ld} (the GNU linker) have no equivalent options, since they do not impose arbitrary limits in these areas. @cindex rank, maximum @cindex maximum rank @cindex number of dimensions, maximum @cindex maximum number of dimensions @cindex limits, rank @cindex limits, array dimensions @command{g77} does currently limit the number of dimensions in an array to the same degree as do the Fortran standards---seven (7). This restriction might be lifted in a future version. @node Run-time Environment Limits @section Run-time Environment Limits @cindex limits, run-time library @cindex wraparound As a portable Fortran implementation, @command{g77} offers its users direct access to, and otherwise depends upon, the underlying facilities of the system used to build @command{g77}, the system on which @command{g77} itself is used to compile programs, and the system on which the @command{g77}-compiled program is actually run. (For most users, the three systems are of the same type---combination of operating environment and hardware---often the same physical system.) The run-time environment for a particular system inevitably imposes some limits on a program's use of various system facilities. These limits vary from system to system. Even when such limits might be well beyond the possibility of being encountered on a particular system, the @command{g77} run-time environment has certain built-in limits, usually, but not always, stemming from intrinsics with inherently limited interfaces. Currently, the @command{g77} run-time environment does not generally offer a less-limiting environment by augmenting the underlying system's own environment. Therefore, code written in the GNU Fortran language, while syntactically and semantically portable, might nevertheless make non-portable assumptions about the run-time environment---assumptions that prove to be false for some particular environments. The GNU Fortran language, the @command{g77} compiler and run-time environment, and the @command{g77} documentation do not yet offer comprehensive portable work-arounds for such limits, though programmers should be able to find their own in specific instances. Not all of the limitations are described in this document. Some of the known limitations include: @menu * Timer Wraparounds:: * Year 2000 (Y2K) Problems:: * Array Size:: * Character-variable Length:: * Year 10000 (Y10K) Problems:: @end menu @node Timer Wraparounds @subsection Timer Wraparounds Intrinsics that return values computed from system timers, whether elapsed (wall-clock) timers, process CPU timers, or other kinds of timers, are prone to experiencing wrap-around errors (or returning wrapped-around values from successive calls) due to insufficient ranges offered by the underlying system's timers. @cindex negative time @cindex short time @cindex long time Some of the symptoms of such behaviors include apparently negative time being computed for a duration, an extremely short amount of time being computed for a long duration, and an extremely long amount of time being computed for a short duration. See the following for intrinsics known to have potential problems in these areas on at least some systems: @ref{CPU_Time Intrinsic}, @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)}, @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)}, @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic}, @ref{Secnds Intrinsic}, @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)}, @ref{System_Clock Intrinsic}, @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)}, @ref{Time8 Intrinsic}. @node Year 2000 (Y2K) Problems @subsection Year 2000 (Y2K) Problems @cindex Y2K compliance @cindex Year 2000 compliance While the @command{g77} compiler itself is believed to be Year-2000 (Y2K) compliant, some intrinsics are not, and, potentially, some underlying systems are not, perhaps rendering some Y2K-compliant intrinsics non-compliant when used on those particular systems. Fortran code that uses non-Y2K-compliant intrinsics (listed below) is, itself, almost certainly not compliant, and should be modified to use Y2K-compliant intrinsics instead. Fortran code that uses no non-Y2K-compliant intrinsics, but which currently is running on a non-Y2K-compliant system, can be made more Y2K compliant by compiling and linking it for use on a new Y2K-compliant system, such as a new version of an old, non-Y2K-compliant, system. Currently, information on Y2K and related issues is being maintained at @uref{http://www.gnu.org/software/year2000-list.html}. See the following for intrinsics known to have potential problems in these areas on at least some systems: @ref{Date Intrinsic}, @ref{IDate Intrinsic (VXT)}. @cindex y2kbuggy @cindex date_y2kbuggy_0 @cindex vxtidate_y2kbuggy_0 @cindex G77_date_y2kbuggy_0 @cindex G77_vxtidate_y2kbuggy_0 The @code{libg2c} library shipped with any @command{g77} that warns about invocation of a non-Y2K-compliant intrinsic has renamed the @code{EXTERNAL} procedure names of those intrinsics. This is done so that the @code{libg2c} implementations of these intrinsics cannot be directly linked to as @code{EXTERNAL} names (which normally would avoid the non-Y2K-intrinsic warning). The renamed forms of the @code{EXTERNAL} names of these renamed procedures may be linked to by appending the string @samp{_y2kbug} to the name of the procedure in the source code. For example: @smallexample CHARACTER*20 STR INTEGER YY, MM, DD EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG CALL DATE_Y2KBUG (STR) CALL VXTIDATE_Y2KBUG (MM, DD, YY) @end smallexample (Note that the @code{EXTERNAL} statement is not actually required, since the modified names are not recognized as intrinsics by the current version of @command{g77}. But it is shown in this specific case, for purposes of illustration.) The renaming of @code{EXTERNAL} procedure names of these intrinsics causes unresolved references at link time. For example, @samp{EXTERNAL DATE; CALL DATE(STR)} is normally compiled by @command{g77} as, in C, @samp{date_(&str, 20);}. This, in turn, links to the @code{date_} procedure in the @code{libE77} portion of @code{libg2c}, which purposely calls a nonexistent procedure named @code{G77_date_y2kbuggy_0}. The resulting link-time error is designed, via this name, to encourage the programmer to look up the index entries to this portion of the @command{g77} documentation. Generally, we recommend that the @code{EXTERNAL} method of invoking procedures in @code{libg2c} @emph{not} be used. When used, some of the correctness checking normally performed by @command{g77} is skipped. In particular, it is probably better to use the @code{INTRINSIC} method of invoking non-Y2K-compliant procedures, so anyone compiling the code can quickly notice the potential Y2K problems (via the warnings printing by @command{g77}) without having to even look at the code itself. If there are problems linking @code{libg2c} to code compiled by @command{g77} that involve the string @samp{y2kbug}, and these are not explained above, that probably indicates that a version of @code{libg2c} older than @command{g77} is being linked to, or that the new library is being linked to code compiled by an older version of @command{g77}. That's because, as of the version that warns about non-Y2K-compliant intrinsic invocation, @command{g77} references the @code{libg2c} implementations of those intrinsics using new names, containing the string @samp{y2kbug}. So, linking newly-compiled code (invoking one of the intrinsics in question) to an old library might yield an unresolved reference to @code{G77_date_y2kbug_0}. (The old library calls it @code{G77_date_0}.) Similarly, linking previously-compiled code to a new library might yield an unresolved reference to @code{G77_vxtidate_0}. (The new library calls it @code{G77_vxtidate_y2kbug_0}.) The proper fix for the above problems is to obtain the latest release of @command{g77} and related products (including @code{libg2c}) and install them on all systems, then recompile, relink, and install (as appropriate) all existing Fortran programs. (Normally, this sort of renaming is steadfastly avoided. In this case, however, it seems more important to highlight potential Y2K problems than to ease the transition of potentially non-Y2K-compliant code to new versions of @command{g77} and @code{libg2c}.) @node Array Size @subsection Array Size @cindex limits, array size @cindex array size Currently, @command{g77} uses the default @code{INTEGER} type for array indexes, which limits the sizes of single-dimension arrays on systems offering a larger address space than can be addressed by that type. (That @command{g77} puts all arrays in memory could be considered another limitation---it could use large temporary files---but that decision is left to the programmer as an implementation choice by most Fortran implementations.) @c ??? Investigate this, to offer a more clear statement @c than the following paragraphs do. -- burley 1999-02-17 It is not yet clear whether this limitation never, sometimes, or always applies to the sizes of multiple-dimension arrays as a whole. For example, on a system with 64-bit addresses and 32-bit default @code{INTEGER}, an array with a size greater than can be addressed by a 32-bit offset can be declared using multiple dimensions. Such an array is therefore larger than a single-dimension array can be, on the same system. @cindex limits, multi-dimension arrays @cindex multi-dimension arrays @cindex arrays, dimensioning Whether large multiple-dimension arrays are reliably supported depends mostly on the @command{gcc} back end (code generator) used by @command{g77}, and has not yet been fully investigated. @node Character-variable Length @subsection Character-variable Length @cindex limits, on character-variable length @cindex character-variable length Currently, @command{g77} uses the default @code{INTEGER} type for the lengths of @code{CHARACTER} variables and array elements. This means that, for example, a system with a 64-bit address space and a 32-bit default @code{INTEGER} type does not, under @command{g77}, support a @code{CHARACTER*@var{n}} declaration where @var{n} is greater than 2147483647. @node Year 10000 (Y10K) Problems @subsection Year 10000 (Y10K) Problems @cindex Y10K compliance @cindex Year 10000 compliance Most intrinsics returning, or computing values based on, date information are prone to Year-10000 (Y10K) problems, due to supporting only 4 digits for the year. See the following for examples: @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)}, @ref{IDate Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)}, @ref{Date_and_Time Intrinsic}. @node Compiler Types @section Compiler Types @cindex types, of data @cindex data types Fortran implementations have a fair amount of freedom given them by the standard as far as how much storage space is used and how much precision and range is offered by the various types such as @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)}, @code{COMPLEX(KIND=1)}, and @code{CHARACTER}. Further, many compilers offer so-called @samp{*@var{n}} notation, but the interpretation of @var{n} varies across compilers and target architectures. The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)}, and @code{REAL(KIND=1)} occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)} and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}. Further, it requires that @code{COMPLEX(KIND=1)} entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is storage-associated (such as via @code{EQUIVALENCE}) with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)} corresponds to the real element and @samp{R(2)} to the imaginary element of the @code{COMPLEX(KIND=1)} variable. (Few requirements as to precision or ranges of any of these are placed on the implementation, nor is the relationship of storage sizes of these types to the @code{CHARACTER} type specified, by the standard.) @command{g77} follows the above requirements, warning when compiling a program requires placement of items in memory that contradict the requirements of the target architecture. (For example, a program can require placement of a @code{REAL(KIND=2)} on a boundary that is not an even multiple of its size, but still an even multiple of the size of a @code{REAL(KIND=1)} variable. On some target architectures, using the canonical mapping of Fortran types to underlying architectural types, such placement is prohibited by the machine definition or the Application Binary Interface (ABI) in force for the configuration defined for building @command{gcc} and @command{g77}. @command{g77} warns about such situations when it encounters them.) @command{g77} follows consistent rules for configuring the mapping between Fortran types, including the @samp{*@var{n}} notation, and the underlying architectural types as accessed by a similarly-configured applicable version of the @command{gcc} compiler. These rules offer a widely portable, consistent Fortran/C environment, although they might well conflict with the expectations of users of Fortran compilers designed and written for particular architectures. These rules are based on the configuration that is in force for the version of @command{gcc} built in the same release as @command{g77} (and which was therefore used to build both the @command{g77} compiler components and the @code{libg2c} run-time library): @table @code @cindex REAL(KIND=1) type @cindex types, REAL(KIND=1) @item REAL(KIND=1) Same as @code{float} type. @cindex REAL(KIND=2) type @cindex types, REAL(KIND=2) @item REAL(KIND=2) Same as whatever floating-point type that is twice the size of a @code{float}---usually, this is a @code{double}. @cindex INTEGER(KIND=1) type @cindex types, INTEGER(KIND=1) @item INTEGER(KIND=1) Same as an integral type that is occupies the same amount of memory storage as @code{float}---usually, this is either an @code{int} or a @code{long int}. @cindex LOGICAL(KIND=1) type @cindex types, LOGICAL(KIND=1) @item LOGICAL(KIND=1) Same @command{gcc} type as @code{INTEGER(KIND=1)}. @cindex INTEGER(KIND=2) type @cindex types, INTEGER(KIND=2) @item INTEGER(KIND=2) Twice the size, and usually nearly twice the range, as @code{INTEGER(KIND=1)}---usually, this is either a @code{long int} or a @code{long long int}. @cindex LOGICAL(KIND=2) type @cindex types, LOGICAL(KIND=2) @item LOGICAL(KIND=2) Same @command{gcc} type as @code{INTEGER(KIND=2)}. @cindex INTEGER(KIND=3) type @cindex types, INTEGER(KIND=3) @item INTEGER(KIND=3) Same @command{gcc} type as signed @code{char}. @cindex LOGICAL(KIND=3) type @cindex types, LOGICAL(KIND=3) @item LOGICAL(KIND=3) Same @command{gcc} type as @code{INTEGER(KIND=3)}. @cindex INTEGER(KIND=6) type @cindex types, INTEGER(KIND=6) @item INTEGER(KIND=6) Twice the size, and usually nearly twice the range, as @code{INTEGER(KIND=3)}---usually, this is a @code{short}. @cindex LOGICAL(KIND=6) type @cindex types, LOGICAL(KIND=6) @item LOGICAL(KIND=6) Same @command{gcc} type as @code{INTEGER(KIND=6)}. @cindex COMPLEX(KIND=1) type @cindex types, COMPLEX(KIND=1) @item COMPLEX(KIND=1) Two @code{REAL(KIND=1)} scalars (one for the real part followed by one for the imaginary part). @cindex COMPLEX(KIND=2) type @cindex types, COMPLEX(KIND=2) @item COMPLEX(KIND=2) Two @code{REAL(KIND=2)} scalars. @cindex *@var{n} notation @item @var{numeric-type}*@var{n} (Where @var{numeric-type} is any type other than @code{CHARACTER}.) Same as whatever @command{gcc} type occupies @var{n} times the storage space of a @command{gcc} @code{char} item. @cindex DOUBLE PRECISION type @cindex types, DOUBLE PRECISION @item DOUBLE PRECISION Same as @code{REAL(KIND=2)}. @cindex DOUBLE COMPLEX type @cindex types, DOUBLE COMPLEX @item DOUBLE COMPLEX Same as @code{COMPLEX(KIND=2)}. @end table Note that the above are proposed correspondences and might change in future versions of @command{g77}---avoid writing code depending on them. Other types supported by @command{g77} are derived from gcc types such as @code{char}, @code{short}, @code{int}, @code{long int}, @code{long long int}, @code{long double}, and so on. That is, whatever types @command{gcc} already supports, @command{g77} supports now or probably will support in a future version. The rules for the @samp{@var{numeric-type}*@var{n}} notation apply to these types, and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be assigned in a way that encourages clarity, consistency, and portability. @node Compiler Constants @section Compiler Constants @cindex constants @cindex types, constants @command{g77} strictly assigns types to @emph{all} constants not documented as ``typeless'' (typeless constants including @samp{'1'Z}, for example). Many other Fortran compilers attempt to assign types to typed constants based on their context. This results in hard-to-find bugs, nonportable code, and is not in the spirit (though it strictly follows the letter) of the 77 and 90 standards. @command{g77} might offer, in a future release, explicit constructs by which a wider variety of typeless constants may be specified, and/or user-requested warnings indicating places where @command{g77} might differ from how other compilers assign types to constants. @xref{Context-Sensitive Constants}, for more information on this issue. @node Compiler Intrinsics @section Compiler Intrinsics @command{g77} offers an ever-widening set of intrinsics. Currently these all are procedures (functions and subroutines). Some of these intrinsics are unimplemented, but their names reserved to reduce future problems with existing code as they are implemented. Others are implemented as part of the GNU Fortran language, while yet others are provided for compatibility with other dialects of Fortran but are not part of the GNU Fortran language. To manage these distinctions, @command{g77} provides intrinsic @emph{groups}, a facility that is simply an extension of the intrinsic groups provided by the GNU Fortran language. @menu * Intrinsic Groups:: How intrinsics are grouped for easy management. * Other Intrinsics:: Intrinsics other than those in the GNU Fortran language. @end menu @node Intrinsic Groups @subsection Intrinsic Groups @cindex groups of intrinsics @cindex intrinsics, groups A given specific intrinsic belongs in one or more groups. Each group is deleted, disabled, hidden, or enabled by default or a command-line option. The meaning of each term follows. @table @b @cindex deleted intrinsics @cindex intrinsics, deleted @item Deleted No intrinsics are recognized as belonging to that group. @cindex disabled intrinsics @cindex intrinsics, disabled @item Disabled Intrinsics are recognized as belonging to the group, but references to them (other than via the @code{INTRINSIC} statement) are disallowed through that group. @cindex hidden intrinsics @cindex intrinsics, hidden @item Hidden Intrinsics in that group are recognized and enabled (if implemented) @emph{only} if the first mention of the actual name of an intrinsic in a program unit is in an @code{INTRINSIC} statement. @cindex enabled intrinsics @cindex intrinsics, enabled @item Enabled Intrinsics in that group are recognized and enabled (if implemented). @end table The distinction between deleting and disabling a group is illustrated by the following example. Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}. If group @samp{FGR} is deleted, the following program unit will successfully compile, because @samp{FOO()} will be seen as a reference to an external function named @samp{FOO}: @example PRINT *, FOO() END @end example @noindent If group @samp{FGR} is disabled, compiling the above program will produce diagnostics, either because the @samp{FOO} intrinsic is improperly invoked or, if properly invoked, it is not enabled. To change the above program so it references an external function @samp{FOO} instead of the disabled @samp{FOO} intrinsic, add the following line to the top: @example EXTERNAL FOO @end example @noindent So, deleting a group tells @command{g77} to pretend as though the intrinsics in that group do not exist at all, whereas disabling it tells @command{g77} to recognize them as (disabled) intrinsics in intrinsic-like contexts. Hiding a group is like enabling it, but the intrinsic must be first named in an @code{INTRINSIC} statement to be considered a reference to the intrinsic rather than to an external procedure. This might be the ``safest'' way to treat a new group of intrinsics when compiling old code, because it allows the old code to be generally written as if those new intrinsics never existed, but to be changed to use them by inserting @code{INTRINSIC} statements in the appropriate places. However, it should be the goal of development to use @code{EXTERNAL} for all names of external procedures that might be intrinsic names. If an intrinsic is in more than one group, it is enabled if any of its containing groups are enabled; if not so enabled, it is hidden if any of its containing groups are hidden; if not so hidden, it is disabled if any of its containing groups are disabled; if not so disabled, it is deleted. This extra complication is necessary because some intrinsics, such as @code{IBITS}, belong to more than one group, and hence should be enabled if any of the groups to which they belong are enabled, and so on. The groups are: @cindex intrinsics, groups of @cindex groups of intrinsics @table @code @cindex @code{badu77} intrinsics group @item badu77 UNIX intrinsics having inappropriate forms (usually functions that have intended side effects). @cindex @code{gnu} intrinsics group @item gnu Intrinsics the GNU Fortran language supports that are extensions to the Fortran standards (77 and 90). @cindex @command{f2c} intrinsics group @item f2c Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}. @cindex @code{f90} intrinsics group @item f90 Fortran 90 intrinsics. @cindex @code{mil} intrinsics group @item mil MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on). @cindex @code{mil} intrinsics group @item unix UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on). @cindex @code{mil} intrinsics group @item vxt VAX/VMS FORTRAN (current as of v4) intrinsics. @end table @node Other Intrinsics @subsection Other Intrinsics @cindex intrinsics, others @cindex other intrinsics @command{g77} supports intrinsics other than those in the GNU Fortran language proper. This set of intrinsics is described below. @ifinfo (Note that the empty lines appearing in the menu below are not intentional---they result from a bug in the @code{makeinfo} program.) @end ifinfo @c The actual documentation for intrinsics comes from @c intdoc.texi, which in turn is automatically generated @c from the internal g77 tables in intrin.def _and_ the @c largely hand-written text in intdoc.h. So, if you want @c to change or add to existing documentation on intrinsics, @c you probably want to edit intdoc.h. @c @clear familyF77 @clear familyGNU @clear familyASC @clear familyMIL @clear familyF90 @set familyVXT @set familyFVZ @clear familyF2C @clear familyF2U @set familyBADU77 @include intdoc.texi @node Other Compilers @chapter Other Compilers An individual Fortran source file can be compiled to an object (@file{*.o}) file instead of to the final program executable. This allows several portions of a program to be compiled at different times and linked together whenever a new version of the program is needed. However, it introduces the issue of @dfn{object compatibility} across the various object files (and libraries, or @file{*.a} files) that are linked together to produce any particular executable file. Object compatibility is an issue when combining, in one program, Fortran code compiled by more than one compiler (or more than one configuration of a compiler). If the compilers disagree on how to transform the names of procedures, there will normally be errors when linking such programs. Worse, if the compilers agree on naming, but disagree on issues like how to pass parameters, return arguments, and lay out @code{COMMON} areas, the earliest detected errors might be the incorrect results produced by the program (and that assumes these errors are detected, which is not always the case). Normally, @command{g77} generates code that is object-compatible with code generated by a version of @command{f2c} configured (with, for example, @file{f2c.h} definitions) to be generally compatible with @command{g77} as built by @command{gcc}. (Normally, @command{f2c} will, by default, conform to the appropriate configuration, but it is possible that older or perhaps even newer versions of @command{f2c}, or versions having certain configuration changes to @command{f2c} internals, will produce object files that are incompatible with @command{g77}.) For example, a Fortran string subroutine argument will become two arguments on the C side: a @code{char *} and an @code{int} length. Much of this compatibility results from the fact that @command{g77} uses the same run-time library, @code{libf2c}, used by @command{f2c}, though @command{g77} gives its version the name @code{libg2c} so as to avoid conflicts when linking, installing them in the same directories, and so on. Other compilers might or might not generate code that is object-compatible with @code{libg2c} and current @command{g77}, and some might offer such compatibility only when explicitly selected via a command-line option to the compiler. @emph{Note: This portion of the documentation definitely needs a lot of work!} @menu * Dropping f2c Compatibility:: When speed is more important. * Compilers Other Than f2c:: Interoperation with code from other compilers. @end menu @node Dropping f2c Compatibility @section Dropping @command{f2c} Compatibility Specifying @option{-fno-f2c} allows @command{g77} to generate, in some cases, faster code, by not needing to allow to the possibility of linking with code compiled by @command{f2c}. For example, this affects how @code{REAL(KIND=1)}, @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called. With @option{-fno-f2c}, they are compiled as returning the appropriate @command{gcc} type (@code{float}, @code{__complex__ float}, @code{__complex__ double}, in many configurations). With @option{-ff2c} in force, they are compiled differently (with perhaps slower run-time performance) to accommodate the restrictions inherent in @command{f2c}'s use of K&R C as an intermediate language---@code{REAL(KIND=1)} functions return C's @code{double} type, while @code{COMPLEX} functions return @code{void} and use an extra argument pointing to a place for the functions to return their values. It is possible that, in some cases, leaving @option{-ff2c} in force might produce faster code than using @option{-fno-f2c}. Feel free to experiment, but remember to experiment with changing the way @emph{entire programs and their Fortran libraries are compiled} at a time, since this sort of experimentation affects the interface of code generated for a Fortran source file---that is, it affects object compatibility. Note that @command{f2c} compatibility is a fairly static target to achieve, though not necessarily perfectly so, since, like @command{g77}, it is still being improved. However, specifying @option{-fno-f2c} causes @command{g77} to generate code that will probably be incompatible with code generated by future versions of @command{g77} when the same option is in force. You should make sure you are always able to recompile complete programs from source code when upgrading to new versions of @command{g77} or @command{f2c}, especially when using options such as @option{-fno-f2c}. Therefore, if you are using @command{g77} to compile libraries and other object files for possible future use and you don't want to require recompilation for future use with subsequent versions of @command{g77}, you might want to stick with @command{f2c} compatibility for now, and carefully watch for any announcements about changes to the @command{f2c}/@code{libf2c} interface that might affect existing programs (thus requiring recompilation). It is probable that a future version of @command{g77} will not, by default, generate object files compatible with @command{f2c}, and that version probably would no longer use @code{libf2c}. If you expect to depend on this compatibility in the long term, use the options @samp{-ff2c -ff2c-library} when compiling all of the applicable code. This should cause future versions of @command{g77} either to produce compatible code (at the expense of the availability of some features and performance), or at the very least, to produce diagnostics. (The library @command{g77} produces will no longer be named @file{libg2c} when it is no longer generally compatible with @file{libf2c}. It will likely be referred to, and, if installed as a distinct library, named @code{libg77}, or some other as-yet-unused name.) @node Compilers Other Than f2c @section Compilers Other Than @command{f2c} On systems with Fortran compilers other than @command{f2c} and @command{g77}, code compiled by @command{g77} is not expected to work well with code compiled by the native compiler. (This is true for @command{f2c}-compiled objects as well.) Libraries compiled with the native compiler probably will have to be recompiled with @command{g77} to be used with @command{g77}-compiled code. Reasons for such incompatibilities include: @itemize @bullet @item There might be differences in the way names of Fortran procedures are translated for use in the system's object-file format. For example, the statement @samp{CALL FOO} might be compiled by @command{g77} to call a procedure the linker @command{ld} sees given the name @samp{_foo_}, while the apparently corresponding statement @samp{SUBROUTINE FOO} might be compiled by the native compiler to define the linker-visible name @samp{_foo}, or @samp{_FOO_}, and so on. @item There might be subtle type mismatches which cause subroutine arguments and function return values to get corrupted. This is why simply getting @command{g77} to transform procedure names the same way a native compiler does is not usually a good idea---unless some effort has been made to ensure that, aside from the way the two compilers transform procedure names, everything else about the way they generate code for procedure interfaces is identical. @item Native compilers use libraries of private I/O routines which will not be available at link time unless you have the native compiler---and you would have to explicitly ask for them. For example, on the Sun you would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link command. @end itemize @node Other Languages @chapter Other Languages @emph{Note: This portion of the documentation definitely needs a lot of work!} @menu * Interoperating with C and C++:: @end menu @node Interoperating with C and C++ @section Tools and advice for interoperating with C and C++ @cindex C, linking with @cindex C++, linking with @cindex linking with C The following discussion assumes that you are running @command{g77} in @command{f2c} compatibility mode, i.e.@: not using @option{-fno-f2c}. It provides some advice about quick and simple techniques for linking Fortran and C (or C++), the most common requirement. For the full story consult the description of code generation. @xref{Debugging and Interfacing}. When linking Fortran and C, it's usually best to use @command{g77} to do the linking so that the correct libraries are included (including the maths one). If you're linking with C++ you will want to add @option{-lstdc++}, @option{-lg++} or whatever. If you need to use another driver program (or @command{ld} directly), you can find out what linkage options @command{g77} passes by running @samp{g77 -v}. @menu * C Interfacing Tools:: * C Access to Type Information:: * f2c Skeletons and Prototypes:: * C++ Considerations:: * Startup Code:: @end menu @node C Interfacing Tools @subsection C Interfacing Tools @pindex f2c @cindex cfortran.h @cindex Netlib Even if you don't actually use it as a compiler, @command{f2c} from @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're interfacing (linking) Fortran and C@. @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}. To use @command{f2c} for this purpose you only need retrieve and build the @file{src} directory from the distribution, consult the @file{README} instructions there for machine-specifics, and install the @command{f2c} program on your path. Something else that might be useful is @samp{cfortran.h} from @uref{ftp://zebra.desy.de/cfortran}. This is a fairly general tool which can be used to generate interfaces for calling in both directions between Fortran and C@. It can be used in @command{f2c} mode with @command{g77}---consult its documentation for details. @node C Access to Type Information @subsection Accessing Type Information in C @cindex types, Fortran/C Generally, C code written to link with @command{g77} code---calling and/or being called from Fortran---should @samp{#include } to define the C versions of the Fortran types. Don't assume Fortran @code{INTEGER} types correspond to C @code{int}s, for instance; instead, declare them as @code{integer}, a type defined by @file{g2c.h}. @file{g2c.h} is installed where @command{gcc} will find it by default, assuming you use a copy of @command{gcc} compatible with @command{g77}, probably built at the same time as @command{g77}. @node f2c Skeletons and Prototypes @subsection Generating Skeletons and Prototypes with @command{f2c} @pindex f2c @cindex -fno-second-underscore A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to interface with an existing library---is to write a file (named, for example, @file{fred.f}) of dummy Fortran skeletons comprising just the declaration of the routine(s) and dummy arguments plus @code{END} statements. Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c} into which you can edit useful code, confident the calling sequence is correct, at least. (There are some errors otherwise commonly made in generating C interfaces with @command{f2c} conventions, such as not using @code{doublereal} as the return type of a @code{REAL} @code{FUNCTION}.) @pindex ftnchek @command{f2c} also can help with calling Fortran from C, using its @option{-P} option to generate C prototypes appropriate for calling the Fortran.@footnote{The files generated like this can also be used for inter-unit consistency checking of dummy and actual arguments, although the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran} or @uref{ftp://ftp.dsm.fordham.edu} is probably better for this purpose.} If the Fortran code containing any routines to be called from C is in file @file{joe.f}, use the command @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing prototype information. @code{#include} this in the C which has to call the Fortran routines to make sure you get it right. @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences between the way Fortran (including compilers like @command{g77}) and C handle arrays. @node C++ Considerations @subsection C++ Considerations @cindex C++ @command{f2c} can be used to generate suitable code for compilation with a C++ system using the @option{-C++} option. The important thing about linking @command{g77}-compiled code with C++ is that the prototypes for the @command{g77} routines must specify C linkage to avoid name mangling. So, use an @samp{extern "C"} declaration. @command{f2c}'s @option{-C++} option will take care of this when generating skeletons or prototype files as above, and also avoid clashes with C++ reserved words in addition to those in C@. @node Startup Code @subsection Startup Code @cindex startup code @cindex run-time, initialization @cindex initialization, run-time Unlike with some runtime systems, it shouldn't be necessary (unless there are bugs) to use a Fortran main program unit to ensure the runtime---specifically the I/O system---is initialized. However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC}, either the @code{main} routine from the @file{libg2c} library must be used, or the @code{f_setarg} routine (new as of @code{egcs} version 1.1 and @command{g77} version 0.5.23) must be called with the appropriate @code{argc} and @code{argv} arguments prior to the program calling @code{GETARG} or @code{IARGC}. To provide more flexibility for mixed-language programming involving @command{g77} while allowing for shared libraries, as of @code{egcs} version 1.1 and @command{g77} version 0.5.23, @command{g77}'s @code{main} routine in @code{libg2c} does the following, in order: @enumerate @item Calls @code{f_setarg} with the incoming @code{argc} and @code{argv} arguments, in the same order as for @code{main} itself. This sets up the command-line environment for @code{GETARG} and @code{IARGC}. @item Calls @code{f_setsig} (with no arguments). This sets up the signaling and exception environment. @item Calls @code{f_init} (with no arguments). This initializes the I/O environment, though that should not be necessary, as all I/O functions in @code{libf2c} are believed to call @code{f_init} automatically, if necessary. (A future version of @command{g77} might skip this explicit step, to speed up normal exit of a program.) @item Arranges for @code{f_exit} to be called (with no arguments) when the program exits. This ensures that the I/O environment is properly shut down before the program exits normally. Otherwise, output buffers might not be fully flushed, scratch files might not be deleted, and so on. The simple way @code{main} does this is to call @code{f_exit} itself after calling @code{MAIN__} (in the next step). However, this does not catch the cases where the program might call @code{exit} directly, instead of using the @code{EXIT} intrinsic (implemented as @code{exit_} in @code{libf2c}). So, @code{main} attempts to use the operating environment's @code{onexit} or @code{atexit} facility, if available, to cause @code{f_exit} to be called automatically upon any invocation of @code{exit}. @item Calls @code{MAIN__} (with no arguments). This starts executing the Fortran main program unit for the application. (Both @command{g77} and @command{f2c} currently compile a main program unit so that its global name is @code{MAIN__}.) @item If no @code{onexit} or @code{atexit} is provided by the system, calls @code{f_exit}. @item Calls @code{exit} with a zero argument, to signal a successful program termination. @item Returns a zero value to the caller, to signal a successful program termination, in case @code{exit} doesn't exit on the system. @end enumerate All of the above names are C @code{extern} names, i.e.@: not mangled. When using the @code{main} procedure provided by @command{g77} without a Fortran main program unit, you need to provide @code{MAIN__} as the entry point for your C code. (Make sure you link the object file that defines that entry point with the rest of your program.) To provide your own @code{main} procedure in place of @command{g77}'s, make sure you specify the object file defining that procedure @emph{before} @option{-lg2c} on the @command{g77} command line. Since the @option{-lg2c} option is implicitly provided, this is usually straightforward. (Use the @option{--verbose} option to see how and where @command{g77} implicitly adds @option{-lg2c} in a command line that will link the program. Feel free to specify @option{-lg2c} explicitly, as appropriate.) However, when providing your own @code{main}, make sure you perform the appropriate tasks in the appropriate order. For example, if your @code{main} does not call @code{f_setarg}, make sure the rest of your application does not call @code{GETARG} or @code{IARGC}. And, if your @code{main} fails to ensure that @code{f_exit} is called upon program exit, some files might end up incompletely written, some scratch files might be left lying around, and some existing files being written might be left with old data not properly truncated at the end. Note that, generally, the @command{g77} operating environment does not depend on a procedure named @code{MAIN__} actually being called prior to any other @command{g77}-compiled code. That is, @code{MAIN__} does not, itself, set up any important operating-environment characteristics upon which other code might depend. This might change in future versions of @command{g77}, with appropriate notification in the release notes. For more information, consult the source code for the above routines. These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c}, @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}. Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77} uses to open-code (inline) references to @code{IARGC}. @node Debugging and Interfacing @chapter Debugging and Interfacing @cindex debugging @cindex interfacing @cindex calling C routines @cindex C routines calling Fortran @cindex f2c compatibility GNU Fortran currently generates code that is object-compatible with the @command{f2c} converter. Also, it avoids limitations in the current GBE, such as the inability to generate a procedure with multiple entry points, by generating code that is structured differently (in terms of procedure names, scopes, arguments, and so on) than might be expected. As a result, writing code in other languages that calls on, is called by, or shares in-memory data with @command{g77}-compiled code generally requires some understanding of the way @command{g77} compiles code for various constructs. Similarly, using a debugger to debug @command{g77}-compiled code, even if that debugger supports native Fortran debugging, generally requires this sort of information. This section describes some of the basic information on how @command{g77} compiles code for constructs involving interfaces to other languages and to debuggers. @emph{Caution:} Much or all of this information pertains to only the current release of @command{g77}, sometimes even to using certain compiler options with @command{g77} (such as @option{-fno-f2c}). Do not write code that depends on this information without clearly marking said code as nonportable and subject to review for every new release of @command{g77}. This information is provided primarily to make debugging of code generated by this particular release of @command{g77} easier for the user, and partly to make writing (generally nonportable) interface code easier. Both of these activities require tracking changes in new version of @command{g77} as they are installed, because new versions can change the behaviors described in this section. @menu * Main Program Unit:: How @command{g77} compiles a main program unit. * Procedures:: How @command{g77} constructs parameter lists for procedures. * Functions:: Functions returning floating-point or character data. * Names:: Naming of user-defined variables, procedures, etc. * Common Blocks:: Accessing common variables while debugging. * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging. * Complex Variables:: How @command{g77} performs complex arithmetic. * Arrays:: Dealing with (possibly multi-dimensional) arrays. * Adjustable Arrays:: Special consideration for adjustable arrays. * Alternate Entry Points:: How @command{g77} implements alternate @code{ENTRY}. * Alternate Returns:: How @command{g77} handles alternate returns. * Assigned Statement Labels:: How @command{g77} handles @code{ASSIGN}. * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values. @end menu @node Main Program Unit @section Main Program Unit (PROGRAM) @cindex PROGRAM statement @cindex statements, PROGRAM When @command{g77} compiles a main program unit, it gives it the public procedure name @code{MAIN__}. The @code{libg2c} library has the actual @code{main()} procedure as is typical of C-based environments, and it is this procedure that performs some initial start-up activity and then calls @code{MAIN__}. Generally, @command{g77} and @code{libg2c} are designed so that you need not include a main program unit written in Fortran in your program---it can be written in C or some other language. Especially for I/O handling, this is the case, although @command{g77} version 0.5.16 includes a bug fix for @code{libg2c} that solved a problem with using the @code{OPEN} statement as the first Fortran I/O activity in a program without a Fortran main program unit. However, if you don't intend to use @command{g77} (or @command{f2c}) to compile your main program unit---that is, if you intend to compile a @code{main()} procedure using some other language---you should carefully examine the code for @code{main()} in @code{libg2c}, found in the source file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things might need to be done by your @code{main()} in order to provide the Fortran environment your Fortran code is expecting. @cindex @code{IArgC} intrinsic @cindex intrinsics, @code{IArgC} @cindex @code{GetArg} intrinsic @cindex intrinsics, @code{GetArg} For example, @code{libg2c}'s @code{main()} sets up the information used by the @code{IARGC} and @code{GETARG} intrinsics. Bypassing @code{libg2c}'s @code{main()} without providing a substitute for this activity would mean that invoking @code{IARGC} and @code{GETARG} would produce undefined results. @cindex debugging @cindex main program unit, debugging @cindex main() @cindex MAIN__() @cindex .gdbinit When debugging, one implication of the fact that @code{main()}, which is the place where the debugged program ``starts'' from the debugger's point of view, is in @code{libg2c} is that you won't be starting your Fortran program at a point you recognize as your Fortran code. The standard way to get around this problem is to set a break point (a one-time, or temporary, break point will do) at the entrance to @code{MAIN__}, and then run the program. A convenient way to do so is to add the @command{gdb} command @example tbreak MAIN__ @end example @noindent to the file @file{.gdbinit} in the directory in which you're debugging (using @command{gdb}). After doing this, the debugger will see the current execution point of the program as at the beginning of the main program unit of your program. Of course, if you really want to set a break point at some other place in your program and just start the program running, without first breaking at @code{MAIN__}, that should work fine. @node Procedures @section Procedures (SUBROUTINE and FUNCTION) @cindex procedures @cindex SUBROUTINE statement @cindex statements, SUBROUTINE @cindex FUNCTION statement @cindex statements, FUNCTION @cindex signature of procedures Currently, @command{g77} passes arguments via reference---specifically, by passing a pointer to the location in memory of a variable, array, array element, a temporary location that holds the result of evaluating an expression, or a temporary or permanent location that holds the value of a constant. Procedures that accept @code{CHARACTER} arguments are implemented by @command{g77} so that each @code{CHARACTER} argument has two actual arguments. The first argument occupies the expected position in the argument list and has the user-specified name. This argument is a pointer to an array of characters, passed by the caller. The second argument is appended to the end of the user-specified calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x} is the user-specified name. This argument is of the C type @code{ftnlen} (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and is the number of characters the caller has allocated in the array pointed to by the first argument. A procedure will ignore the length argument if @samp{X} is not declared @code{CHARACTER*(*)}, because for other declarations, it knows the length. Not all callers necessarily ``know'' this, however, which is why they all pass the extra argument. The contents of the @code{CHARACTER} argument are specified by the address passed in the first argument (named after it). The procedure can read or write these contents as appropriate. When more than one @code{CHARACTER} argument is present in the argument list, the length arguments are appended in the order the original arguments appear. So @samp{CALL FOO('HI','THERE')} is implemented in C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77} does not provide the trailing null bytes on the constant strings (@command{f2c} does provide them, but they are unnecessary in a Fortran environment, and you should not expect them to be there). Note that the above information applies to @code{CHARACTER} variables and arrays @strong{only}. It does @strong{not} apply to external @code{CHARACTER} functions or to intrinsic @code{CHARACTER} functions. That is, no second length argument is passed to @samp{FOO} in this case: @example CHARACTER X EXTERNAL X CALL FOO(X) @end example @noindent Nor does @samp{FOO} expect such an argument in this case: @example SUBROUTINE FOO(X) CHARACTER X EXTERNAL X @end example Because of this implementation detail, if a program has a bug such that there is disagreement as to whether an argument is a procedure, and the type of the argument is @code{CHARACTER}, subtle symptoms might appear. @node Functions @section Functions (FUNCTION and RETURN) @cindex functions @cindex FUNCTION statement @cindex statements, FUNCTION @cindex RETURN statement @cindex statements, RETURN @cindex return type of functions @command{g77} handles in a special way functions that return the following types: @itemize @bullet @item @code{CHARACTER} @item @code{COMPLEX} @item @code{REAL(KIND=1)} @end itemize For @code{CHARACTER}, @command{g77} implements a subroutine (a C function returning @code{void}) with two arguments prepended: @samp{__g77_result}, which the caller passes as a pointer to a @code{char} array expected to hold the return value, and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value specifying the length of the return value as declared in the calling program. For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length} to determine the size of the array that @samp{__g77_result} points to; otherwise, it ignores that argument. For @code{COMPLEX}, when @option{-ff2c} is in force, @command{g77} implements a subroutine with one argument prepended: @samp{__g77_result}, which the caller passes as a pointer to a variable of the type of the function. The called function writes the return value into this variable instead of returning it as a function value. When @option{-fno-f2c} is in force, @command{g77} implements a @code{COMPLEX} function as @command{gcc}'s @samp{__complex__ float} or @samp{__complex__ double} function (or an emulation thereof, when @option{-femulate-complex} is in effect), returning the result of the function in the same way as @command{gcc} would. For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements a function that actually returns @code{REAL(KIND=2)} (typically C's @code{double} type). When @option{-fno-f2c} is in force, @code{REAL(KIND=1)} functions return @code{float}. @node Names @section Names @cindex symbol names @cindex transforming symbol names Fortran permits each implementation to decide how to represent names as far as how they're seen in other contexts, such as debuggers and when interfacing to other languages, and especially as far as how casing is handled. External names---names of entities that are public, or ``accessible'', to all modules in a program---normally have an underscore (@samp{_}) appended by @command{g77}, to generate code that is compatible with @command{f2c}. External names include names of Fortran things like common blocks, external procedures (subroutines and functions, but not including statement functions, which are internal procedures), and entry point names. However, use of the @option{-fno-underscoring} option disables this kind of transformation of external names (though inhibiting the transformation certainly improves the chances of colliding with incompatible externals written in other languages---but that might be intentional. @cindex -fno-underscoring option @cindex options, -fno-underscoring @cindex -fno-second-underscore option @cindex options, -fno-underscoring When @option{-funderscoring} is in force, any name (external or local) that already has at least one underscore in it is implemented by @command{g77} by appending two underscores. (This second underscore can be disabled via the @option{-fno-second-underscore} option.) External names are changed this way for @command{f2c} compatibility. Local names are changed this way to avoid collisions with external names that are different in the source code---@command{f2c} does the same thing, but there's no compatibility issue there except for user expectations while debugging. For example: @example Max_Cost = 0 @end example @cindex debugging @noindent Here, a user would, in the debugger, refer to this variable using the name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__}, as described below). (We hope to improve @command{g77} in this regard in the future---don't write scripts depending on this behavior! Also, consider experimenting with the @option{-fno-underscoring} option to try out debugging without having to massage names by hand like this.) @command{g77} provides a number of command-line options that allow the user to control how case mapping is handled for source files. The default is the traditional UNIX model for Fortran compilers---names are mapped to lower case. Other command-line options can be specified to map names to upper case, or to leave them exactly as written in the source file. For example: @example Foo = 9.436 @end example @noindent Here, it is normally the case that the variable assigned will be named @samp{foo}. This would be the name to enter when using a debugger to access the variable. However, depending on the command-line options specified, the name implemented by @command{g77} might instead be @samp{FOO} or even @samp{Foo}, thus affecting how debugging is done. Also: @example Call Foo @end example @noindent This would normally call a procedure that, if it were in a separate C program, be defined starting with the line: @example void foo_() @end example @noindent However, @command{g77} command-line options could be used to change the casing of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option could be used to inhibit the appending of the underscore to the name. @node Common Blocks @section Common Blocks (COMMON) @cindex common blocks @cindex @code{COMMON} statement @cindex statements, @code{COMMON} @command{g77} names and lays out @code{COMMON} areas the same way @command{f2c} does, for compatibility with @command{f2c}. @node Local Equivalence Areas @section Local Equivalence Areas (EQUIVALENCE) @cindex equivalence areas @cindex local equivalence areas @cindex EQUIVALENCE statement @cindex statements, EQUIVALENCE @command{g77} treats storage-associated areas involving a @code{COMMON} block as explained in the section on common blocks. A local @code{EQUIVALENCE} area is a collection of variables and arrays connected to each other in any way via @code{EQUIVALENCE}, none of which are listed in a @code{COMMON} statement. (@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name for @var{x} using a different method when more than one name was in the list of names of entities placed at the beginning of the array. Though the documentation specified that the first name listed in the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77} in fact chose the name using a method that was so complicated, it seemed easier to change it to an alphabetical sort than to describe the previous method in the documentation.) @node Complex Variables @section Complex Variables (COMPLEX) @cindex complex variables @cindex imaginary part @cindex COMPLEX statement @cindex statements, COMPLEX As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types (and related intrinsics, constants, functions, and so on) in a manner that makes direct debugging involving these types in Fortran language mode difficult. Essentially, @command{g77} implements these types using an internal construct similar to C's @code{struct}, at least as seen by the @command{gcc} back end. Currently, the back end, when outputting debugging info with the compiled code for the assembler to digest, does not detect these @code{struct} types as being substitutes for Fortran complex. As a result, the Fortran language modes of debuggers such as @command{gdb} see these types as C @code{struct} types, which they might or might not support. Until this is fixed, switch to C language mode to work with entities of @code{COMPLEX} type and then switch back to Fortran language mode afterward. (In @command{gdb}, this is accomplished via @samp{set lang c} and either @samp{set lang fortran} or @samp{set lang auto}.) @node Arrays @section Arrays (DIMENSION) @cindex DIMENSION statement @cindex statements, DIMENSION @cindex array ordering @cindex ordering, array @cindex column-major ordering @cindex row-major ordering @cindex arrays Fortran uses ``column-major ordering'' in its arrays. This differs from other languages, such as C, which use ``row-major ordering''. The difference is that, with Fortran, array elements adjacent to each other in memory differ in the @emph{first} subscript instead of the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)}, whereas with row-major ordering it would follow @samp{A(5,10,19)}. This consideration affects not only interfacing with and debugging Fortran code, it can greatly affect how code is designed and written, especially when code speed and size is a concern. Fortran also differs from C, a popular language for interfacing and to support directly in debuggers, in the way arrays are treated. In C, arrays are single-dimensional and have interesting relationships to pointers, neither of which is true for Fortran. As a result, dealing with Fortran arrays from within an environment limited to C concepts can be challenging. For example, accessing the array element @samp{A(5,10,20)} is easy enough in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations are needed. First, C would treat the A array as a single-dimension array. Second, C does not understand low bounds for arrays as does Fortran. Third, C assumes a low bound of zero (0), while Fortran defaults to a low bound of one (1) and can supports an arbitrary low bound. Therefore, calculations must be done to determine what the C equivalent of @samp{A(5,10,20)} would be, and these calculations require knowing the dimensions of @samp{A}. For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of @samp{A(5,10,20)} would be: @example (5-2) + (10-1)*(11-2+1) + (20-0)*(11-2+1)*(21-1+1) = 4293 @end example @noindent So the C equivalent in this case would be @samp{a[4293]}. When using a debugger directly on Fortran code, the C equivalent might not work, because some debuggers cannot understand the notion of low bounds other than zero. However, unlike @command{f2c}, @command{g77} does inform the GBE that a multi-dimensional array (like @samp{A} in the above example) is really multi-dimensional, rather than a single-dimensional array, so at least the dimensionality of the array is preserved. Debuggers that understand Fortran should have no trouble with non-zero low bounds, but for non-Fortran debuggers, especially C debuggers, the above example might have a C equivalent of @samp{a[4305]}. This calculation is arrived at by eliminating the subtraction of the lower bound in the first parenthesized expression on each line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)} substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}. Actually, the implication of this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine, but that @samp{a[20][10][5]} produces the equivalent of @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds. Come to think of it, perhaps the behavior is due to the debugger internally compensating for the lower bounds by offsetting the base address of @samp{a}, leaving @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of its first element as identified by subscripts equal to the corresponding lower bounds). You know, maybe nobody really needs to use arrays. @node Adjustable Arrays @section Adjustable Arrays (DIMENSION) @cindex arrays, adjustable @cindex adjustable arrays @cindex arrays, automatic @cindex automatic arrays @cindex DIMENSION statement @cindex statements, DIMENSION @cindex dimensioning arrays @cindex arrays, dimensioning Adjustable and automatic arrays in Fortran require the implementation (in this case, the @command{g77} compiler) to ``memorize'' the expressions that dimension the arrays each time the procedure is invoked. This is so that subsequent changes to variables used in those expressions, made during execution of the procedure, do not have any effect on the dimensions of those arrays. For example: @example REAL ARRAY(5) DATA ARRAY/5*2/ CALL X(ARRAY, 5) END SUBROUTINE X(A, N) DIMENSION A(N) N = 20 PRINT *, N, A END @end example @noindent Here, the implementation should, when running the program, print something like: @example 20 2. 2. 2. 2. 2. @end example @noindent Note that this shows that while the value of @samp{N} was successfully changed, the size of the @samp{A} array remained at 5 elements. To support this, @command{g77} generates code that executes before any user code (and before the internally generated computed @code{GOTO} to handle alternate entry points, as described below) that evaluates each (nonconstant) expression in the list of subscripts for an array, and saves the result of each such evaluation to be used when determining the size of the array (instead of re-evaluating the expressions). So, in the above example, when @samp{X} is first invoked, code is executed that copies the value of @samp{N} to a temporary. And that same temporary serves as the actual high bound for the single dimension of the @samp{A} array (the low bound being the constant 1). Since the user program cannot (legitimately) change the value of the temporary during execution of the procedure, the size of the array remains constant during each invocation. For alternate entry points, the code @command{g77} generates takes into account the possibility that a dummy adjustable array is not actually passed to the actual entry point being invoked at that time. In that case, the public procedure implementing the entry point passes to the master private procedure implementing all the code for the entry points a @code{NULL} pointer where a pointer to that adjustable array would be expected. The @command{g77}-generated code doesn't attempt to evaluate any of the expressions in the subscripts for an array if the pointer to that array is @code{NULL} at run time in such cases. (Don't depend on this particular implementation by writing code that purposely passes @code{NULL} pointers where the callee expects adjustable arrays, even if you know the callee won't reference the arrays---nor should you pass @code{NULL} pointers for any dummy arguments used in calculating the bounds of such arrays or leave undefined any values used for that purpose in COMMON---because the way @command{g77} implements these things might change in the future!) @node Alternate Entry Points @section Alternate Entry Points (ENTRY) @cindex alternate entry points @cindex entry points @cindex ENTRY statement @cindex statements, ENTRY The GBE does not understand the general concept of alternate entry points as Fortran provides via the ENTRY statement. @command{g77} gets around this by using an approach to compiling procedures having at least one @code{ENTRY} statement that is almost identical to the approach used by @command{f2c}. (An alternate approach could be used that would probably generate faster, but larger, code that would also be a bit easier to debug.) Information on how @command{g77} implements @code{ENTRY} is provided for those trying to debug such code. The choice of implementation seems unlikely to affect code (compiled in other languages) that interfaces to such code. @command{g77} compiles exactly one public procedure for the primary entry point of a procedure plus each @code{ENTRY} point it specifies, as usual. That is, in terms of the public interface, there is no difference between @example SUBROUTINE X END SUBROUTINE Y END @end example @noindent and: @example SUBROUTINE X ENTRY Y END @end example The difference between the above two cases lies in the code compiled for the @samp{X} and @samp{Y} procedures themselves, plus the fact that, for the second case, an extra internal procedure is compiled. For every Fortran procedure with at least one @code{ENTRY} statement, @command{g77} compiles an extra procedure named @samp{__g77_masterfun_@var{x}}, where @var{x} is the name of the primary entry point (which, in the above case, using the standard compiler options, would be @samp{x_} in C). This extra procedure is compiled as a private procedure---that is, a procedure not accessible by name to separately compiled modules. It contains all the code in the program unit, including the code for the primary entry point plus for every entry point. (The code for each public procedure is quite short, and explained later.) The extra procedure has some other interesting characteristics. The argument list for this procedure is invented by @command{g77}. It contains a single integer argument named @samp{__g77_which_entrypoint}, passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the entry point index---0 for the primary entry point, 1 for the first entry point (the first @code{ENTRY} statement encountered), 2 for the second entry point, and so on. It also contains, for functions returning @code{CHARACTER} and (when @option{-ff2c} is in effect) @code{COMPLEX} functions, and for functions returning different types among the @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()} containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that is expected at run time to contain a pointer to where to store the result of the entry point. For @code{CHARACTER} functions, this storage area is an array of the appropriate number of characters; for @code{COMPLEX} functions, it is the appropriate area for the return type; for multiple-return-type functions, it is a union of all the supported return types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER} and non-@code{CHARACTER} return types via @code{ENTRY} in a single function is not supported by @command{g77}). For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed by yet another argument named @samp{__g77_length} that, at run time, specifies the caller's expected length of the returned value. Note that only @code{CHARACTER*(*)} functions and entry points actually make use of this argument, even though it is always passed by all callers of public @code{CHARACTER} functions (since the caller does not generally know whether such a function is @code{CHARACTER*(*)} or whether there are any other callers that don't have that information). The rest of the argument list is the union of all the arguments specified for all the entry points (in their usual forms, e.g. @code{CHARACTER} arguments have extra length arguments, all appended at the end of this list). This is considered the ``master list'' of arguments. The code for this procedure has, before the code for the first executable statement, code much like that for the following Fortran statement: @smallexample GOTO (100000,100001,100002), __g77_which_entrypoint 100000 @dots{}code for primary entry point@dots{} 100001 @dots{}code immediately following first ENTRY statement@dots{} 100002 @dots{}code immediately following second ENTRY statement@dots{} @end smallexample @noindent (Note that invalid Fortran statement labels and variable names are used in the above example to highlight the fact that it represents code generated by the @command{g77} internals, not code to be written by the user.) It is this code that, when the procedure is called, picks which entry point to start executing. Getting back to the public procedures (@samp{x} and @samp{Y} in the original example), those procedures are fairly simple. Their interfaces are just like they would be if they were self-contained procedures (without @code{ENTRY}), of course, since that is what the callers expect. Their code consists of simply calling the private procedure, described above, with the appropriate extra arguments (the entry point index, and perhaps a pointer to a multiple-type- return variable, local to the public procedure, that contains all the supported returnable non-character types). For arguments that are not listed for a given entry point that are listed for other entry points, and therefore that are in the ``master list'' for the private procedure, null pointers (in C, the @code{NULL} macro) are passed. Also, for entry points that are part of a multiple-type- returning function, code is compiled after the call of the private procedure to extract from the multi-type union the appropriate result, depending on the type of the entry point in question, returning that result to the original caller. When debugging a procedure containing alternate entry points, you can either set a break point on the public procedure itself (e.g. a break point on @samp{X} or @samp{Y}) or on the private procedure that contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}). If you do the former, you should use the debugger's command to ``step into'' the called procedure to get to the actual code; with the latter approach, the break point leaves you right at the actual code, skipping over the public entry point and its call to the private procedure (unless you have set a break point there as well, of course). Further, the list of dummy arguments that is visible when the private procedure is active is going to be the expanded version of the list for whichever particular entry point is active, as explained above, and the way in which return values are handled might well be different from how they would be handled for an equivalent single-entry function. @node Alternate Returns @section Alternate Returns (SUBROUTINE and RETURN) @cindex subroutines @cindex alternate returns @cindex SUBROUTINE statement @cindex statements, SUBROUTINE @cindex RETURN statement @cindex statements, RETURN Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and @samp{CALL X(*50)}) are implemented by @command{g77} as functions returning the C @code{int} type. The actual alternate-return arguments are omitted from the calling sequence. Instead, the caller uses the return value to do a rough equivalent of the Fortran computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)} function), and the callee just returns whatever integer is specified in the @code{RETURN} statement for the subroutine For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed by @samp{RETURN} in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}). @node Assigned Statement Labels @section Assigned Statement Labels (ASSIGN and GOTO) @cindex assigned statement labels @cindex statement labels, assigned @cindex ASSIGN statement @cindex statements, ASSIGN @cindex GOTO statement @cindex statements, GOTO For portability to machines where a pointer (such as to a label, which is how @command{g77} implements @code{ASSIGN} and its relatives, the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements) is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77} uses a different memory location to hold the @code{ASSIGN}ed value of a variable than it does the numerical value in that variable, unless the variable is wide enough (can hold enough bits). In particular, while @command{g77} implements @example I = 10 @end example @noindent as, in C notation, @samp{i = 10;}, it implements @example ASSIGN 10 TO I @end example @noindent as, in GNU's extended C notation (for the label syntax), @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't actually generate the name @samp{L10} or any other name like that, since debuggers cannot access labels anyway). While this currently means that an @code{ASSIGN} statement does not overwrite the numeric contents of its target variable, @emph{do not} write any code depending on this feature. @command{g77} has already changed this implementation across versions and might do so in the future. This information is provided only to make debugging Fortran programs compiled with the current version of @command{g77} somewhat easier. If there's no debugger-visible variable named @samp{__g77_ASSIGN_I} in a program unit that does @samp{ASSIGN 10 TO I}, that probably means @command{g77} has decided it can store the pointer to the label directly into @samp{I} itself. @xref{Ugly Assigned Labels}, for information on a command-line option to force @command{g77} to use the same storage for both normal and assigned-label uses of a variable. @node Run-time Library Errors @section Run-time Library Errors @cindex IOSTAT= @cindex error values @cindex error messages @cindex messages, run-time @cindex I/O, errors The @code{libg2c} library currently has the following table to relate error code numbers, returned in @code{IOSTAT=} variables, to messages. This information should, in future versions of this document, be expanded upon to include detailed descriptions of each message. In line with good coding practices, any of the numbers in the list below should @emph{not} be directly written into Fortran code you write. Instead, make a separate @code{INCLUDE} file that defines @code{PARAMETER} names for them, and use those in your code, so you can more easily change the actual numbers in the future. The information below is culled from the definition of @code{F_err} in @file{f/runtime/libI77/err.c} in the @command{g77} source tree. @smallexample 100: "error in format" 101: "illegal unit number" 102: "formatted io not allowed" 103: "unformatted io not allowed" 104: "direct io not allowed" 105: "sequential io not allowed" 106: "can't backspace file" 107: "null file name" 108: "can't stat file" 109: "unit not connected" 110: "off end of record" 111: "truncation failed in endfile" 112: "incomprehensible list input" 113: "out of free space" 114: "unit not connected" 115: "read unexpected character" 116: "bad logical input field" 117: "bad variable type" 118: "bad namelist name" 119: "variable not in namelist" 120: "no end record" 121: "variable count incorrect" 122: "subscript for scalar variable" 123: "invalid array section" 124: "substring out of bounds" 125: "subscript out of bounds" 126: "can't read file" 127: "can't write file" 128: "'new' file exists" 129: "can't append to file" 130: "non-positive record number" 131: "I/O started while already doing I/O" @end smallexample @node Collected Fortran Wisdom @chapter Collected Fortran Wisdom @cindex wisdom @cindex legacy code @cindex code, legacy @cindex writing code @cindex code, writing Most users of @command{g77} can be divided into two camps: @itemize @bullet @item Those writing new Fortran code to be compiled by @command{g77}. @item Those using @command{g77} to compile existing, ``legacy'' code. @end itemize Users writing new code generally understand most of the necessary aspects of Fortran to write ``mainstream'' code, but often need help deciding how to handle problems, such as the construction of libraries containing @code{BLOCK DATA}. Users dealing with ``legacy'' code sometimes don't have much experience with Fortran, but believe that the code they're compiling already works when compiled by other compilers (and might not understand why, as is sometimes the case, it doesn't work when compiled by @command{g77}). The following information is designed to help users do a better job coping with existing, ``legacy'' Fortran code, and with writing new code as well. @menu * Advantages Over f2c:: If @command{f2c} is so great, why @command{g77}? * Block Data and Libraries:: How @command{g77} solves a common problem. * Loops:: Fortran @code{DO} loops surprise many people. * Working Programs:: Getting programs to work should be done first. * Overly Convenient Options:: Temptations to avoid, habits to not form. * Faster Programs:: Everybody wants these, but at what cost? @end menu @node Advantages Over f2c @section Advantages Over f2c Without @command{f2c}, @command{g77} would have taken much longer to do and probably not been as good for quite a while. Sometimes people who notice how much @command{g77} depends on, and documents encouragement to use, @command{f2c} ask why @command{g77} was created if @command{f2c} already existed. This section gives some basic answers to these questions, though it is not intended to be comprehensive. @menu * Language Extensions:: Features used by Fortran code. * Diagnostic Abilities:: Abilities to spot problems early. * Compiler Options:: Features helpful to accommodate legacy code, etc. * Compiler Speed:: Speed of the compilation process. * Program Speed:: Speed of the generated, optimized code. * Ease of Debugging:: Debugging ease-of-use at the source level. * Character and Hollerith Constants:: A byte saved is a byte earned. @end menu @node Language Extensions @subsection Language Extensions @command{g77} offers several extensions to FORTRAN 77 language that @command{f2c} doesn't: @itemize @bullet @item Automatic arrays @item @code{CYCLE} and @code{EXIT} @item Construct names @item @code{SELECT CASE} @item @code{KIND=} and @code{LEN=} notation @item Semicolon as statement separator @item Constant expressions in @code{FORMAT} statements (such as @samp{FORMAT(I)}, where @samp{J} is a @code{PARAMETER} named constant) @item @code{MvBits} intrinsic @item @code{libU77} (Unix-compatibility) library, with routines known to compiler as intrinsics (so they work even when compiler options are used to change the interfaces used by Fortran routines) @end itemize @command{g77} also implements iterative @code{DO} loops so that they work even in the presence of certain ``extreme'' inputs, unlike @command{f2c}. @xref{Loops}. However, @command{f2c} offers a few that @command{g77} doesn't, such as: @itemize @bullet @item Intrinsics in @code{PARAMETER} statements @item Array bounds expressions (such as @samp{REAL M(N(2))}) @item @code{AUTOMATIC} statement @end itemize It is expected that @command{g77} will offer some or all of these missing features at some time in the future. @node Diagnostic Abilities @subsection Diagnostic Abilities @command{g77} offers better diagnosis of problems in @code{FORMAT} statements. @command{f2c} doesn't, for example, emit any diagnostic for @samp{FORMAT(XZFAJG10324)}, leaving that to be diagnosed, at run time, by the @code{libf2c} run-time library. @node Compiler Options @subsection Compiler Options @command{g77} offers compiler options that @command{f2c} doesn't, most of which are designed to more easily accommodate legacy code: @itemize @bullet @item Two that control the automatic appending of extra underscores to external names @item One that allows dollar signs (@samp{$}) in symbol names @item A variety that control acceptance of various ``ugly'' constructs @item Several that specify acceptable use of upper and lower case in the source code @item Many that enable, disable, delete, or hide groups of intrinsics @item One to specify the length of fixed-form source lines (normally 72) @item One to specify the the source code is written in Fortran-90-style free-form @end itemize However, @command{f2c} offers a few that @command{g77} doesn't, like an option to have @code{REAL} default to @code{REAL*8}. It is expected that @command{g77} will offer all of the missing options pertinent to being a Fortran compiler at some time in the future. @node Compiler Speed @subsection Compiler Speed Saving the steps of writing and then rereading C code is a big reason why @command{g77} should be able to compile code much faster than using @command{f2c} in conjunction with the equivalent invocation of @command{gcc}. However, due to @command{g77}'s youth, lots of self-checking is still being performed. As a result, this improvement is as yet unrealized (though the potential seems to be there for quite a big speedup in the future). It is possible that, as of version 0.5.18, @command{g77} is noticeably faster compiling many Fortran source files than using @command{f2c} in conjunction with @command{gcc}. @node Program Speed @subsection Program Speed @command{g77} has the potential to better optimize code than @command{f2c}, even when @command{gcc} is used to compile the output of @command{f2c}, because @command{f2c} must necessarily translate Fortran into a somewhat lower-level language (C) that cannot preserve all the information that is potentially useful for optimization, while @command{g77} can gather, preserve, and transmit that information directly to the GBE. For example, @command{g77} implements @code{ASSIGN} and assigned @code{GOTO} using direct assignment of pointers to labels and direct jumps to labels, whereas @command{f2c} maps the assigned labels to integer values and then uses a C @code{switch} statement to encode the assigned @code{GOTO} statements. However, as is typical, theory and reality don't quite match, at least not in all cases, so it is still the case that @command{f2c} plus @command{gcc} can generate code that is faster than @command{g77}. Version 0.5.18 of @command{g77} offered default settings and options, via patches to the @command{gcc} back end, that allow for better program speed, though some of these improvements also affected the performance of programs translated by @command{f2c} and then compiled by @command{g77}'s version of @command{gcc}. Version 0.5.20 of @command{g77} offers further performance improvements, at least one of which (alias analysis) is not generally applicable to @command{f2c} (though @command{f2c} could presumably be changed to also take advantage of this new capability of the @command{gcc} back end, assuming this is made available in an upcoming release of @command{gcc}). @node Ease of Debugging @subsection Ease of Debugging Because @command{g77} compiles directly to assembler code like @command{gcc}, instead of translating to an intermediate language (C) as does @command{f2c}, support for debugging can be better for @command{g77} than @command{f2c}. However, although @command{g77} might be somewhat more ``native'' in terms of debugging support than @command{f2c} plus @command{gcc}, there still are a lot of things ``not quite right''. Many of the important ones should be resolved in the near future. For example, @command{g77} doesn't have to worry about reserved names like @command{f2c} does. Given @samp{FOR = WHILE}, @command{f2c} must necessarily translate this to something @emph{other} than @samp{for = while;}, because C reserves those words. However, @command{g77} does still uses things like an extra level of indirection for @code{ENTRY}-laden procedures---in this case, because the back end doesn't yet support multiple entry points. Another example is that, given @smallexample COMMON A, B EQUIVALENCE (B, C) @end smallexample @noindent the @command{g77} user should be able to access the variables directly, by name, without having to traverse C-like structures and unions, while @command{f2c} is unlikely to ever offer this ability (due to limitations in the C language). However, due to apparent bugs in the back end, @command{g77} currently doesn't take advantage of this facility at all---it doesn't emit any debugging information for @code{COMMON} and @code{EQUIVALENCE} areas, other than information on the array of @code{char} it creates (and, in the case of local @code{EQUIVALENCE}, names) for each such area. Yet another example is arrays. @command{g77} represents them to the debugger using the same ``dimensionality'' as in the source code, while @command{f2c} must necessarily convert them all to one-dimensional arrays to fit into the confines of the C language. However, the level of support offered by debuggers for interactive Fortran-style access to arrays as compiled by @command{g77} can vary widely. In some cases, it can actually be an advantage that @command{f2c} converts everything to widely supported C semantics. In fairness, @command{g77} could do many of the things @command{f2c} does to get things working at least as well as @command{f2c}---for now, the developers prefer making @command{g77} work the way they think it is supposed to, and finding help improving the other products (the back end of @command{gcc}; @command{gdb}; and so on) to get things working properly. @node Character and Hollerith Constants @subsection Character and Hollerith Constants @cindex character constants @cindex constants, character @cindex Hollerith constants @cindex constants, Hollerith @cindex trailing null byte @cindex null byte, trailing @cindex zero byte, trailing To avoid the extensive hassle that would be needed to avoid this, @command{f2c} uses C character constants to encode character and Hollerith constants. That means a constant like @samp{'HELLO'} is translated to @samp{"hello"} in C, which further means that an extra null byte is present at the end of the constant. This null byte is superfluous. @command{g77} does not generate such null bytes. This represents significant savings of resources, such as on systems where @file{/dev/null} or @file{/dev/zero} represent bottlenecks in the systems' performance, because @command{g77} simply asks for fewer zeros from the operating system than @command{f2c}. (Avoiding spurious use of zero bytes, each byte typically have eight zero bits, also reduces the liabilities in case Microsoft's rumored patent on the digits 0 and 1 is upheld.) @node Block Data and Libraries @section Block Data and Libraries @cindex block data and libraries @cindex BLOCK DATA statement @cindex statements, BLOCK DATA @cindex libraries, containing BLOCK DATA @cindex f2c compatibility @cindex compatibility, f2c To ensure that block data program units are linked, especially a concern when they are put into libraries, give each one a name (as in @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO} statement in every program unit that uses any common block initialized by the corresponding @code{BLOCK DATA}. @command{g77} currently compiles a @code{BLOCK DATA} as if it were a @code{SUBROUTINE}, that is, it generates an actual procedure having the appropriate name. The procedure does nothing but return immediately if it happens to be called. For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO} in the program and ensures that by generating a reference to it so the linker will make sure it is present. (Specifically, @command{g77} outputs in the data section a static pointer to the external name @samp{FOO}.) The implementation @command{g77} currently uses to make this work is one of the few things not compatible with @command{f2c} as currently shipped. @command{f2c} currently does nothing with @samp{EXTERNAL FOO} except issue a warning that @samp{FOO} is not otherwise referenced, and, for @samp{BLOCK DATA FOO}, @command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}. The upshot is that you shouldn't mix @command{f2c} and @command{g77} in this particular case. If you use @command{f2c} to compile @samp{BLOCK DATA FOO}, then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO} will result in an unresolved reference when linked. If you do the opposite, then @samp{FOO} might not be linked in under various circumstances (such as when @samp{FOO} is in a library, or you're using a ``clever'' linker---so clever, it produces a broken program with little or no warning by omitting initializations of global data because they are contained in unreferenced procedures). The changes you make to your code to make @command{g77} handle this situation, however, appear to be a widely portable way to handle it. That is, many systems permit it (as they should, since the FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO} is a block data program unit), and of the ones that might not link @samp{BLOCK DATA FOO} under some circumstances, most of them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate program units. Here is the recommended approach to modifying a program containing a program unit such as the following: @smallexample BLOCK DATA FOO COMMON /VARS/ X, Y, Z DATA X, Y, Z / 3., 4., 5. / END @end smallexample @noindent If the above program unit might be placed in a library module, then ensure that every program unit in every program that references that particular @code{COMMON} area uses the @code{EXTERNAL} statement to force the area to be initialized. For example, change a program unit that starts with @smallexample INTEGER FUNCTION CURX() COMMON /VARS/ X, Y, Z CURX = X END @end smallexample @noindent so that it uses the @code{EXTERNAL} statement, as in: @smallexample INTEGER FUNCTION CURX() COMMON /VARS/ X, Y, Z EXTERNAL FOO CURX = X END @end smallexample @noindent That way, @samp{CURX} is compiled by @command{g77} (and many other compilers) so that the linker knows it must include @samp{FOO}, the @code{BLOCK DATA} program unit that sets the initial values for the variables in @samp{VAR}, in the executable program. @node Loops @section Loops @cindex DO statement @cindex statements, DO @cindex trips, number of @cindex number of trips The meaning of a @code{DO} loop in Fortran is precisely specified in the Fortran standard@dots{}and is quite different from what many programmers might expect. In particular, Fortran iterative @code{DO} loops are implemented as if the number of trips through the loop is calculated @emph{before} the loop is entered. The number of trips for a loop is calculated from the @var{start}, @var{end}, and @var{increment} values specified in a statement such as: @smallexample DO @var{iter} = @var{start}, @var{end}, @var{increment} @end smallexample @noindent The trip count is evaluated using a fairly simple formula based on the three values following the @samp{=} in the statement, and it is that trip count that is effectively decremented during each iteration of the loop. If, at the beginning of an iteration of the loop, the trip count is zero or negative, the loop terminates. The per-loop-iteration modifications to @var{iter} are not related to determining whether to terminate the loop. There are two important things to remember about the trip count: @itemize @bullet @item It can be @emph{negative}, in which case it is treated as if it was zero---meaning the loop is not executed at all. @item The type used to @emph{calculate} the trip count is the same type as @var{iter}, but the final calculation, and thus the type of the trip count itself, always is @code{INTEGER(KIND=1)}. @end itemize These two items mean that there are loops that cannot be written in straightforward fashion using the Fortran @code{DO}. For example, on a system with the canonical 32-bit two's-complement implementation of @code{INTEGER(KIND=1)}, the following loop will not work: @smallexample DO I = -2000000000, 2000000000 @end smallexample @noindent Although the @var{start} and @var{end} values are well within the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not. The expected trip count is 40000000001, which is outside the range of @code{INTEGER(KIND=1)} on many systems. Instead, the above loop should be constructed this way: @smallexample I = -2000000000 DO IF (I .GT. 2000000000) EXIT @dots{} I = I + 1 END DO @end smallexample @noindent The simple @code{DO} construct and the @code{EXIT} statement (used to leave the innermost loop) are F90 features that @command{g77} supports. Some Fortran compilers have buggy implementations of @code{DO}, in that they don't follow the standard. They implement @code{DO} as a straightforward translation to what, in C, would be a @code{for} statement. Instead of creating a temporary variable to hold the trip count as calculated at run time, these compilers use the iteration variable @var{iter} to control whether the loop continues at each iteration. The bug in such an implementation shows up when the trip count is within the range of the type of @var{iter}, but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})} exceeds that range. For example: @smallexample DO I = 2147483600, 2147483647 @end smallexample @noindent A loop started by the above statement will work as implemented by @command{g77}, but the use, by some compilers, of a more C-like implementation akin to @smallexample for (i = 2147483600; i <= 2147483647; ++i) @end smallexample @noindent produces a loop that does not terminate, because @samp{i} can never be greater than 2147483647, since incrementing it beyond that value overflows @samp{i}, setting it to -2147483648. This is a large, negative number that still is less than 2147483647. Another example of unexpected behavior of @code{DO} involves using a nonintegral iteration variable @var{iter}, that is, a @code{REAL} variable. Consider the following program: @smallexample DATA BEGIN, END, STEP /.1, .31, .007/ DO 10 R = BEGIN, END, STEP IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!' PRINT *,R 10 CONTINUE PRINT *,'LAST = ',R IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!' END @end smallexample @noindent A C-like view of @code{DO} would hold that the two ``exclamatory'' @code{PRINT} statements are never executed. However, this is the output of running the above program as compiled by @command{g77} on a GNU/Linux ix86 system: @smallexample .100000001 .107000001 .114 .120999999 @dots{} .289000005 .296000004 .303000003 LAST = .310000002 .310000002 .LE. .310000002!! @end smallexample Note that one of the two checks in the program turned up an apparent violation of the programmer's expectation---yet, the loop is correctly implemented by @command{g77}, in that it has 30 iterations. This trip count of 30 is correct when evaluated using the floating-point representations for the @var{begin}, @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux ix86 are used. On other systems, an apparently more accurate trip count of 31 might result, but, nevertheless, @command{g77} is faithfully following the Fortran standard, and the result is not what the author of the sample program above apparently expected. (Such other systems might, for different values in the @code{DATA} statement, violate the other programmer's expectation, for example.) Due to this combination of imprecise representation of floating-point values and the often-misunderstood interpretation of @code{DO} by standard-conforming compilers such as @command{g77}, use of @code{DO} loops with @code{REAL} iteration variables is not recommended. Such use can be caught by specifying @option{-Wsurprising}. @xref{Warning Options}, for more information on this option. @node Working Programs @section Working Programs Getting Fortran programs to work in the first place can be quite a challenge---even when the programs already work on other systems, or when using other compilers. @command{g77} offers some facilities that might be useful for tracking down bugs in such programs. @menu * Not My Type:: * Variables Assumed To Be Zero:: * Variables Assumed To Be Saved:: * Unwanted Variables:: * Unused Arguments:: * Surprising Interpretations of Code:: * Aliasing Assumed To Work:: * Output Assumed To Flush:: * Large File Unit Numbers:: * Floating-point precision:: * Inconsistent Calling Sequences:: @end menu @node Not My Type @subsection Not My Type @cindex mistyped variables @cindex variables, mistyped @cindex mistyped functions @cindex functions, mistyped @cindex implicit typing A fruitful source of bugs in Fortran source code is use, or mis-use, of Fortran's implicit-typing feature, whereby the type of a variable, array, or function is determined by the first character of its name. Simple cases of this include statements like @samp{LOGX=9.227}, without a statement such as @samp{REAL LOGX}. In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)} type, with the result of the assignment being that it is given the value @samp{9}. More involved cases include a function that is defined starting with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}. Any caller of this function that does not also declare @samp{IPS} as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)}) is likely to assume it returns @code{INTEGER}, or some other type, leading to invalid results or even program crashes. The @option{-Wimplicit} option might catch failures to properly specify the types of variables, arrays, and functions in the code. However, in code that makes heavy use of Fortran's implicit-typing facility, this option might produce so many warnings about cases that are working, it would be hard to find the one or two that represent bugs. This is why so many experienced Fortran programmers strongly recommend widespread use of the @code{IMPLICIT NONE} statement, despite it not being standard FORTRAN 77, to completely turn off implicit typing. (@command{g77} supports @code{IMPLICIT NONE}, as do almost all FORTRAN 77 compilers.) Note that @option{-Wimplicit} catches only implicit typing of @emph{names}. It does not catch implicit typing of expressions such as @samp{X**(2/3)}. Such expressions can be buggy as well---in fact, @samp{X**(2/3)} is equivalent to @samp{X**0}, due to the way Fortran expressions are given types and then evaluated. (In this particular case, the programmer probably wanted @samp{X**(2./3.)}.) @node Variables Assumed To Be Zero @subsection Variables Assumed To Be Zero @cindex zero-initialized variables @cindex variables, assumed to be zero @cindex uninitialized variables Many Fortran programs were developed on systems that provided automatic initialization of all, or some, variables and arrays to zero. As a result, many of these programs depend, sometimes inadvertently, on this behavior, though to do so violates the Fortran standards. You can ask @command{g77} for this behavior by specifying the @option{-finit-local-zero} option when compiling Fortran code. (You might want to specify @option{-fno-automatic} as well, to avoid code-size inflation for non-optimized compilations.) Note that a program that works better when compiled with the @option{-finit-local-zero} option is almost certainly depending on a particular system's, or compiler's, tendency to initialize some variables to zero. It might be worthwhile finding such cases and fixing them, using techniques such as compiling with the @option{-O -Wuninitialized} options using @command{g77}. @node Variables Assumed To Be Saved @subsection Variables Assumed To Be Saved @cindex variables, retaining values across calls @cindex saved variables @cindex static variables Many Fortran programs were developed on systems that saved the values of all, or some, variables and arrays across procedure calls. As a result, many of these programs depend, sometimes inadvertently, on being able to assign a value to a variable, perform a @code{RETURN} to a calling procedure, and, upon subsequent invocation, reference the previously assigned variable to obtain the value. They expect this despite not using the @code{SAVE} statement to specify that the value in a variable is expected to survive procedure returns and calls. Depending on variables and arrays to retain values across procedure calls without using @code{SAVE} to require it violates the Fortran standards. You can ask @command{g77} to assume @code{SAVE} is specified for all relevant (local) variables and arrays by using the @option{-fno-automatic} option. Note that a program that works better when compiled with the @option{-fno-automatic} option is almost certainly depending on not having to use the @code{SAVE} statement as required by the Fortran standard. It might be worthwhile finding such cases and fixing them, using techniques such as compiling with the @samp{-O -Wuninitialized} options using @command{g77}. @node Unwanted Variables @subsection Unwanted Variables The @option{-Wunused} option can find bugs involving implicit typing, sometimes more easily than using @option{-Wimplicit} in code that makes heavy use of implicit typing. An unused variable or array might indicate that the spelling for its declaration is different from that of its intended uses. Other than cases involving typos, unused variables rarely indicate actual bugs in a program. However, investigating such cases thoroughly has, on occasion, led to the discovery of code that had not been completely written---where the programmer wrote declarations as needed for the whole algorithm, wrote some or even most of the code for that algorithm, then got distracted and forgot that the job was not complete. @node Unused Arguments @subsection Unused Arguments @cindex unused arguments @cindex arguments, unused As with unused variables, It is possible that unused arguments to a procedure might indicate a bug. Compile with @samp{-W -Wunused} option to catch cases of unused arguments. Note that @option{-W} also enables warnings regarding overflow of floating-point constants under certain circumstances. @node Surprising Interpretations of Code @subsection Surprising Interpretations of Code The @option{-Wsurprising} option can help find bugs involving expression evaluation or in the way @code{DO} loops with non-integral iteration variables are handled. Cases found by this option might indicate a difference of interpretation between the author of the code involved, and a standard-conforming compiler such as @command{g77}. Such a difference might produce actual bugs. In any case, changing the code to explicitly do what the programmer might have expected it to do, so @command{g77} and other compilers are more likely to follow the programmer's expectations, might be worthwhile, especially if such changes make the program work better. @node Aliasing Assumed To Work @subsection Aliasing Assumed To Work @cindex -falias-check option @cindex options, -falias-check @cindex -fargument-alias option @cindex options, -fargument-alias @cindex -fargument-noalias option @cindex options, -fargument-noalias @cindex -fno-argument-noalias-global option @cindex options, -fno-argument-noalias-global @cindex aliasing @cindex anti-aliasing @cindex overlapping arguments @cindex overlays @cindex association, storage @cindex storage association @cindex scheduling of reads and writes @cindex reads and writes, scheduling The @option{-falias-check}, @option{-fargument-alias}, @option{-fargument-noalias}, and @option{-fno-argument-noalias-global} options, introduced in version 0.5.20 and @command{g77}'s version 2.7.2.2.f.2 of @command{gcc}, were withdrawn as of @command{g77} version 0.5.23 due to their not being supported by @command{gcc} version 2.8. These options control the assumptions regarding aliasing (overlapping) of writes and reads to main memory (core) made by the @command{gcc} back end. The information below still is useful, but applies to only those versions of @command{g77} that support the alias analysis implied by support for these options. These options are effective only when compiling with @option{-O} (specifying any level other than @option{-O0}) or with @option{-falias-check}. The default for Fortran code is @option{-fargument-noalias-global}. (The default for C code and code written in other C-based languages is @option{-fargument-alias}. These defaults apply regardless of whether you use @command{g77} or @command{gcc} to compile your code.) Note that, on some systems, compiling with @option{-fforce-addr} in effect can produce more optimal code when the default aliasing options are in effect (and when optimization is enabled). If your program is not working when compiled with optimization, it is possible it is violating the Fortran standards (77 and 90) by relying on the ability to ``safely'' modify variables and arrays that are aliased, via procedure calls, to other variables and arrays, without using @code{EQUIVALENCE} to explicitly set up this kind of aliasing. (The FORTRAN 77 standard's prohibition of this sort of overlap, generally referred to therein as ``storage assocation'', appears in Sections 15.9.3.6. This prohibition allows implementations, such as @command{g77}, to, for example, implement the passing of procedures and even values in @code{COMMON} via copy operations into local, perhaps more efficiently accessed temporaries at entry to a procedure, and, where appropriate, via copy operations back out to their original locations in memory at exit from that procedure, without having to take into consideration the order in which the local copies are updated by the code, among other things.) To test this hypothesis, try compiling your program with the @option{-fargument-alias} option, which causes the compiler to revert to assumptions essentially the same as made by versions of @command{g77} prior to 0.5.20. If the program works using this option, that strongly suggests that the bug is in your program. Finding and fixing the bug(s) should result in a program that is more standard-conforming and that can be compiled by @command{g77} in a way that results in a faster executable. (You might want to try compiling with @option{-fargument-noalias}, a kind of half-way point, to see if the problem is limited to aliasing between dummy arguments and @code{COMMON} variables---this option assumes that such aliasing is not done, while still allowing aliasing among dummy arguments.) An example of aliasing that is invalid according to the standards is shown in the following program, which might @emph{not} produce the expected results when executed: @smallexample I = 1 CALL FOO(I, I) PRINT *, I END SUBROUTINE FOO(J, K) J = J + K K = J * K PRINT *, J, K END @end smallexample The above program attempts to use the temporary aliasing of the @samp{J} and @samp{K} arguments in @samp{FOO} to effect a pathological behavior---the simultaneous changing of the values of @emph{both} @samp{J} and @samp{K} when either one of them is written. The programmer likely expects the program to print these values: @example 2 4 4 @end example However, since the program is not standard-conforming, an implementation's behavior when running it is undefined, because subroutine @samp{FOO} modifies at least one of the arguments, and they are aliased with each other. (Even if one of the assignment statements was deleted, the program would still violate these rules. This kind of on-the-fly aliasing is permitted by the standard only when none of the aliased items are defined, or written, while the aliasing is in effect.) As a practical example, an optimizing compiler might schedule the @samp{J =} part of the second line of @samp{FOO} @emph{after} the reading of @samp{J} and @samp{K} for the @samp{J * K} expression, resulting in the following output: @example 2 2 2 @end example Essentially, compilers are promised (by the standard and, therefore, by programmers who write code they claim to be standard-conforming) that if they cannot detect aliasing via static analysis of a single program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no such aliasing exists. In such cases, compilers are free to assume that an assignment to one variable will not change the value of another variable, allowing it to avoid generating code to re-read the value of the other variable, to re-schedule reads and writes, and so on, to produce a faster executable. The same promise holds true for arrays (as seen by the called procedure)---an element of one dummy array cannot be aliased with, or overlap, any element of another dummy array or be in a @code{COMMON} area known to the procedure. (These restrictions apply only when the procedure defines, or writes to, one of the aliased variables or arrays.) Unfortunately, there is no way to find @emph{all} possible cases of violations of the prohibitions against aliasing in Fortran code. Static analysis is certainly imperfect, as is run-time analysis, since neither can catch all violations. (Static analysis can catch all likely violations, and some that might never actually happen, while run-time analysis can catch only those violations that actually happen during a particular run. Neither approach can cope with programs mixing Fortran code with routines written in other languages, however.) Currently, @command{g77} provides neither static nor run-time facilities to detect any cases of this problem, although other products might. Run-time facilities are more likely to be offered by future versions of @command{g77}, though patches improving @command{g77} so that it provides either form of detection are welcome. @node Output Assumed To Flush @subsection Output Assumed To Flush @cindex ALWAYS_FLUSH @cindex synchronous write errors @cindex disk full @cindex flushing output @cindex fflush() @cindex I/O, flushing @cindex output, flushing @cindex writes, flushing @cindex NFS @cindex network file system For several versions prior to 0.5.20, @command{g77} configured its version of the @code{libf2c} run-time library so that one of its configuration macros, @code{ALWAYS_FLUSH}, was defined. This was done as a result of a belief that many programs expected output to be flushed to the operating system (under UNIX, via the @code{fflush()} library call) with the result that errors, such as disk full, would be immediately flagged via the relevant @code{ERR=} and @code{IOSTAT=} mechanism. Because of the adverse effects this approach had on the performance of many programs, @command{g77} no longer configures @code{libf2c} (now named @code{libg2c} in its @command{g77} incarnation) to always flush output. If your program depends on this behavior, either insert the appropriate @samp{CALL FLUSH} statements, or modify the sources to the @code{libg2c}, rebuild and reinstall @command{g77}, and relink your programs with the modified library. (Ideally, @code{libg2c} would offer the choice at run-time, so that a compile-time option to @command{g77} or @command{f2c} could result in generating the appropriate calls to flushing or non-flushing library routines.) Some Fortran programs require output (writes) to be flushed to the operating system (under UNIX, via the @code{fflush()} library call) so that errors, such as disk full, are immediately flagged via the relevant @code{ERR=} and @code{IOSTAT=} mechanism, instead of such errors being flagged later as subsequent writes occur, forcing the previously written data to disk, or when the file is closed. Essentially, the difference can be viewed as synchronous error reporting (immediate flagging of errors during writes) versus asynchronous, or, more precisely, buffered error reporting (detection of errors might be delayed). @code{libg2c} supports flagging write errors immediately when it is built with the @code{ALWAYS_FLUSH} macro defined. This results in a @code{libg2c} that runs slower, sometimes quite a bit slower, under certain circumstances---for example, accessing files via the networked file system NFS---but the effect can be more reliable, robust file I/O. If you know that Fortran programs requiring this level of precision of error reporting are to be compiled using the version of @command{g77} you are building, you might wish to modify the @command{g77} source tree so that the version of @code{libg2c} is built with the @code{ALWAYS_FLUSH} macro defined, enabling this behavior. To do this, find this line in @file{@value{path-libf2c}/f2c.h} in your @command{g77} source tree: @example /* #define ALWAYS_FLUSH */ @end example Remove the leading @samp{/*@w{ }}, so the line begins with @samp{#define}, and the trailing @samp{@w{ }*/}. Then build or rebuild @command{g77} as appropriate. @node Large File Unit Numbers @subsection Large File Unit Numbers @cindex MXUNIT @cindex unit numbers @cindex maximum unit number @cindex illegal unit number @cindex increasing maximum unit number If your program crashes at run time with a message including the text @samp{illegal unit number}, that probably is a message from the run-time library, @code{libg2c}. The message means that your program has attempted to use a file unit number that is out of the range accepted by @code{libg2c}. Normally, this range is 0 through 99, and the high end of the range is controlled by a @code{libg2c} source-file macro named @code{MXUNIT}. If you can easily change your program to use unit numbers in the range 0 through 99, you should do so. As distributed, whether as part of @command{f2c} or @command{g77}, @code{libf2c} accepts file unit numbers only in the range 0 through 99. For example, a statement such as @samp{WRITE (UNIT=100)} causes a run-time crash in @code{libf2c}, because the unit number, 100, is out of range. If you know that Fortran programs at your installation require the use of unit numbers higher than 99, you can change the value of the @code{MXUNIT} macro, which represents the maximum unit number, to an appropriately higher value. To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your @command{g77} source tree, changing the following line: @example #define MXUNIT 100 @end example Change the line so that the value of @code{MXUNIT} is defined to be at least one @emph{greater} than the maximum unit number used by the Fortran programs on your system. (For example, a program that does @samp{WRITE (UNIT=255)} would require @code{MXUNIT} set to at least 256 to avoid crashing.) Then build or rebuild @command{g77} as appropriate. @emph{Note:} Changing this macro has @emph{no} effect on other limits your system might place on the number of files open at the same time. That is, the macro might allow a program to do @samp{WRITE (UNIT=100)}, but the library and operating system underlying @code{libf2c} might disallow it if many other files have already been opened (via @code{OPEN} or implicitly via @code{READ}, @code{WRITE}, and so on). Information on how to increase these other limits should be found in your system's documentation. @node Floating-point precision @subsection Floating-point precision @cindex IEEE 754 conformance @cindex conformance, IEEE 754 @cindex floating-point, precision @cindex ix86 floating-point @cindex x86 floating-point If your program depends on exact IEEE 754 floating-point handling it may help on some systems---specifically x86 or m68k hardware---to use the @option{-ffloat-store} option or to reset the precision flag on the floating-point unit. @xref{Optimize Options}. However, it might be better simply to put the FPU into double precision mode and not take the performance hit of @option{-ffloat-store}. On x86 and m68k GNU systems you can do this with a technique similar to that for turning on floating-point exceptions (@pxref{Floating-point Exception Handling}). The control word could be set to double precision by some code like this one: @smallexample #include @{ fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE; _FPU_SETCW(cw); @} @end smallexample (It is not clear whether this has any effect on the operation of the GNU maths library, but we have no evidence of it causing trouble.) Some targets (such as the Alpha) may need special options for full IEEE conformance. @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using the GNU Compiler Collection (GCC)}. @node Inconsistent Calling Sequences @subsection Inconsistent Calling Sequences @pindex ftnchek @cindex floating-point, errors @cindex ix86 FPU stack @cindex x86 FPU stack Code containing inconsistent calling sequences in the same file is normally rejected---see @ref{GLOBALS}. (Use, say, @command{ftnchek} to ensure consistency across source files. @xref{f2c Skeletons and Prototypes,, Generating Skeletons and Prototypes with @command{f2c}}.) Mysterious errors, which may appear to be code generation problems, can appear specifically on the x86 architecture with some such inconsistencies. On x86 hardware, floating-point return values of functions are placed on the floating-point unit's register stack, not the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION} @code{FUNCTION} as some other sort of procedure, or vice versa, scrambles the floating-point stack. This may break unrelated code executed later. Similarly if, say, external C routines are written incorrectly. @node Overly Convenient Options @section Overly Convenient Command-line Options @cindex overly convenient options @cindex options, overly convenient These options should be used only as a quick-and-dirty way to determine how well your program will run under different compilation models without having to change the source. Some are more problematic than others, depending on how portable and maintainable you want the program to be (and, of course, whether you are allowed to change it at all is crucial). You should not continue to use these command-line options to compile a given program, but rather should make changes to the source code: @table @code @cindex -finit-local-zero option @cindex options, -finit-local-zero @item -finit-local-zero (This option specifies that any uninitialized local variables and arrays have default initialization to binary zeros.) Many other compilers do this automatically, which means lots of Fortran code developed with those compilers depends on it. It is safer (and probably would produce a faster program) to find the variables and arrays that need such initialization and provide it explicitly via @code{DATA}, so that @option{-finit-local-zero} is not needed. Consider using @option{-Wuninitialized} (which requires @option{-O}) to find likely candidates, but do not specify @option{-finit-local-zero} or @option{-fno-automatic}, or this technique won't work. @cindex -fno-automatic option @cindex options, -fno-automatic @item -fno-automatic (This option specifies that all local variables and arrays are to be treated as if they were named in @code{SAVE} statements.) Many other compilers do this automatically, which means lots of Fortran code developed with those compilers depends on it. The effect of this is that all non-automatic variables and arrays are made static, that is, not placed on the stack or in heap storage. This might cause a buggy program to appear to work better. If so, rather than relying on this command-line option (and hoping all compilers provide the equivalent one), add @code{SAVE} statements to some or all program unit sources, as appropriate. Consider using @option{-Wuninitialized} (which requires @option{-O}) to find likely candidates, but do not specify @option{-finit-local-zero} or @option{-fno-automatic}, or this technique won't work. The default is @option{-fautomatic}, which tells @command{g77} to try and put variables and arrays on the stack (or in fast registers) where possible and reasonable. This tends to make programs faster. @cindex automatic arrays @cindex arrays, automatic @emph{Note:} Automatic variables and arrays are not affected by this option. These are variables and arrays that are @emph{necessarily} automatic, either due to explicit statements, or due to the way they are declared. Examples include local variables and arrays not given the @code{SAVE} attribute in procedures declared @code{RECURSIVE}, and local arrays declared with non-constant bounds (automatic arrays). Currently, @command{g77} supports only automatic arrays, not @code{RECURSIVE} procedures or other means of explicitly specifying that variables or arrays are automatic. @cindex -f@var{group}-intrinsics-hide option @cindex options, -f@var{group}-intrinsics-hide @item -f@var{group}-intrinsics-hide Change the source code to use @code{EXTERNAL} for any external procedure that might be the name of an intrinsic. It is easy to find these using @option{-f@var{group}-intrinsics-disable}. @end table @node Faster Programs @section Faster Programs @cindex speed, of programs @cindex programs, speeding up Aside from the usual @command{gcc} options, such as @option{-O}, @option{-ffast-math}, and so on, consider trying some of the following approaches to speed up your program (once you get it working). @menu * Aligned Data:: * Prefer Automatic Uninitialized Variables:: * Avoid f2c Compatibility:: * Use Submodel Options:: @end menu @node Aligned Data @subsection Aligned Data @cindex alignment @cindex data, aligned @cindex stack, aligned @cindex aligned data @cindex aligned stack @cindex Pentium optimizations @cindex optimization, for Pentium On some systems, such as those with Pentium Pro CPUs, programs that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) might run much slower than possible due to the compiler not aligning these 64-bit values to 64-bit boundaries in memory. (The effect also is present, though to a lesser extent, on the 586 (Pentium) architecture.) The Intel x86 architecture generally ensures that these programs will work on all its implementations, but particular implementations (such as Pentium Pro) perform better with more strict alignment. (Such behavior isn't unique to the Intel x86 architecture.) Other architectures might @emph{demand} 64-bit alignment of 64-bit data. There are a variety of approaches to use to address this problem: @itemize @bullet @item @cindex @code{COMMON} layout @cindex layout of @code{COMMON} blocks Order your @code{COMMON} and @code{EQUIVALENCE} areas such that the variables and arrays with the widest alignment guidelines come first. For example, on most systems, this would mean placing @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)}, @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER} and @code{INTEGER(KIND=3)} entities. The reason to use such placement is it makes it more likely that your data will be aligned properly, without requiring you to do detailed analysis of each aggregate (@code{COMMON} and @code{EQUIVALENCE}) area. Specifically, on systems where the above guidelines are appropriate, placing @code{CHARACTER} entities before @code{REAL(KIND=2)} entities can work just as well, but only if the number of bytes occupied by the @code{CHARACTER} entities is divisible by the recommended alignment for @code{REAL(KIND=2)}. By ordering the placement of entities in aggregate areas according to the simple guidelines above, you avoid having to carefully count the number of bytes occupied by each entity to determine whether the actual alignment of each subsequent entity meets the alignment guidelines for the type of that entity. If you don't ensure correct alignment of @code{COMMON} elements, the compiler may be forced by some systems to violate the Fortran semantics by adding padding to get @code{DOUBLE PRECISION} data properly aligned. If the unfortunate practice is employed of overlaying different types of data in the @code{COMMON} block, the different variants of this block may become misaligned with respect to each other. Even if your platform doesn't require strict alignment, @code{COMMON} should be laid out as above for portability. (Unfortunately the FORTRAN 77 standard didn't anticipate this possible requirement, which is compiler-independent on a given platform.) @item @cindex -malign-double option @cindex options, -malign-double Use the (x86-specific) @option{-malign-double} option when compiling programs for the Pentium and Pentium Pro architectures (called 586 and 686 in the @command{gcc} configuration subsystem). The warning about this in the @command{gcc} manual isn't generally relevant to Fortran, but using it will force @code{COMMON} to be padded if necessary to align @code{DOUBLE PRECISION} data. When @code{DOUBLE PRECISION} data is forcibly aligned in @code{COMMON} by @command{g77} due to specifying @option{-malign-double}, @command{g77} issues a warning about the need to insert padding. In this case, each and every program unit that uses the same @code{COMMON} area must specify the same layout of variables and their types for that area and be compiled with @option{-malign-double} as well. @command{g77} will issue warnings in each case, but as long as every program unit using that area is compiled with the same warnings, the resulting object files should work when linked together unless the program makes additional assumptions about @code{COMMON} area layouts that are outside the scope of the FORTRAN 77 standard, or uses @code{EQUIVALENCE} or different layouts in ways that assume no padding is ever inserted by the compiler. @item Ensure that @file{crt0.o} or @file{crt1.o} on your system guarantees a 64-bit aligned stack for @code{main()}. The recent one from GNU (@code{glibc2}) will do this on x86 systems, but we don't know of any other x86 setups where it will be right. Read your system's documentation to determine if it is appropriate to upgrade to a more recent version to obtain the optimal alignment. @end itemize Progress is being made on making this work ``out of the box'' on future versions of @command{g77}, @command{gcc}, and some of the relevant operating systems (such as GNU/Linux). @cindex alignment testing @cindex testing alignment A package that tests the degree to which a Fortran compiler (such as @command{g77}) aligns 64-bit floating-point variables and arrays is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}. @node Prefer Automatic Uninitialized Variables @subsection Prefer Automatic Uninitialized Variables If you're using @option{-fno-automatic} already, you probably should change your code to allow compilation with @option{-fautomatic} (the default), to allow the program to run faster. Similarly, you should be able to use @option{-fno-init-local-zero} (the default) instead of @option{-finit-local-zero}. This is because it is rare that every variable affected by these options in a given program actually needs to be so affected. For example, @option{-fno-automatic}, which effectively @code{SAVE}s every local non-automatic variable and array, affects even things like @code{DO} iteration variables, which rarely need to be @code{SAVE}d, and this often reduces run-time performances. Similarly, @option{-fno-init-local-zero} forces such variables to be initialized to zero---when @code{SAVE}d (such as when @option{-fno-automatic}), this by itself generally affects only startup time for a program, but when not @code{SAVE}d, it can slow down the procedure every time it is called. @xref{Overly Convenient Options,,Overly Convenient Command-Line Options}, for information on the @option{-fno-automatic} and @option{-finit-local-zero} options and how to convert their use into selective changes in your own code. @node Avoid f2c Compatibility @subsection Avoid f2c Compatibility @cindex -fno-f2c option @cindex options, -fno-f2c @cindex @command{f2c} compatibility @cindex compatibility, @command{f2c} If you aren't linking with any code compiled using @command{f2c}, try using the @option{-fno-f2c} option when compiling @emph{all} the code in your program. (Note that @code{libf2c} is @emph{not} an example of code that is compiled using @command{f2c}---it is compiled by a C compiler, typically @command{gcc}.) @node Use Submodel Options @subsection Use Submodel Options @cindex submodels Using an appropriate @option{-m} option to generate specific code for your CPU may be worthwhile, though it may mean the executable won't run on other versions of the CPU that don't support the same instruction set. @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using the GNU Compiler Collection (GCC)}. For instance on an x86 system the compiler might have been built---as shown by @samp{g77 -v}---for the target @samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to generate code best optimized for a Pentium you could use the option @option{-march=pentium}. For recent CPUs that don't have explicit support in the released version of @command{gcc}, it @emph{might} still be possible to get improvements with certain @option{-m} options. @option{-fomit-frame-pointer} can help performance on x86 systems and others. It will, however, inhibit debugging on the systems on which it is not turned on anyway by @option{-O}. @node Trouble @chapter Known Causes of Trouble with GNU Fortran @cindex bugs, known @cindex installation trouble @cindex known causes of trouble This section describes known problems that affect users of GNU Fortran. Most of these are not GNU Fortran bugs per se---if they were, we would fix them. But the result for a user might be like the result of a bug. Some of these problems are due to bugs in other software, some are missing features that are too much work to add, and some are places where people's opinions differ as to what is best. To find out about major bugs discovered in the current release and possible workarounds for them, see @uref{ftp://alpha.gnu.org/g77.plan}. (Note that some of this portion of the manual is lifted directly from the @command{gcc} manual, with minor modifications to tailor it to users of @command{g77}. Anytime a bug seems to have more to do with the @command{gcc} portion of @command{g77}, see @ref{Trouble,,Known Causes of Trouble with GCC, gcc,Using the GNU Compiler Collection (GCC)}.) @menu * But-bugs:: Bugs really in other programs or elsewhere. * Known Bugs:: Bugs known to be in this version of @command{g77}. * Missing Features:: Features we already know we want to add later. * Disappointments:: Regrettable things we can't change. * Non-bugs:: Things we think are right, but some others disagree. * Warnings and Errors:: Which problems in your code get warnings, and which get errors. @end menu @node But-bugs @section Bugs Not In GNU Fortran @cindex but-bugs These are bugs to which the maintainers often have to reply, ``but that isn't a bug in @command{g77}@dots{}''. Some of these already are fixed in new versions of other software; some still need to be fixed; some are problems with how @command{g77} is installed or is being used; some are the result of bad hardware that causes software to misbehave in sometimes bizarre ways; some just cannot be addressed at this time until more is known about the problem. Please don't re-report these bugs to the @command{g77} maintainers---if you must remind someone how important it is to you that the problem be fixed, talk to the people responsible for the other products identified below, but preferably only after you've tried the latest versions of those products. The @command{g77} maintainers have their hands full working on just fixing and improving @command{g77}, without serving as a clearinghouse for all bugs that happen to affect @command{g77} users. @xref{Collected Fortran Wisdom}, for information on behavior of Fortran programs, and the programs that compile them, that might be @emph{thought} to indicate bugs. @menu * Signal 11 and Friends:: Strange behavior by any software. * Cannot Link Fortran Programs:: Unresolved references. * Large Common Blocks:: Problems on older GNU/Linux systems. * Debugger Problems:: When the debugger crashes. * NeXTStep Problems:: Misbehaving executables. * Stack Overflow:: More misbehaving executables. * Nothing Happens:: Less behaving executables. * Strange Behavior at Run Time:: Executables misbehaving due to bugs in your program. * Floating-point Errors:: The results look wrong, but@dots{}. @end menu @node Signal 11 and Friends @subsection Signal 11 and Friends @cindex signal 11 @cindex hardware errors A whole variety of strange behaviors can occur when the software, or the way you are using the software, stresses the hardware in a way that triggers hardware bugs. This might seem hard to believe, but it happens frequently enough that there exist documents explaining in detail what the various causes of the problems are, what typical symptoms look like, and so on. Generally these problems are referred to in this document as ``signal 11'' crashes, because the Linux kernel, running on the most popular hardware (the Intel x86 line), often stresses the hardware more than other popular operating systems. When hardware problems do occur under GNU/Linux on x86 systems, these often manifest themselves as ``signal 11'' problems, as illustrated by the following diagnostic: @smallexample sh# @kbd{g77 myprog.f} gcc: Internal compiler error: program f771 got fatal signal 11 sh# @end smallexample It is @emph{very} important to remember that the above message is @emph{not} the only one that indicates a hardware problem, nor does it always indicate a hardware problem. In particular, on systems other than those running the Linux kernel, the message might appear somewhat or very different, as it will if the error manifests itself while running a program other than the @command{g77} compiler. For example, it will appear somewhat different when running your program, when running Emacs, and so on. How to cope with such problems is well beyond the scope of this manual. However, users of Linux-based systems (such as GNU/Linux) should review @uref{http://www.bitwizard.nl/sig11/}, a source of detailed information on diagnosing hardware problems, by recognizing their common symptoms. Users of other operating systems and hardware might find this reference useful as well. If you know of similar material for another hardware/software combination, please let us know so we can consider including a reference to it in future versions of this manual. @node Cannot Link Fortran Programs @subsection Cannot Link Fortran Programs @cindex unresolved reference (various) @cindex linking error for user code @cindex code, user @cindex @command{ld}, error linking user code @cindex @command{ld}, can't find strange names On some systems, perhaps just those with out-of-date (shared?) libraries, unresolved-reference errors happen when linking @command{g77}-compiled programs (which should be done using @command{g77}). If this happens to you, try appending @option{-lc} to the command you use to link the program, e.g. @samp{g77 foo.f -lc}. @command{g77} already specifies @samp{-lg2c -lm} when it calls the linker, but it cannot also specify @option{-lc} because not all systems have a file named @file{libc.a}. It is unclear at this point whether there are legitimately installed systems where @samp{-lg2c -lm} is insufficient to resolve code produced by @command{g77}. @cindex undefined reference (_main) @cindex linking error, user code @cindex @command{ld}, error linking user code @cindex code, user @cindex @command{ld}, can't find @samp{_main} If your program doesn't link due to unresolved references to names like @samp{_main}, make sure you're using the @command{g77} command to do the link, since this command ensures that the necessary libraries are loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc} command to do the actual link. (Use the @option{-v} option to discover more about what actually happens when you use the @command{g77} and @command{gcc} commands.) Also, try specifying @option{-lc} as the last item on the @command{g77} command line, in case that helps. @node Large Common Blocks @subsection Large Common Blocks @cindex common blocks, large @cindex large common blocks @cindex linking, errors @cindex @command{ld}, errors @cindex errors, linker On some older GNU/Linux systems, programs with common blocks larger than 16MB cannot be linked without some kind of error message being produced. This is a bug in older versions of @command{ld}, fixed in more recent versions of @code{binutils}, such as version 2.6. @node Debugger Problems @subsection Debugger Problems @cindex @command{gdb}, support @cindex support, @command{gdb} There are some known problems when using @command{gdb} on code compiled by @command{g77}. Inadequate investigation as of the release of 0.5.16 results in not knowing which products are the culprit, but @file{gdb-4.14} definitely crashes when, for example, an attempt is made to print the contents of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux machines, plus some others. Attempts to access assumed-size arrays are also known to crash recent versions of @command{gdb}. (@command{gdb}'s Fortran support was done for a different compiler and isn't properly compatible with @command{g77}.) @node NeXTStep Problems @subsection NeXTStep Problems @cindex NeXTStep problems @cindex bus error @cindex segmentation violation Developers of Fortran code on NeXTStep (all architectures) have to watch out for the following problem when writing programs with large, statically allocated (i.e. non-stack based) data structures (common blocks, saved arrays). Due to the way the native loader (@file{/bin/ld}) lays out data structures in virtual memory, it is very easy to create an executable wherein the @samp{__DATA} segment overlaps (has addresses in common) with the @samp{UNIX STACK} segment. This leads to all sorts of trouble, from the executable simply not executing, to bus errors. The NeXTStep command line tool @command{ebadexec} points to the problem as follows: @smallexample % @kbd{/bin/ebadexec a.out} /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX STACK segment (truncated address = 0x400000 rounded size = 0x3c00000) of executable file: a.out @end smallexample (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the stack segment.) This can be cured by assigning the @samp{__DATA} segment (virtual) addresses beyond the stack segment. A conservative estimate for this is from address 6000000 (hexadecimal) onwards---this has always worked for me [Toon Moene]: @smallexample % @kbd{g77 -segaddr __DATA 6000000 test.f} % @kbd{ebadexec a.out} ebadexec: file: a.out appears to be executable % @end smallexample Browsing through @file{@value{path-g77}/Makefile.in}, you will find that the @code{f771} program itself also has to be linked with these flags---it has large statically allocated data structures. (Version 0.5.18 reduces this somewhat, but probably not enough.) (The above item was contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).) @node Stack Overflow @subsection Stack Overflow @cindex stack, overflow @cindex segmentation violation @command{g77} code might fail at runtime (probably with a ``segmentation violation'') due to overflowing the stack. This happens most often on systems with an environment that provides substantially more heap space (for use when arbitrarily allocating and freeing memory) than stack space. Often this can be cured by increasing or removing your shell's limit on stack usage, typically using @kbd{limit stacksize} (in @command{csh} and derivatives) or @kbd{ulimit -s} (in @command{sh} and derivatives). Increasing the allowed stack size might, however, require changing some operating system or system configuration parameters. You might be able to work around the problem by compiling with the @option{-fno-automatic} option to reduce stack usage, probably at the expense of speed. @command{g77}, on most machines, puts many variables and arrays on the stack where possible, and can be configured (by changing @code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force smaller-sized entities into static storage (saving on stack space) or permit larger-sized entities to be put on the stack (which can improve run-time performance, as it presents more opportunities for the GBE to optimize the generated code). @emph{Note:} Putting more variables and arrays on the stack might cause problems due to system-dependent limits on stack size. Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no effect on automatic variables and arrays. @xref{But-bugs}, for more information. @emph{Note:} While @code{libg2c} places a limit on the range of Fortran file-unit numbers, the underlying library and operating system might impose different kinds of limits. For example, some systems limit the number of files simultaneously open by a running program. Information on how to increase these limits should be found in your system's documentation. @cindex automatic arrays @cindex arrays, automatic However, if your program uses large automatic arrays (for example, has declarations like @samp{REAL A(N)} where @samp{A} is a local array and @samp{N} is a dummy or @code{COMMON} variable that can have a large value), neither use of @option{-fno-automatic}, nor changing the cut-off point for @command{g77} for using the stack, will solve the problem by changing the placement of these large arrays, as they are @emph{necessarily} automatic. @command{g77} currently provides no means to specify that automatic arrays are to be allocated on the heap instead of the stack. So, other than increasing the stack size, your best bet is to change your source code to avoid large automatic arrays. Methods for doing this currently are outside the scope of this document. (@emph{Note:} If your system puts stack and heap space in the same memory area, such that they are effectively combined, then a stack overflow probably indicates a program that is either simply too large for the system, or buggy.) @node Nothing Happens @subsection Nothing Happens @cindex nothing happens @cindex naming programs @cindex @command{test} programs @cindex programs, @command{test} It is occasionally reported that a ``simple'' program, such as a ``Hello, World!'' program, does nothing when it is run, even though the compiler reported no errors, despite the program containing nothing other than a simple @code{PRINT} statement. This most often happens because the program has been compiled and linked on a UNIX system and named @command{test}, though other names can lead to similarly unexpected run-time behavior on various systems. Essentially this problem boils down to giving your program a name that is already known to the shell you are using to identify some other program, which the shell continues to execute instead of your program when you invoke it via, for example: @smallexample sh# @kbd{test} sh# @end smallexample Under UNIX and many other system, a simple command name invokes a searching mechanism that might well not choose the program located in the current working directory if there is another alternative (such as the @command{test} command commonly installed on UNIX systems). The reliable way to invoke a program you just linked in the current directory under UNIX is to specify it using an explicit pathname, as in: @smallexample sh# @kbd{./test} Hello, World! sh# @end smallexample Users who encounter this problem should take the time to read up on how their shell searches for commands, how to set their search path, and so on. The relevant UNIX commands to learn about include @command{man}, @command{info} (on GNU systems), @command{setenv} (or @command{set} and @command{env}), @command{which}, and @command{find}. @node Strange Behavior at Run Time @subsection Strange Behavior at Run Time @cindex segmentation violation @cindex bus error @cindex overwritten data @cindex data, overwritten @command{g77} code might fail at runtime with ``segmentation violation'', ``bus error'', or even something as subtle as a procedure call overwriting a variable or array element that it is not supposed to touch. These can be symptoms of a wide variety of actual bugs that occurred earlier during the program's run, but manifested themselves as @emph{visible} problems some time later. Overflowing the bounds of an array---usually by writing beyond the end of it---is one of two kinds of bug that often occurs in Fortran code. (Compile your code with the @option{-fbounds-check} option to catch many of these kinds of errors at program run time.) The other kind of bug is a mismatch between the actual arguments passed to a procedure and the dummy arguments as declared by that procedure. Both of these kinds of bugs, and some others as well, can be difficult to track down, because the bug can change its behavior, or even appear to not occur, when using a debugger. That is, these bugs can be quite sensitive to data, including data representing the placement of other data in memory (that is, pointers, such as the placement of stack frames in memory). @command{g77} now offers the ability to catch and report some of these problems at compile, link, or run time, such as by generating code to detect references to beyond the bounds of most arrays (except assumed-size arrays), and checking for agreement between calling and called procedures. Future improvements are likely to be made in the procedure-mismatch area, at least. In the meantime, finding and fixing the programming bugs that lead to these behaviors is, ultimately, the user's responsibility, as difficult as that task can sometimes be. @cindex infinite spaces printed @cindex space, endless printing of @cindex libc, non-ANSI or non-default @cindex C library @cindex linking against non-standard library @cindex Solaris One runtime problem that has been observed might have a simple solution. If a formatted @code{WRITE} produces an endless stream of spaces, check that your program is linked against the correct version of the C library. The configuration process takes care to account for your system's normal @file{libc} not being ANSI-standard, which will otherwise cause this behaviour. If your system's default library is ANSI-standard and you subsequently link against a non-ANSI one, there might be problems such as this one. Specifically, on Solaris2 systems, avoid picking up the @code{BSD} library from @file{/usr/ucblib}. @node Floating-point Errors @subsection Floating-point Errors @cindex floating-point errors @cindex rounding errors @cindex inconsistent floating-point results @cindex results, inconsistent Some programs appear to produce inconsistent floating-point results compiled by @command{g77} versus by other compilers. Often the reason for this behavior is the fact that floating-point values are represented on almost all Fortran systems by @emph{approximations}, and these approximations are inexact even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6, 0.7, 0.8, 0.9, 1.1, and so on. Most Fortran systems, including all current ports of @command{g77}, use binary arithmetic to represent these approximations. Therefore, the exact value of any floating-point approximation as manipulated by @command{g77}-compiled code is representable by adding some combination of the values 1.0, 0.5, 0.25, 0.125, and so on (just keep dividing by two) through the precision of the fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for @code{REAL(KIND=2)}), then multiplying the sum by a integral power of two (in Fortran, by @samp{2**N}) that typically is between -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for @code{REAL(KIND=2)}, then multiplying by -1 if the number is negative. So, a value like 0.2 is exactly represented in decimal---since it is a fraction, @samp{2/10}, with a denominator that is compatible with the base of the number system (base 10). However, @samp{2/10} cannot be represented by any finite number of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot be exactly represented in binary notation. (On the other hand, decimal notation can represent any binary number in a finite number of digits. Decimal notation cannot do so with ternary, or base-3, notation, which would represent floating-point numbers as sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on. After all, no finite number of decimal digits can exactly represent @samp{1/3}. Fortunately, few systems use ternary notation.) Moreover, differences in the way run-time I/O libraries convert between these approximations and the decimal representation often used by programmers and the programs they write can result in apparent differences between results that do not actually exist, or exist to such a small degree that they usually are not worth worrying about. For example, consider the following program: @smallexample PRINT *, 0.2 END @end smallexample When compiled by @command{g77}, the above program might output @samp{0.20000003}, while another compiler might produce a executable that outputs @samp{0.2}. This particular difference is due to the fact that, currently, conversion of floating-point values by the @code{libg2c} library, used by @command{g77}, handles only double-precision values. Since @samp{0.2} in the program is a single-precision value, it is converted to double precision (still in binary notation) before being converted back to decimal. The conversion to binary appends @emph{binary} zero digits to the original value---which, again, is an inexact approximation of 0.2---resulting in an approximation that is much less exact than is connoted by the use of double precision. (The appending of binary zero digits has essentially the same effect as taking a particular decimal approximation of @samp{1/3}, such as @samp{0.3333333}, and appending decimal zeros to it, producing @samp{0.33333330000000000}. Treating the resulting decimal approximation as if it really had 18 or so digits of valid precision would make it seem a very poor approximation of @samp{1/3}.) As a result of converting the single-precision approximation to double precision by appending binary zeros, the conversion of the resulting double-precision value to decimal produces what looks like an incorrect result, when in fact the result is @emph{inexact}, and is probably no less inaccurate or imprecise an approximation of 0.2 than is produced by other compilers that happen to output the converted value as ``exactly'' @samp{0.2}. (Some compilers behave in a way that can make them appear to retain more accuracy across a conversion of a single-precision constant to double precision. @xref{Context-Sensitive Constants}, to see why this practice is illusory and even dangerous.) Note that a more exact approximation of the constant is computed when the program is changed to specify a double-precision constant: @smallexample PRINT *, 0.2D0 END @end smallexample Future versions of @command{g77} and/or @code{libg2c} might convert single-precision values directly to decimal, instead of converting them to double precision first. This would tend to result in output that is more consistent with that produced by some other Fortran implementations. A useful source of information on floating-point computation is David Goldberg, `What Every Computer Scientist Should Know About Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@: 5-48. An online version is available at @uref{http://docs.sun.com/}, and there is a supplemented version, in PostScript form, at @uref{http://www.validgh.com/goldberg/paper.ps}. Information related to the IEEE 754 floating-point standard by a leading light can be found at @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/}; see also slides from the short course referenced from @uref{http://http.cs.berkeley.edu/%7Efateman/}. @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ, and library code for GNU/Linux x86 systems. The supplement to the PostScript-formatted Goldberg document, referenced above, is available in HTML format. See `Differences Among IEEE 754 Implementations' by Doug Priest, available online at @uref{http://www.validgh.com/goldberg/addendum.html}. This document explores some of the issues surrounding computing of extended (80-bit) results on processors such as the x86, especially when those results are arbitrarily truncated to 32-bit or 64-bit values by the compiler as ``spills''. @cindex spills of floating-point results @cindex 80-bit spills @cindex truncation, of floating-point values (@emph{Note:} @command{g77} specifically, and @command{gcc} generally, does arbitrarily truncate 80-bit results during spills as of this writing. It is not yet clear whether a future version of the GNU compiler suite will offer 80-bit spills as an option, or perhaps even as the default behavior.) @c xref would be different between editions: The GNU C library provides routines for controlling the FPU, and other documentation about this. @xref{Floating-point precision}, regarding IEEE 754 conformance. @include bugs.texi @node Missing Features @section Missing Features This section lists features we know are missing from @command{g77}, and which we want to add someday. (There is no priority implied in the ordering below.) @menu GNU Fortran language: * Better Source Model:: * Fortran 90 Support:: * Intrinsics in PARAMETER Statements:: * Arbitrary Concatenation:: * SELECT CASE on CHARACTER Type:: * RECURSIVE Keyword:: * Popular Non-standard Types:: * Full Support for Compiler Types:: * Array Bounds Expressions:: * POINTER Statements:: * Sensible Non-standard Constructs:: * READONLY Keyword:: * FLUSH Statement:: * Expressions in FORMAT Statements:: * Explicit Assembler Code:: * Q Edit Descriptor:: GNU Fortran dialects: * Old-style PARAMETER Statements:: * TYPE and ACCEPT I/O Statements:: * STRUCTURE UNION RECORD MAP:: * OPEN CLOSE and INQUIRE Keywords:: * ENCODE and DECODE:: * AUTOMATIC Statement:: * Suppressing Space Padding:: * Fortran Preprocessor:: * Bit Operations on Floating-point Data:: * Really Ugly Character Assignments:: New facilities: * POSIX Standard:: * Floating-point Exception Handling:: * Nonportable Conversions:: * Large Automatic Arrays:: * Support for Threads:: * Increasing Precision/Range:: * Enabling Debug Lines:: Better diagnostics: * Better Warnings:: * Gracefully Handle Sensible Bad Code:: * Non-standard Conversions:: * Non-standard Intrinsics:: * Modifying DO Variable:: * Better Pedantic Compilation:: * Warn About Implicit Conversions:: * Invalid Use of Hollerith Constant:: * Dummy Array Without Dimensioning Dummy:: * Invalid FORMAT Specifiers:: * Ambiguous Dialects:: * Unused Labels:: * Informational Messages:: Run-time facilities: * Uninitialized Variables at Run Time:: * Portable Unformatted Files:: * Better List-directed I/O:: * Default to Console I/O:: Debugging: * Labels Visible to Debugger:: @end menu @node Better Source Model @subsection Better Source Model @command{g77} needs to provide, as the default source-line model, a ``pure visual'' mode, where the interpretation of a source program in this mode can be accurately determined by a user looking at a traditionally displayed rendition of the program (assuming the user knows whether the program is fixed or free form). The design should assume the user cannot tell tabs from spaces and cannot see trailing spaces on lines, but has canonical tab stops and, for fixed-form source, has the ability to always know exactly where column 72 is (since the Fortran standard itself requires this for fixed-form source). This would change the default treatment of fixed-form source to not treat lines with tabs as if they were infinitely long---instead, they would end at column 72 just as if the tabs were replaced by spaces in the canonical way. As part of this, provide common alternate models (Digital, @command{f2c}, and so on) via command-line options. This includes allowing arbitrarily long lines for free-form source as well as fixed-form source and providing various limits and diagnostics as appropriate. @cindex sequence numbers @cindex columns 73 through 80 Also, @command{g77} should offer, perhaps even default to, warnings when characters beyond the last valid column are anything other than spaces. This would mean code with ``sequence numbers'' in columns 73 through 80 would be rejected, and there's a lot of that kind of code around, but one of the most frequent bugs encountered by new users is accidentally writing fixed-form source code into and beyond column 73. So, maybe the users of old code would be able to more easily handle having to specify, say, a @option{-Wno-col73to80} option. @node Fortran 90 Support @subsection Fortran 90 Support @cindex Fortran 90, support @cindex support, Fortran 90 @command{g77} does not support many of the features that distinguish Fortran 90 (and, now, Fortran 95) from ANSI FORTRAN 77. Some Fortran 90 features are supported, because they make sense to offer even to die-hard users of F77. For example, many of them codify various ways F77 has been extended to meet users' needs during its tenure, so @command{g77} might as well offer them as the primary way to meet those same needs, even if it offers compatibility with one or more of the ways those needs were met by other F77 compilers in the industry. Still, many important F90 features are not supported, because no attempt has been made to research each and every feature and assess its viability in @command{g77}. In the meantime, users who need those features must use Fortran 90 compilers anyway, and the best approach to adding some F90 features to GNU Fortran might well be to fund a comprehensive project to create GNU Fortran 95. @node Intrinsics in PARAMETER Statements @subsection Intrinsics in @code{PARAMETER} Statements @cindex PARAMETER statement @cindex statements, PARAMETER @command{g77} doesn't allow intrinsics in @code{PARAMETER} statements. Related to this, @command{g77} doesn't allow non-integral exponentiation in @code{PARAMETER} statements, such as @samp{PARAMETER (R=2**.25)}. It is unlikely @command{g77} will ever support this feature, as doing it properly requires complete emulation of a target computer's floating-point facilities when building @command{g77} as a cross-compiler. But, if the @command{gcc} back end is enhanced to provide such a facility, @command{g77} will likely use that facility in implementing this feature soon afterwards. @node Arbitrary Concatenation @subsection Arbitrary Concatenation @cindex concatenation @cindex CHARACTER*(*) @cindex run-time, dynamic allocation @command{g77} doesn't support arbitrary operands for concatenation in contexts where run-time allocation is required. For example: @smallexample SUBROUTINE X(A) CHARACTER*(*) A CALL FOO(A // 'suffix') @end smallexample @node SELECT CASE on CHARACTER Type @subsection @code{SELECT CASE} on @code{CHARACTER} Type Character-type selector/cases for @code{SELECT CASE} currently are not supported. @node RECURSIVE Keyword @subsection @code{RECURSIVE} Keyword @cindex RECURSIVE keyword @cindex keywords, RECURSIVE @cindex recursion, lack of @cindex lack of recursion @command{g77} doesn't support the @code{RECURSIVE} keyword that F90 compilers do. Nor does it provide any means for compiling procedures designed to do recursion. All recursive code can be rewritten to not use recursion, but the result is not pretty. @node Increasing Precision/Range @subsection Increasing Precision/Range @cindex -r8 @cindex -qrealsize=8 @cindex -i8 @cindex f2c @cindex increasing precision @cindex precision, increasing @cindex increasing range @cindex range, increasing @cindex Toolpack @cindex Netlib Some compilers, such as @command{f2c}, have an option (@option{-r8}, @option{-qrealsize=8} or similar) that provides automatic treatment of @code{REAL} entities such that they have twice the storage size, and a corresponding increase in the range and precision, of what would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type. (This affects @code{COMPLEX} the same way.) They also typically offer another option (@option{-i8}) to increase @code{INTEGER} entities so they are twice as large (with roughly twice as much range). (There are potential pitfalls in using these options.) @command{g77} does not yet offer any option that performs these kinds of transformations. Part of the problem is the lack of detailed specifications regarding exactly how these options affect the interpretation of constants, intrinsics, and so on. Until @command{g77} addresses this need, programmers could improve the portability of their code by modifying it to not require compile-time options to produce correct results. Some free tools are available which may help, specifically in Toolpack (which one would expect to be sound) and the @file{fortran} section of the Netlib repository. Use of preprocessors can provide a fairly portable means to work around the lack of widely portable methods in the Fortran language itself (though increasing acceptance of Fortran 90 would alleviate this problem). @node Popular Non-standard Types @subsection Popular Non-standard Types @cindex @code{INTEGER*2} support @cindex types, @code{INTEGER*2} @cindex @code{LOGICAL*1} support @cindex types, @code{LOGICAL*1} @command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1}, and similar. In the meantime, version 0.5.18 provides rudimentary support for them. @node Full Support for Compiler Types @subsection Full Support for Compiler Types @cindex @code{REAL*16} support @cindex types, @code{REAL*16} @cindex @code{INTEGER*8} support @cindex types, @code{INTEGER*8} @command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents for @emph{all} applicable back-end-supported types (@code{char}, @code{short int}, @code{int}, @code{long int}, @code{long long int}, and @code{long double}). This means providing intrinsic support, and maybe constant support (using F90 syntax) as well, and, for most machines will result in automatic support of @code{INTEGER*1}, @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16}, and so on. @node Array Bounds Expressions @subsection Array Bounds Expressions @cindex array elements, in adjustable array bounds @cindex function references, in adjustable array bounds @cindex array bounds, adjustable @cindex @code{DIMENSION} statement @cindex statements, @code{DIMENSION} @command{g77} doesn't support more general expressions to dimension arrays, such as array element references, function references, etc. For example, @command{g77} currently does not accept the following: @smallexample SUBROUTINE X(M, N) INTEGER N(10), M(N(2), N(1)) @end smallexample @node POINTER Statements @subsection POINTER Statements @cindex POINTER statement @cindex statements, POINTER @cindex Cray pointers @command{g77} doesn't support pointers or allocatable objects (other than automatic arrays). This set of features is probably considered just behind intrinsics in @code{PARAMETER} statements on the list of large, important things to add to @command{g77}. In the meantime, consider using the @code{INTEGER(KIND=7)} declaration to specify that a variable must be able to hold a pointer. This construct is not portable to other non-GNU compilers, but it is portable to all machines GNU Fortran supports when @command{g77} is used. @xref{Functions and Subroutines}, for information on @code{%VAL()}, @code{%REF()}, and @code{%DESCR()} constructs, which are useful for passing pointers to procedures written in languages other than Fortran. @node Sensible Non-standard Constructs @subsection Sensible Non-standard Constructs @command{g77} rejects things other compilers accept, like @samp{INTRINSIC SQRT,SQRT}. As time permits in the future, some of these things that are easy for humans to read and write and unlikely to be intended to mean something else will be accepted by @command{g77} (though @option{-fpedantic} should trigger warnings about such non-standard constructs). Until @command{g77} no longer gratuitously rejects sensible code, you might as well fix your code to be more standard-conforming and portable. The kind of case that is important to except from the recommendation to change your code is one where following good coding rules would force you to write non-standard code that nevertheless has a clear meaning. For example, when writing an @code{INCLUDE} file that defines a common block, it might be appropriate to include a @code{SAVE} statement for the common block (such as @samp{SAVE /CBLOCK/}), so that variables defined in the common block retain their values even when all procedures declaring the common block become inactive (return to their callers). However, putting @code{SAVE} statements in an @code{INCLUDE} file would prevent otherwise standard-conforming code from also specifying the @code{SAVE} statement, by itself, to indicate that all local variables and arrays are to have the @code{SAVE} attribute. For this reason, @command{g77} already has been changed to allow this combination, because although the general problem of gratuitously rejecting unambiguous and ``safe'' constructs still exists in @command{g77}, this particular construct was deemed useful enough that it was worth fixing @command{g77} for just this case. So, while there is no need to change your code to avoid using this particular construct, there might be other, equally appropriate but non-standard constructs, that you shouldn't have to stop using just because @command{g77} (or any other compiler) gratuitously rejects it. Until the general problem is solved, if you have any such construct you believe is worthwhile using (e.g. not just an arbitrary, redundant specification of an attribute), please submit a bug report with an explanation, so we can consider fixing @command{g77} just for cases like yours. @node READONLY Keyword @subsection @code{READONLY} Keyword @cindex READONLY Support for @code{READONLY}, in @code{OPEN} statements, requires @code{libg2c} support, to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')} does not delete a file opened on a unit with the @code{READONLY} keyword, and perhaps to trigger a fatal diagnostic if a @code{WRITE} or @code{PRINT} to such a unit is attempted. @emph{Note:} It is not sufficient for @command{g77} and @code{libg2c} (its version of @code{libf2c}) to assume that @code{READONLY} does not need some kind of explicit support at run time, due to UNIX systems not (generally) needing it. @command{g77} is not just a UNIX-based compiler! Further, mounting of non-UNIX filesystems on UNIX systems (such as via NFS) might require proper @code{READONLY} support. @cindex SHARED (Similar issues might be involved with supporting the @code{SHARED} keyword.) @node FLUSH Statement @subsection @code{FLUSH} Statement @command{g77} could perhaps use a @code{FLUSH} statement that does what @samp{CALL FLUSH} does, but that supports @samp{*} as the unit designator (same unit as for @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=} specifiers. @node Expressions in FORMAT Statements @subsection Expressions in @code{FORMAT} Statements @cindex FORMAT statement @cindex statements, FORMAT @command{g77} doesn't support @samp{FORMAT(I)} and the like. Supporting this requires a significant redesign or replacement of @code{libg2c}. However, @command{g77} does support this construct when the expression is constant (as of version 0.5.22). For example: @smallexample PARAMETER (IWIDTH = 12) 10 FORMAT (I) @end smallexample Otherwise, at least for output (@code{PRINT} and @code{WRITE}), Fortran code making use of this feature can be rewritten to avoid it by constructing the @code{FORMAT} string in a @code{CHARACTER} variable or array, then using that variable or array in place of the @code{FORMAT} statement label to do the original @code{PRINT} or @code{WRITE}. Many uses of this feature on input can be rewritten this way as well, but not all can. For example, this can be rewritten: @smallexample READ 20, I 20 FORMAT (I) @end smallexample However, this cannot, in general, be rewritten, especially when @code{ERR=} and @code{END=} constructs are employed: @smallexample READ 30, J, I 30 FORMAT (I) @end smallexample @node Explicit Assembler Code @subsection Explicit Assembler Code @command{g77} needs to provide some way, a la @command{gcc}, for @command{g77} code to specify explicit assembler code. @node Q Edit Descriptor @subsection Q Edit Descriptor @cindex FORMAT statement @cindex Q edit descriptor @cindex edit descriptor, Q The @code{Q} edit descriptor in @code{FORMAT}s isn't supported. (This is meant to get the number of characters remaining in an input record.) Supporting this requires a significant redesign or replacement of @code{libg2c}. A workaround might be using internal I/O or the stream-based intrinsics. @xref{FGetC Intrinsic (subroutine)}. @node Old-style PARAMETER Statements @subsection Old-style PARAMETER Statements @cindex PARAMETER statement @cindex statements, PARAMETER @command{g77} doesn't accept @samp{PARAMETER I=1}. Supporting this obsolete form of the @code{PARAMETER} statement would not be particularly hard, as most of the parsing code is already in place and working. Until time/money is spent implementing it, you might as well fix your code to use the standard form, @samp{PARAMETER (I=1)} (possibly needing @samp{INTEGER I} preceding the @code{PARAMETER} statement as well, otherwise, in the obsolete form of @code{PARAMETER}, the type of the variable is set from the type of the constant being assigned to it). @node TYPE and ACCEPT I/O Statements @subsection @code{TYPE} and @code{ACCEPT} I/O Statements @cindex TYPE statement @cindex statements, TYPE @cindex ACCEPT statement @cindex statements, ACCEPT @command{g77} doesn't support the I/O statements @code{TYPE} and @code{ACCEPT}. These are common extensions that should be easy to support, but also are fairly easy to work around in user code. Generally, any @samp{TYPE fmt,list} I/O statement can be replaced by @samp{PRINT fmt,list}. And, any @samp{ACCEPT fmt,list} statement can be replaced by @samp{READ fmt,list}. @node STRUCTURE UNION RECORD MAP @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP} @cindex STRUCTURE statement @cindex statements, STRUCTURE @cindex UNION statement @cindex statements, UNION @cindex RECORD statement @cindex statements, RECORD @cindex MAP statement @cindex statements, MAP @command{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}. This set of extensions is quite a bit lower on the list of large, important things to add to @command{g77}, partly because it requires a great deal of work either upgrading or replacing @code{libg2c}. @node OPEN CLOSE and INQUIRE Keywords @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords @cindex disposition of files @cindex OPEN statement @cindex statements, OPEN @cindex CLOSE statement @cindex statements, CLOSE @cindex INQUIRE statement @cindex statements, INQUIRE @command{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements. These extensions are easy to add to @command{g77} itself, but require much more work on @code{libg2c}. @cindex FORM='PRINT' @cindex ANS carriage control @cindex carriage control @pindex asa @pindex fpr @command{g77} doesn't support @code{FORM='PRINT'} or an equivalent to translate the traditional `carriage control' characters in column 1 of output to use backspaces, carriage returns and the like. However programs exist to translate them in output files (or standard output). These are typically called either @command{fpr} or @command{asa}. You can get a version of @command{asa} from @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU systems which will probably build easily on other systems. Alternatively, @command{fpr} is in BSD distributions in various archive sites. @c (Can both programs can be used in a pipeline, @c with a named input file, @c and/or with a named output file???) @node ENCODE and DECODE @subsection @code{ENCODE} and @code{DECODE} @cindex ENCODE statement @cindex statements, ENCODE @cindex DECODE statement @cindex statements, DECODE @command{g77} doesn't support @code{ENCODE} or @code{DECODE}. These statements are best replaced by READ and WRITE statements involving internal files (CHARACTER variables and arrays). For example, replace a code fragment like @smallexample INTEGER*1 LINE(80) @dots{} DECODE (80, 9000, LINE) A, B, C @dots{} 9000 FORMAT (1X, 3(F10.5)) @end smallexample @noindent with: @smallexample CHARACTER*80 LINE @dots{} READ (UNIT=LINE, FMT=9000) A, B, C @dots{} 9000 FORMAT (1X, 3(F10.5)) @end smallexample Similarly, replace a code fragment like @smallexample INTEGER*1 LINE(80) @dots{} ENCODE (80, 9000, LINE) A, B, C @dots{} 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5)) @end smallexample @noindent with: @smallexample CHARACTER*80 LINE @dots{} WRITE (UNIT=LINE, FMT=9000) A, B, C @dots{} 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5)) @end smallexample It is entirely possible that @code{ENCODE} and @code{DECODE} will be supported by a future version of @command{g77}. @node AUTOMATIC Statement @subsection @code{AUTOMATIC} Statement @cindex @code{AUTOMATIC} statement @cindex statements, @code{AUTOMATIC} @cindex automatic variables @cindex variables, automatic @command{g77} doesn't support the @code{AUTOMATIC} statement that @command{f2c} does. @code{AUTOMATIC} would identify a variable or array as not being @code{SAVE}'d, which is normally the default, but which would be especially useful for code that, @emph{generally}, needed to be compiled with the @option{-fno-automatic} option. @code{AUTOMATIC} also would serve as a hint to the compiler that placing the variable or array---even a very large array--on the stack is acceptable. @code{AUTOMATIC} would not, by itself, designate the containing procedure as recursive. @code{AUTOMATIC} should work syntactically like @code{SAVE}, in that @code{AUTOMATIC} with no variables listed should apply to all pertinent variables and arrays (which would not include common blocks or their members). Variables and arrays denoted as @code{AUTOMATIC} would not be permitted to be initialized via @code{DATA} or other specification of any initial values, requiring explicit initialization, such as via assignment statements. @cindex UNSAVE @cindex STATIC Perhaps @code{UNSAVE} and @code{STATIC}, as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC}, should be provided as well. @node Suppressing Space Padding @subsection Suppressing Space Padding of Source Lines @command{g77} should offer VXT-Fortran-style suppression of virtual spaces at the end of a source line if an appropriate command-line option is specified. This affects cases where a character constant is continued onto the next line in a fixed-form source file, as in the following example: @smallexample 10 PRINT *,'HOW MANY 1 SPACES?' @end smallexample @noindent @command{g77}, and many other compilers, virtually extend the continued line through column 72 with spaces that become part of the character constant, but Digital Fortran normally didn't, leaving only one space between @samp{MANY} and @samp{SPACES?} in the output of the above statement. Fairly recently, at least one version of Digital Fortran was enhanced to provide the other behavior when a command-line option is specified, apparently due to demand from readers of the USENET group @file{comp.lang.fortran} to offer conformance to this widespread practice in the industry. @command{g77} should return the favor by offering conformance to Digital's approach to handling the above example. @node Fortran Preprocessor @subsection Fortran Preprocessor @command{g77} should offer a preprocessor designed specifically for Fortran to replace @samp{cpp -traditional}. There are several out there worth evaluating, at least. Such a preprocessor would recognize Hollerith constants, properly parse comments and character constants, and so on. It might also recognize, process, and thus preprocess files included via the @code{INCLUDE} directive. @node Bit Operations on Floating-point Data @subsection Bit Operations on Floating-point Data @cindex @code{And} intrinsic @cindex intrinsics, @code{And} @cindex @code{Or} intrinsic @cindex intrinsics, @code{Or} @cindex @code{Shift} intrinsic @cindex intrinsics, @code{Shift} @command{g77} does not allow @code{REAL} and other non-integral types for arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}. For example, this program is rejected by @command{g77}, because the intrinsic @code{Iand} does not accept @code{REAL} arguments: @smallexample DATA A/7.54/, B/9.112/ PRINT *, IAND(A, B) END @end smallexample @node Really Ugly Character Assignments @subsection Really Ugly Character Assignments An option such as @option{-fugly-char} should be provided to allow @smallexample REAL*8 A1 DATA A1 / '12345678' / @end smallexample and: @smallexample REAL*8 A1 A1 = 'ABCDEFGH' @end smallexample @node POSIX Standard @subsection @code{POSIX} Standard @command{g77} should support the POSIX standard for Fortran. @node Floating-point Exception Handling @subsection Floating-point Exception Handling @cindex floating-point, exceptions @cindex exceptions, floating-point @cindex FPE handling @cindex NaN values The @command{gcc} backend and, consequently, @command{g77}, currently provides no general control over whether or not floating-point exceptions are trapped or ignored. (Ignoring them typically results in NaN values being propagated in systems that conform to IEEE 754.) The behaviour is normally inherited from the system-dependent startup code, though some targets, such as the Alpha, have code generation options which change the behaviour. Most systems provide some C-callable mechanism to change this; this can be invoked at startup using @command{gcc}'s @code{constructor} attribute. For example, just compiling and linking the following C code with your program will turn on exception trapping for the ``common'' exceptions on a GNU system using glibc 2.2 or newer: @smallexample #define _GNU_SOURCE 1 #include static void __attribute__ ((constructor)) trapfpe () @{ /* Enable some exceptions. At startup all exceptions are masked. */ feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW); @} @end smallexample A convenient trick is to compile this something like: @smallexample gcc -o libtrapfpe.a trapfpe.c @end smallexample and then use it by adding @option{-trapfpe} to the @command{g77} command line when linking. @node Nonportable Conversions @subsection Nonportable Conversions @cindex nonportable conversions @cindex conversions, nonportable @command{g77} doesn't accept some particularly nonportable, silent data-type conversions such as @code{LOGICAL} to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A} is type @code{REAL}), that other compilers might quietly accept. Some of these conversions are accepted by @command{g77} when the @option{-fugly-logint} option is specified. Perhaps it should accept more or all of them. @node Large Automatic Arrays @subsection Large Automatic Arrays @cindex automatic arrays @cindex arrays, automatic Currently, automatic arrays always are allocated on the stack. For situations where the stack cannot be made large enough, @command{g77} should offer a compiler option that specifies allocation of automatic arrays in heap storage. @node Support for Threads @subsection Support for Threads @cindex threads @cindex parallel processing Neither the code produced by @command{g77} nor the @code{libg2c} library are thread-safe, nor does @command{g77} have support for parallel processing (other than the instruction-level parallelism available on some processors). A package such as PVM might help here. @node Enabling Debug Lines @subsection Enabling Debug Lines @cindex debug line @cindex comment line, debug An option such as @option{-fdebug-lines} should be provided to turn fixed-form lines beginning with @samp{D} to be treated as if they began with a space, instead of as if they began with a @samp{C} (as comment lines). @node Better Warnings @subsection Better Warnings Because of how @command{g77} generates code via the back end, it doesn't always provide warnings the user wants. Consider: @smallexample PROGRAM X PRINT *, A END @end smallexample Currently, the above is not flagged as a case of using an uninitialized variable, because @command{g77} generates a run-time library call that looks, to the GBE, like it might actually @emph{modify} @samp{A} at run time. (And, in fact, depending on the previous run-time library call, it would!) Fixing this requires one of the following: @itemize @bullet @item Switch to new library, @code{libg77}, that provides a more ``clean'' interface, vis-a-vis input, output, and modified arguments, so the GBE can tell what's going on. This would provide a pretty big performance improvement, at least theoretically, and, ultimately, in practice, for some types of code. @item Have @command{g77} pass a pointer to a temporary containing a copy of @samp{A}, instead of to @samp{A} itself. The GBE would then complain about the copy operation involving a potentially uninitialized variable. This might also provide a performance boost for some code, because @samp{A} might then end up living in a register, which could help with inner loops. @item Have @command{g77} use a GBE construct similar to @code{ADDR_EXPR} but with extra information on the fact that the item pointed to won't be modified (a la @code{const} in C). Probably the best solution for now, but not quite trivial to implement in the general case. @end itemize @node Gracefully Handle Sensible Bad Code @subsection Gracefully Handle Sensible Bad Code @command{g77} generally should continue processing for warnings and recoverable (user) errors whenever possible---that is, it shouldn't gratuitously make bad or useless code. For example: @smallexample INTRINSIC ZABS CALL FOO(ZABS) END @end smallexample @noindent When compiling the above with @option{-ff2c-intrinsics-disable}, @command{g77} should indeed complain about passing @code{ZABS}, but it still should compile, instead of rejecting the entire @code{CALL} statement. (Some of this is related to improving the compiler internals to improve how statements are analyzed.) @node Non-standard Conversions @subsection Non-standard Conversions @option{-Wconversion} and related should flag places where non-standard conversions are found. Perhaps much of this would be part of @option{-Wugly*}. @node Non-standard Intrinsics @subsection Non-standard Intrinsics @command{g77} needs a new option, like @option{-Wintrinsics}, to warn about use of non-standard intrinsics without explicit @code{INTRINSIC} statements for them. This would help find code that might fail silently when ported to another compiler. @node Modifying DO Variable @subsection Modifying @code{DO} Variable @command{g77} should warn about modifying @code{DO} variables via @code{EQUIVALENCE}. (The internal information gathered to produce this warning might also be useful in setting the internal ``doiter'' flag for a variable or even array reference within a loop, since that might produce faster code someday.) For example, this code is invalid, so @command{g77} should warn about the invalid assignment to @samp{NOTHER}: @smallexample EQUIVALENCE (I, NOTHER) DO I = 1, 100 IF (I.EQ. 10) NOTHER = 20 END DO @end smallexample @node Better Pedantic Compilation @subsection Better Pedantic Compilation @command{g77} needs to support @option{-fpedantic} more thoroughly, and use it only to generate warnings instead of rejecting constructs outright. Have it warn: if a variable that dimensions an array is not a dummy or placed explicitly in @code{COMMON} (F77 does not allow it to be placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements follow statement-function-definition statements; about all sorts of syntactic extensions. @node Warn About Implicit Conversions @subsection Warn About Implicit Conversions @command{g77} needs a @option{-Wpromotions} option to warn if source code appears to expect automatic, silent, and somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)} constants to @code{REAL(KIND=2)} based on context. For example, it would warn about cases like this: @smallexample DOUBLE PRECISION FOO PARAMETER (TZPHI = 9.435784839284958) FOO = TZPHI * 3D0 @end smallexample @node Invalid Use of Hollerith Constant @subsection Invalid Use of Hollerith Constant @command{g77} should disallow statements like @samp{RETURN 2HAB}, which are invalid in both source forms (unlike @samp{RETURN (2HAB)}, which probably still makes no sense but at least can be reliably parsed). Fixed-form processing rejects it, but not free-form, except in a way that is a bit difficult to understand. @node Dummy Array Without Dimensioning Dummy @subsection Dummy Array Without Dimensioning Dummy @command{g77} should complain when a list of dummy arguments containing an adjustable dummy array does not also contain every variable listed in the dimension list of the adjustable array. Currently, @command{g77} does complain about a variable that dimensions an array but doesn't appear in any dummy list or @code{COMMON} area, but this needs to be extended to catch cases where it doesn't appear in every dummy list that also lists any arrays it dimensions. For example, @command{g77} should warn about the entry point @samp{ALT} below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its list of arguments: @smallexample SUBROUTINE PRIMARY(ARRAY, ISIZE) REAL ARRAY(ISIZE) ENTRY ALT(ARRAY) @end smallexample @node Invalid FORMAT Specifiers @subsection Invalid FORMAT Specifiers @command{g77} should check @code{FORMAT} specifiers for validity as it does @code{FORMAT} statements. For example, a diagnostic would be produced for: @smallexample PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!' @end smallexample @node Ambiguous Dialects @subsection Ambiguous Dialects @command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic}, @option{-Wvxt}, @option{-Wf90}, and so on. These would warn about places in the user's source where ambiguities are found, helpful in resolving ambiguities in the program's dialect or dialects. @node Unused Labels @subsection Unused Labels @command{g77} should warn about unused labels when @option{-Wunused} is in effect. @node Informational Messages @subsection Informational Messages @command{g77} needs an option to suppress information messages (notes). @option{-w} does this but also suppresses warnings. The default should be to suppress info messages. Perhaps info messages should simply be eliminated. @node Uninitialized Variables at Run Time @subsection Uninitialized Variables at Run Time @command{g77} needs an option to initialize everything (not otherwise explicitly initialized) to ``weird'' (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and largest-magnitude integers, would help track down references to some kinds of uninitialized variables at run time. Note that use of the options @samp{-O -Wuninitialized} can catch many such bugs at compile time. @node Portable Unformatted Files @subsection Portable Unformatted Files @cindex unformatted files @cindex file formats @cindex binary data @cindex byte ordering @command{g77} has no facility for exchanging unformatted files with systems using different number formats---even differing only in endianness (byte order)---or written by other compilers. Some compilers provide facilities at least for doing byte-swapping during unformatted I/O. It is unrealistic to expect to cope with exchanging unformatted files with arbitrary other compiler runtimes, but the @command{g77} runtime should at least be able to read files written by @command{g77} on systems with different number formats, particularly if they differ only in byte order. In case you do need to write a program to translate to or from @command{g77} (@code{libf2c}) unformatted files, they are written as follows: @table @asis @item Sequential Unformatted sequential records consist of @enumerate @item A number giving the length of the record contents; @item the length of record contents again (for backspace). @end enumerate The record length is of C type @code{long}; this means that it is 8 bytes on 64-bit systems such as Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux. Consequently such files cannot be exchanged between 64-bit and 32-bit systems, even with the same basic number format. @item Direct access Unformatted direct access files form a byte stream of length @var{records}*@var{recl} bytes, where @var{records} is the maximum record number (@code{REC=@var{records}}) written and @var{recl} is the record length in bytes specified in the @code{OPEN} statement (@code{RECL=@var{recl}}). Data appear in the records as determined by the relevant @code{WRITE} statement. Dummy records with arbitrary contents appear in the file in place of records which haven't been written. @end table Thus for exchanging a sequential or direct access unformatted file between big- and little-endian 32-bit systems using IEEE 754 floating point it would be sufficient to reverse the bytes in consecutive words in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX}, @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by @command{g77}. If necessary, it is possible to do byte-oriented i/o with @command{g77}'s @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in Fortran by equivalencing larger sized variables to an @code{INTEGER*1} array or a set of scalars. @cindex HDF @cindex PDB If you need to exchange binary data between arbitrary system and compiler variations, we recommend using a portable binary format with Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/}) or PACT's PDB@footnote{No, not @emph{that} one.} (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike, say, CDF or XDR, HDF-like systems write in the native number formats and only incur overhead when they are read on a system with a different format.) A future @command{g77} runtime library should use such techniques. @node Better List-directed I/O @subsection Better List-directed I/O Values output using list-directed I/O (@samp{PRINT *, R, D}) should be written with a field width, precision, and so on appropriate for the type (precision) of each value. (Currently, no distinction is made between single-precision and double-precision values by @code{libf2c}.) It is likely this item will require the @code{libg77} project to be undertaken. In the meantime, use of formatted I/O is recommended. While it might be of little consolation, @command{g77} does support @samp{FORMAT(F.4)}, for example, as long as @samp{WIDTH} is defined as a named constant (via @code{PARAMETER}). That at least allows some compile-time specification of the precision of a data type, perhaps controlled by preprocessing directives. @node Default to Console I/O @subsection Default to Console I/O The default I/O units, specified by @samp{READ @var{fmt}}, @samp{READ (UNIT=*)}, @samp{WRITE (UNIT=*)}, and @samp{PRINT @var{fmt}}, should not be units 5 (input) and 6 (output), but, rather, unit numbers not normally available for use in statements such as @code{OPEN} and @code{CLOSE}. Changing this would allow a program to connect units 5 and 6 to files via @code{OPEN}, but still use @samp{READ (UNIT=*)} and @samp{PRINT} to do I/O to the ``console''. This change probably requires the @code{libg77} project. @node Labels Visible to Debugger @subsection Labels Visible to Debugger @command{g77} should output debugging information for statements labels, for use by debuggers that know how to support them. Same with weirder things like construct names. It is not yet known if any debug formats or debuggers support these. @node Disappointments @section Disappointments and Misunderstandings These problems are perhaps regrettable, but we don't know any practical way around them for now. @menu * Mangling of Names:: @samp{SUBROUTINE FOO} is given external name @samp{foo_}. * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/} and @samp{SUBROUTINE FOO}. * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}. @end menu @node Mangling of Names @subsection Mangling of Names in Source Code @cindex naming issues @cindex external names @cindex common blocks @cindex name space @cindex underscore The current external-interface design, which includes naming of external procedures, COMMON blocks, and the library interface, has various usability problems, including things like adding underscores where not really necessary (and preventing easier inter-language operability) and yet not providing complete namespace freedom for user C code linked with Fortran apps (due to the naming of functions in the library, among other things). Project GNU should at least get all this ``right'' for systems it fully controls, such as the Hurd, and provide defaults and options for compatibility with existing systems and interoperability with popular existing compilers. @node Multiple Definitions of External Names @subsection Multiple Definitions of External Names @cindex block data @cindex BLOCK DATA statement @cindex statements, BLOCK DATA @cindex @code{COMMON} statement @cindex statements, @code{COMMON} @cindex naming conflicts @command{g77} doesn't allow a common block and an external procedure or @code{BLOCK DATA} to have the same name. Some systems allow this, but @command{g77} does not, to be compatible with @command{f2c}. @command{g77} could special-case the way it handles @code{BLOCK DATA}, since it is not compatible with @command{f2c} in this particular area (necessarily, since @command{g77} offers an important feature here), but it is likely that such special-casing would be very annoying to people with programs that use @samp{EXTERNAL FOO}, with no other mention of @samp{FOO} in the same program unit, to refer to external procedures, since the result would be that @command{g77} would treat these references as requests to force-load BLOCK DATA program units. In that case, if @command{g77} modified names of @code{BLOCK DATA} so they could have the same names as @code{COMMON}, users would find that their programs wouldn't link because the @samp{FOO} procedure didn't have its name translated the same way. (Strictly speaking, @command{g77} could emit a null-but-externally-satisfying definition of @samp{FOO} with its name transformed as if it had been a @code{BLOCK DATA}, but that probably invites more trouble than it's worth.) @node Limitation on Implicit Declarations @subsection Limitation on Implicit Declarations @cindex IMPLICIT CHARACTER*(*) statement @cindex statements, IMPLICIT CHARACTER*(*) @command{g77} disallows @code{IMPLICIT CHARACTER*(*)}. This is not standard-conforming. @node Non-bugs @section Certain Changes We Don't Want to Make This section lists changes that people frequently request, but which we do not make because we think GNU Fortran is better without them. @menu * Backslash in Constants:: Why @samp{'\\'} is a constant that is one, not two, characters long. * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede @samp{COMMON VAR}. * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work. * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a single-precision constant, and might be interpreted as @samp{9.435785} or similar. * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work. * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might not behave as expected. @end menu @node Backslash in Constants @subsection Backslash in Constants @cindex backslash @cindex @command{f77} support @cindex support, @command{f77} In the opinion of many experienced Fortran users, @option{-fno-backslash} should be the default, not @option{-fbackslash}, as currently set by @command{g77}. First of all, you can always specify @option{-fno-backslash} to turn off this processing. Despite not being within the spirit (though apparently within the letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to @option{-fbackslash} because that is what most UNIX @command{f77} commands default to, and apparently lots of code depends on this feature. This is a particularly troubling issue. The use of a C construct in the midst of Fortran code is bad enough, worse when it makes existing Fortran programs stop working (as happens when programs written for non-UNIX systems are ported to UNIX systems with compilers that provide the @option{-fbackslash} feature as the default---sometimes with no option to turn it off). The author of GNU Fortran wished, for reasons of linguistic purity, to make @option{-fno-backslash} the default for GNU Fortran and thus require users of UNIX @command{f77} and @command{f2c} to specify @option{-fbackslash} to get the UNIX behavior. However, the realization that @command{g77} is intended as a replacement for @emph{UNIX} @command{f77}, caused the author to choose to make @command{g77} as compatible with @command{f77} as feasible, which meant making @option{-fbackslash} the default. The primary focus on compatibility is at the source-code level, and the question became ``What will users expect a replacement for @command{f77} to do, by default?'' Although at least one UNIX @command{f77} does not provide @option{-fbackslash} as a default, it appears that the majority of them do, which suggests that the majority of code that is compiled by UNIX @command{f77} compilers expects @option{-fbackslash} to be the default. It is probably the case that more code exists that would @emph{not} work with @option{-fbackslash} in force than code that requires it be in force. However, most of @emph{that} code is not being compiled with @command{f77}, and when it is, new build procedures (shell scripts, makefiles, and so on) must be set up anyway so that they work under UNIX. That makes a much more natural and safe opportunity for non-UNIX users to adapt their build procedures for @command{g77}'s default of @option{-fbackslash} than would exist for the majority of UNIX @command{f77} users who would have to modify existing, working build procedures to explicitly specify @option{-fbackslash} if that was not the default. One suggestion has been to configure the default for @option{-fbackslash} (and perhaps other options as well) based on the configuration of @command{g77}. This is technically quite straightforward, but will be avoided even in cases where not configuring defaults to be dependent on a particular configuration greatly inconveniences some users of legacy code. Many users appreciate the GNU compilers because they provide an environment that is uniform across machines. These users would be inconvenienced if the compiler treated things like the format of the source code differently on certain machines. Occasionally users write programs intended only for a particular machine type. On these occasions, the users would benefit if the GNU Fortran compiler were to support by default the same dialect as the other compilers on that machine. But such applications are rare. And users writing a program to run on more than one type of machine cannot possibly benefit from this kind of compatibility. (This is consistent with the design goals for @command{gcc}. To change them for @command{g77}, you must first change them for @command{gcc}. Do not ask the maintainers of @command{g77} to do this for you, or to disassociate @command{g77} from the widely understood, if not widely agreed-upon, goals for GNU compilers in general.) This is why GNU Fortran does and will treat backslashes in the same fashion on all types of machines (by default). @xref{Direction of Language Development}, for more information on this overall philosophy guiding the development of the GNU Fortran language. Of course, users strongly concerned about portability should indicate explicitly in their build procedures which options are expected by their source code, or write source code that has as few such expectations as possible. For example, avoid writing code that depends on backslash (@samp{\}) being interpreted either way in particular, such as by starting a program unit with: @smallexample CHARACTER BACKSL PARAMETER (BACKSL = '\\') @end smallexample @noindent Then, use concatenation of @samp{BACKSL} anyplace a backslash is desired. In this way, users can write programs which have the same meaning in many Fortran dialects. (However, this technique does not work for Hollerith constants---which is just as well, since the only generally portable uses for Hollerith constants are in places where character constants can and should be used instead, for readability.) @node Initializing Before Specifying @subsection Initializing Before Specifying @cindex initialization, statement placement @cindex placing initialization statements @command{g77} does not allow @samp{DATA VAR/1/} to appear in the source code before @samp{COMMON VAR}, @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on. In general, @command{g77} requires initialization of a variable or array to be specified @emph{after} all other specifications of attributes (type, size, placement, and so on) of that variable or array are specified (though @emph{confirmation} of data type is permitted). It is @emph{possible} @command{g77} will someday allow all of this, even though it is not allowed by the FORTRAN 77 standard. Then again, maybe it is better to have @command{g77} always require placement of @code{DATA} so that it can possibly immediately write constants to the output file, thus saving time and space. That is, @samp{DATA A/1000000*1/} should perhaps always be immediately writable to canonical assembler, unless it's already known to be in a @code{COMMON} area following as-yet-uninitialized stuff, and to do this it cannot be followed by @samp{COMMON A}. @node Context-Sensitive Intrinsicness @subsection Context-Sensitive Intrinsicness @cindex intrinsics, context-sensitive @cindex context-sensitive intrinsics @command{g77} treats procedure references to @emph{possible} intrinsic names as always enabling their intrinsic nature, regardless of whether the @emph{form} of the reference is valid for that intrinsic. For example, @samp{CALL SQRT} is interpreted by @command{g77} as an invalid reference to the @code{SQRT} intrinsic function, because the reference is a subroutine invocation. First, @command{g77} recognizes the statement @samp{CALL SQRT} as a reference to a @emph{procedure} named @samp{SQRT}, not to a @emph{variable} with that name (as it would for a statement such as @samp{V = SQRT}). Next, @command{g77} establishes that, in the program unit being compiled, @code{SQRT} is an intrinsic---not a subroutine that happens to have the same name as an intrinsic (as would be the case if, for example, @samp{EXTERNAL SQRT} was present). Finally, @command{g77} recognizes that the @emph{form} of the reference is invalid for that particular intrinsic. That is, it recognizes that it is invalid for an intrinsic @emph{function}, such as @code{SQRT}, to be invoked as a @emph{subroutine}. At that point, @command{g77} issues a diagnostic. Some users claim that it is ``obvious'' that @samp{CALL SQRT} references an external subroutine of their own, not an intrinsic function. However, @command{g77} knows about intrinsic subroutines, not just functions, and is able to support both having the same names, for example. As a result of this, @command{g77} rejects calls to intrinsics that are not subroutines, and function invocations of intrinsics that are not functions, just as it (and most compilers) rejects invocations of intrinsics with the wrong number (or types) of arguments. So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls a user-written subroutine named @samp{SQRT}. @node Context-Sensitive Constants @subsection Context-Sensitive Constants @cindex constants, context-sensitive @cindex context-sensitive constants @command{g77} does not use context to determine the types of constants or named constants (@code{PARAMETER}), except for (non-standard) typeless constants such as @samp{'123'O}. For example, consider the following statement: @smallexample PRINT *, 9.435784839284958 * 2D0 @end smallexample @noindent @command{g77} will interpret the (truncated) constant @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)}, constant, because the suffix @code{D0} is not specified. As a result, the output of the above statement when compiled by @command{g77} will appear to have ``less precision'' than when compiled by other compilers. In these and other cases, some compilers detect the fact that a single-precision constant is used in a double-precision context and therefore interpret the single-precision constant as if it was @emph{explicitly} specified as a double-precision constant. (This has the effect of appending @emph{decimal}, not @emph{binary}, zeros to the fractional part of the number---producing different computational results.) The reason this misfeature is dangerous is that a slight, apparently innocuous change to the source code can change the computational results. Consider: @smallexample REAL ALMOST, CLOSE DOUBLE PRECISION FIVE PARAMETER (ALMOST = 5.000000000001) FIVE = 5 CLOSE = 5.000000000001 PRINT *, 5.000000000001 - FIVE PRINT *, ALMOST - FIVE PRINT *, CLOSE - FIVE END @end smallexample @noindent Running the above program should result in the same value being printed three times. With @command{g77} as the compiler, it does. However, compiled by many other compilers, running the above program would print two or three distinct values, because in two or three of the statements, the constant @samp{5.000000000001}, which on most systems is exactly equal to @samp{5.} when interpreted as a single-precision constant, is instead interpreted as a double-precision constant, preserving the represented precision. However, this ``clever'' promotion of type does not extend to variables or, in some compilers, to named constants. Since programmers often are encouraged to replace manifest constants or permanently-assigned variables with named constants (@code{PARAMETER} in Fortran), and might need to replace some constants with variables having the same values for pertinent portions of code, it is important that compilers treat code so modified in the same way so that the results of such programs are the same. @command{g77} helps in this regard by treating constants just the same as variables in terms of determining their types in a context-independent way. Still, there is a lot of existing Fortran code that has been written to depend on the way other compilers freely interpret constants' types based on context, so anything @command{g77} can do to help flag cases of this in such code could be very helpful. @node Equivalence Versus Equality @subsection Equivalence Versus Equality @cindex .EQV., with integer operands @cindex comparing logical expressions @cindex logical expressions, comparing Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands is not supported, except via @option{-fugly-logint}, which is not recommended except for legacy code (where the behavior expected by the @emph{code} is assumed). Legacy code should be changed, as resources permit, to use @code{.EQV.} and @code{.NEQV.} instead, as these are permitted by the various Fortran standards. New code should never be written expecting @code{.EQ.} or @code{.NE.} to work if either of its operands is @code{LOGICAL}. The problem with supporting this ``feature'' is that there is unlikely to be consensus on how it works, as illustrated by the following sample program: @smallexample LOGICAL L,M,N DATA L,M,N /3*.FALSE./ IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N' END @end smallexample The issue raised by the above sample program is: what is the precedence of @code{.EQ.} (and @code{.NE.}) when applied to @code{LOGICAL} operands? Some programmers will argue that it is the same as the precedence for @code{.EQ.} when applied to numeric (such as @code{INTEGER}) operands. By this interpretation, the subexpression @samp{M.EQ.N} must be evaluated first in the above program, resulting in a program that, when run, does not execute the @code{PRINT} statement. Other programmers will argue that the precedence is the same as the precedence for @code{.EQV.}, which is restricted by the standards to @code{LOGICAL} operands. By this interpretation, the subexpression @samp{L.AND.M} must be evaluated first, resulting in a program that @emph{does} execute the @code{PRINT} statement. Assigning arbitrary semantic interpretations to syntactic expressions that might legitimately have more than one ``obvious'' interpretation is generally unwise. The creators of the various Fortran standards have done a good job in this case, requiring a distinct set of operators (which have their own distinct precedence) to compare @code{LOGICAL} operands. This requirement results in expression syntax with more certain precedence (without requiring substantial context), making it easier for programmers to read existing code. @command{g77} will avoid muddying up elements of the Fortran language that were well-designed in the first place. (Ask C programmers about the precedence of expressions such as @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell you, without knowing more context, whether the @samp{&} and @samp{-} operators are infix (binary) or unary!) Most dangerous of all is the fact that, even assuming consensus on its meaning, an expression like @samp{L.AND.M.EQ.N}, if it is the result of a typographical error, doesn't @emph{look} like it has such a typo. Even experienced Fortran programmers would not likely notice that @samp{L.AND.M.EQV.N} was, in fact, intended. So, this is a prime example of a circumstance in which a quality compiler diagnoses the code, instead of leaving it up to someone debugging it to know to turn on special compiler options that might diagnose it. @node Order of Side Effects @subsection Order of Side Effects @cindex side effects, order of evaluation @cindex order of evaluation, side effects @command{g77} does not necessarily produce code that, when run, performs side effects (such as those performed by function invocations) in the same order as in some other compiler---or even in the same order as another version, port, or invocation (using different command-line options) of @command{g77}. It is never safe to depend on the order of evaluation of side effects. For example, an expression like this may very well behave differently from one compiler to another: @smallexample J = IFUNC() - IFUNC() @end smallexample @noindent There is no guarantee that @samp{IFUNC} will be evaluated in any particular order. Either invocation might happen first. If @samp{IFUNC} returns 5 the first time it is invoked, and returns 12 the second time, @samp{J} might end up with the value @samp{7}, or it might end up with @samp{-7}. Generally, in Fortran, procedures with side-effects intended to be visible to the caller are best designed as @emph{subroutines}, not functions. Examples of such side-effects include: @itemize @bullet @item The generation of random numbers that are intended to influence return values. @item Performing I/O (other than internal I/O to local variables). @item Updating information in common blocks. @end itemize An example of a side-effect that is not intended to be visible to the caller is a function that maintains a cache of recently calculated results, intended solely to speed repeated invocations of the function with identical arguments. Such a function can be safely used in expressions, because if the compiler optimizes away one or more calls to the function, operation of the program is unaffected (aside from being speeded up). @node Warnings and Errors @section Warning Messages and Error Messages @cindex error messages @cindex warnings vs errors @cindex messages, warning and error The GNU compiler can produce two kinds of diagnostics: errors and warnings. Each kind has a different purpose: @itemize @w{} @item @emph{Errors} report problems that make it impossible to compile your program. GNU Fortran reports errors with the source file name, line number, and column within the line where the problem is apparent. @item @emph{Warnings} report other unusual conditions in your code that @emph{might} indicate a problem, although compilation can (and does) proceed. Warning messages also report the source file name, line number, and column information, but include the text @samp{warning:} to distinguish them from error messages. @end itemize Warnings might indicate danger points where you should check to make sure that your program really does what you intend; or the use of obsolete features; or the use of nonstandard features of GNU Fortran. Many warnings are issued only if you ask for them, with one of the @option{-W} options (for instance, @option{-Wall} requests a variety of useful warnings). @emph{Note:} Currently, the text of the line and a pointer to the column is printed in most @command{g77} diagnostics. @xref{Warning Options,,Options to Request or Suppress Warnings}, for more detail on these and related command-line options. @node Open Questions @chapter Open Questions Please consider offering useful answers to these questions! @itemize @bullet @item @code{LOC()} and other intrinsics are probably somewhat misclassified. Is the a need for more precise classification of intrinsics, and if so, what are the appropriate groupings? Is there a need to individually enable/disable/delete/hide intrinsics from the command line? @end itemize @node Bugs @chapter Reporting Bugs @cindex bugs @cindex reporting bugs Your bug reports play an essential role in making GNU Fortran reliable. When you encounter a problem, the first thing to do is to see if it is already known. @xref{Trouble}. If it isn't known, then you should report the problem. Reporting a bug might help you by bringing a solution to your problem, or it might not. (If it does not, look in the service directory; see @ref{Service}.) In any case, the principal function of a bug report is to help the entire community by making the next version of GNU Fortran work better. Bug reports are your contribution to the maintenance of GNU Fortran. Since the maintainers are very overloaded, we cannot respond to every bug report. However, if the bug has not been fixed, we are likely to send you a patch and ask you to tell us whether it works. In order for a bug report to serve its purpose, you must include the information that makes for fixing the bug. @menu * Criteria: Bug Criteria. Have you really found a bug? * Where: Bug Lists. Where to send your bug report. * Reporting: Bug Reporting. How to report a bug effectively. @end menu @xref{Trouble,,Known Causes of Trouble with GNU Fortran}, for information on problems we already know about. @xref{Service,,How To Get Help with GNU Fortran}, for information on where to ask for help. @node Bug Criteria @section Have You Found a Bug? @cindex bug criteria If you are not sure whether you have found a bug, here are some guidelines: @itemize @bullet @cindex fatal signal @cindex core dump @item If the compiler gets a fatal signal, for any input whatever, that is a compiler bug. Reliable compilers never crash---they just remain obsolete. @cindex invalid assembly code @cindex assembly code, invalid @item If the compiler produces invalid assembly code, for any input whatever, @c (except an @code{asm} statement), that is a compiler bug, unless the compiler reports errors (not just warnings) which would ordinarily prevent the assembler from being run. @cindex undefined behavior @cindex undefined function value @item If the compiler produces valid assembly code that does not correctly execute the input source code, that is a compiler bug. However, you must double-check to make sure, because you might have run into an incompatibility between GNU Fortran and traditional Fortran. @c (@pxref{Incompatibilities}). These incompatibilities might be considered bugs, but they are inescapable consequences of valuable features. Or you might have a program whose behavior is undefined, which happened by chance to give the desired results with another Fortran compiler. It is best to check the relevant Fortran standard thoroughly if it is possible that the program indeed does something undefined. After you have localized the error to a single source line, it should be easy to check for these things. If your program is correct and well defined, you have found a compiler bug. It might help if, in your submission, you identified the specific language in the relevant Fortran standard that specifies the desired behavior, if it isn't likely to be obvious and agreed-upon by all Fortran users. @item If the compiler produces an error message for valid input, that is a compiler bug. @cindex invalid input @item If the compiler does not produce an error message for invalid input, that is a compiler bug. However, you should note that your idea of ``invalid input'' might be someone else's idea of ``an extension'' or ``support for traditional practice''. @item If you are an experienced user of Fortran compilers, your suggestions for improvement of GNU Fortran are welcome in any case. @end itemize Many, perhaps most, bug reports against @command{g77} turn out to be bugs in the user's code. While we find such bug reports educational, they sometimes take a considerable amount of time to track down or at least respond to---time we could be spending making @command{g77}, not some user's code, better. Some steps you can take to verify that the bug is not certainly in the code you're compiling with @command{g77}: @itemize @bullet @item Compile your code using the @command{g77} options @samp{-W -Wall -O}. These options enable many useful warning; the @option{-O} option enables flow analysis that enables the uninitialized-variable warning. If you investigate the warnings and find evidence of possible bugs in your code, fix them first and retry @command{g77}. @item Compile your code using the @command{g77} options @option{-finit-local-zero}, @option{-fno-automatic}, @option{-ffloat-store}, and various combinations thereof. If your code works with any of these combinations, that is not proof that the bug isn't in @command{g77}---a @command{g77} bug exposed by your code might simply be avoided, or have a different, more subtle effect, when different options are used---but it can be a strong indicator that your code is making unwarranted assumptions about the Fortran dialect and/or underlying machine it is being compiled and run on. @xref{Overly Convenient Options,,Overly Convenient Command-Line Options}, for information on the @option{-fno-automatic} and @option{-finit-local-zero} options and how to convert their use into selective changes in your own code. @item @pindex ftnchek Validate your code with @command{ftnchek} or a similar code-checking tool. @command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran} or @uref{ftp://ftp.dsm.fordham.edu}. @pindex make @cindex Makefile example Here are some sample @file{Makefile} rules using @command{ftnchek} ``project'' files to do cross-file checking and @command{sfmakedepend} (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend}) to maintain dependencies automatically. These assume the use of GNU @command{make}. @smallexample # Dummy suffix for ftnchek targets: .SUFFIXES: .chek .PHONY: chekall # How to compile .f files (for implicit rule): FC = g77 # Assume `include' directory: FFLAGS = -Iinclude -g -O -Wall # Flags for ftnchek: CHEK1 = -array=0 -include=includes -noarray CHEK2 = -nonovice -usage=1 -notruncation CHEKFLAGS = $(CHEK1) $(CHEK2) # Run ftnchek with all the .prj files except the one corresponding # to the target's root: %.chek : %.f ; \ ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \ -noextern -library $< # Derive a project file from a source file: %.prj : %.f ; \ ftnchek $(CHEKFLAGS) -noextern -project -library $< # The list of objects is assumed to be in variable OBJS. # Sources corresponding to the objects: SRCS = $(OBJS:%.o=%.f) # ftnchek project files: PRJS = $(OBJS:%.o=%.prj) # Build the program prog: $(OBJS) ; \ $(FC) -o $@ $(OBJS) chekall: $(PRJS) ; \ ftnchek $(CHEKFLAGS) $(PRJS) prjs: $(PRJS) # For Emacs M-x find-tag: TAGS: $(SRCS) ; \ etags $(SRCS) # Rebuild dependencies: depend: ; \ sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1) @end smallexample @item Try your code out using other Fortran compilers, such as @command{f2c}. If it does not work on at least one other compiler (assuming the compiler supports the features the code needs), that is a strong indicator of a bug in the code. However, even if your code works on many compilers @emph{except} @command{g77}, that does @emph{not} mean the bug is in @command{g77}. It might mean the bug is in your code, and that @command{g77} simply exposes it more readily than other compilers. @end itemize @node Bug Lists @section Where to Report Bugs @cindex bug report mailing lists @kindex @value{email-bugs} Send bug reports for GNU Fortran to @email{@value{email-bugs}}. Often people think of posting bug reports to a newsgroup instead of mailing them. This sometimes appears to work, but it has one problem which can be crucial: a newsgroup posting does not contain a mail path back to the sender. Thus, if maintainers need more information, they might be unable to reach you. For this reason, you should always send bug reports by mail to the proper mailing list. As a last resort, send bug reports on paper to: @example GNU Compiler Bugs Free Software Foundation 59 Temple Place - Suite 330 Boston, MA 02111-1307, USA @end example @node Bug Reporting @section How to Report Bugs @cindex compiler bugs, reporting The fundamental principle of reporting bugs usefully is this: @strong{report all the facts}. If you are not sure whether to state a fact or leave it out, state it! Often people omit facts because they think they know what causes the problem and they conclude that some details don't matter. Thus, you might assume that the name of the variable you use in an example does not matter. Well, probably it doesn't, but one cannot be sure. Perhaps the bug is a stray memory reference which happens to fetch from the location where that name is stored in memory; perhaps, if the name were different, the contents of that location would fool the compiler into doing the right thing despite the bug. Play it safe and give a specific, complete example. That is the easiest thing for you to do, and the most helpful. Keep in mind that the purpose of a bug report is to enable someone to fix the bug if it is not known. It isn't very important what happens if the bug is already known. Therefore, always write your bug reports on the assumption that the bug is not known. Sometimes people give a few sketchy facts and ask, ``Does this ring a bell?'' This cannot help us fix a bug, so it is rarely helpful. We respond by asking for enough details to enable us to investigate. You might as well expedite matters by sending them to begin with. (Besides, there are enough bells ringing around here as it is.) Try to make your bug report self-contained. If we have to ask you for more information, it is best if you include all the previous information in your response, as well as the information that was missing. Please report each bug in a separate message. This makes it easier for us to track which bugs have been fixed and to forward your bugs reports to the appropriate maintainer. Do not compress and encode any part of your bug report using programs such as @file{uuencode}. If you do so it will slow down the processing of your bug. If you must submit multiple large files, use @file{shar}, which allows us to read your message without having to run any decompression programs. (As a special exception for GNU Fortran bug-reporting, at least for now, if you are sending more than a few lines of code, if your program's source file format contains ``interesting'' things like trailing spaces or strange characters, or if you need to include binary data files, it is acceptable to put all the files together in a @command{tar} archive, and, whether you need to do that, it is acceptable to then compress the single file (@command{tar} archive or source file) using @command{gzip} and encode it via @command{uuencode}. Do not use any MIME stuff---the current maintainer can't decode this. Using @command{compress} instead of @command{gzip} is acceptable, assuming you have licensed the use of the patented algorithm in @command{compress} from Unisys.) To enable someone to investigate the bug, you should include all these things: @itemize @bullet @item The version of GNU Fortran. You can get this by running @command{g77} with the @option{-v} option. (Ignore any error messages that might be displayed when the linker is run.) Without this, we won't know whether there is any point in looking for the bug in the current version of GNU Fortran. @item @cindex preprocessor @cindex cpp program @cindex programs, cpp @pindex cpp A complete input file that will reproduce the bug. If your source file(s) require preprocessing (for example, their names have suffixes like @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}), and the bug is in the compiler proper (@file{f771}) or in a subsequent phase of processing, run your source file through the C preprocessor by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}. Then, include the contents of @var{newfile} in the bug report. (When you do this, use the same preprocessor options---such as @option{-I}, @option{-D}, and @option{-U}---that you used in actual compilation.) A single statement is not enough of an example. In order to compile it, it must be embedded in a complete file of compiler input. The bug might depend on the details of how this is done. Without a real example one can compile, all anyone can do about your bug report is wish you luck. It would be futile to try to guess how to provoke the bug. For example, bugs in register allocation and reloading can depend on every little detail of the source and include files that trigger them. @item @cindex included files @cindex INCLUDE directive @cindex directive, INCLUDE @cindex #include directive @cindex directive, #include Note that you should include with your bug report any files included by the source file (via the @code{#include} or @code{INCLUDE} directive) that you send, and any files they include, and so on. It is not necessary to replace the @code{#include} and @code{INCLUDE} directives with the actual files in the version of the source file that you send, but it might make submitting the bug report easier in the end. However, be sure to @emph{reproduce} the bug using the @emph{exact} version of the source material you submit, to avoid wild-goose chases. @item The command arguments you gave GNU Fortran to compile that example and observe the bug. For example, did you use @option{-O}? To guarantee you won't omit something important, list all the options. If we were to try to guess the arguments, we would probably guess wrong and then we would not encounter the bug. @item The type of machine you are using, and the operating system name and version number. (Much of this information is printed by @samp{g77 -v}---if you include that, send along any additional info you have that you don't see clearly represented in that output.) @item The operands you gave to the @command{configure} command when you installed the compiler. @item A complete list of any modifications you have made to the compiler source. (We don't promise to investigate the bug unless it happens in an unmodified compiler. But if you've made modifications and don't tell us, then you are sending us on a wild-goose chase.) Be precise about these changes. A description in English is not enough---send a context diff for them. Adding files of your own (such as a machine description for a machine we don't support) is a modification of the compiler source. @item Details of any other deviations from the standard procedure for installing GNU Fortran. @item A description of what behavior you observe that you believe is incorrect. For example, ``The compiler gets a fatal signal,'' or, ``The assembler instruction at line 208 in the output is incorrect.'' Of course, if the bug is that the compiler gets a fatal signal, then one can't miss it. But if the bug is incorrect output, the maintainer might not notice unless it is glaringly wrong. None of us has time to study all the assembler code from a 50-line Fortran program just on the chance that one instruction might be wrong. We need @emph{you} to do this part! Even if the problem you experience is a fatal signal, you should still say so explicitly. Suppose something strange is going on, such as, your copy of the compiler is out of synch, or you have encountered a bug in the C library on your system. (This has happened!) Your copy might crash and the copy here would not. If you @i{said} to expect a crash, then when the compiler here fails to crash, we would know that the bug was not happening. If you don't say to expect a crash, then we would not know whether the bug was happening. We would not be able to draw any conclusion from our observations. If the problem is a diagnostic when building GNU Fortran with some other compiler, say whether it is a warning or an error. Often the observed symptom is incorrect output when your program is run. Sad to say, this is not enough information unless the program is short and simple. None of us has time to study a large program to figure out how it would work if compiled correctly, much less which line of it was compiled wrong. So you will have to do that. Tell us which source line it is, and what incorrect result happens when that line is executed. A person who understands the program can find this as easily as finding a bug in the program itself. @item If you send examples of assembler code output from GNU Fortran, please use @option{-g} when you make them. The debugging information includes source line numbers which are essential for correlating the output with the input. @item If you wish to mention something in the GNU Fortran source, refer to it by context, not by line number. The line numbers in the development sources don't match those in your sources. Your line numbers would convey no convenient information to the maintainers. @item Additional information from a debugger might enable someone to find a problem on a machine which he does not have available. However, you need to think when you collect this information if you want it to have any chance of being useful. @cindex backtrace for bug reports For example, many people send just a backtrace, but that is never useful by itself. A simple backtrace with arguments conveys little about GNU Fortran because the compiler is largely data-driven; the same functions are called over and over for different RTL insns, doing different things depending on the details of the insn. Most of the arguments listed in the backtrace are useless because they are pointers to RTL list structure. The numeric values of the pointers, which the debugger prints in the backtrace, have no significance whatever; all that matters is the contents of the objects they point to (and most of the contents are other such pointers). In addition, most compiler passes consist of one or more loops that scan the RTL insn sequence. The most vital piece of information about such a loop---which insn it has reached---is usually in a local variable, not in an argument. @findex debug_rtx What you need to provide in addition to a backtrace are the values of the local variables for several stack frames up. When a local variable or an argument is an RTX, first print its value and then use the GDB command @command{pr} to print the RTL expression that it points to. (If GDB doesn't run on your machine, use your debugger to call the function @code{debug_rtx} with the RTX as an argument.) In general, whenever a variable is a pointer, its value is no use without the data it points to. @end itemize Here are some things that are not necessary: @itemize @bullet @item A description of the envelope of the bug. Often people who encounter a bug spend a lot of time investigating which changes to the input file will make the bug go away and which changes will not affect it. This is often time consuming and not very useful, because the way we will find the bug is by running a single example under the debugger with breakpoints, not by pure deduction from a series of examples. You might as well save your time for something else. Of course, if you can find a simpler example to report @emph{instead} of the original one, that is a convenience. Errors in the output will be easier to spot, running under the debugger will take less time, etc. Most GNU Fortran bugs involve just one function, so the most straightforward way to simplify an example is to delete all the function definitions except the one where the bug occurs. Those earlier in the file may be replaced by external declarations if the crucial function depends on them. (Exception: inline functions might affect compilation of functions defined later in the file.) However, simplification is not vital; if you don't want to do this, report the bug anyway and send the entire test case you used. @item In particular, some people insert conditionals @samp{#ifdef BUG} around a statement which, if removed, makes the bug not happen. These are just clutter; we won't pay any attention to them anyway. Besides, you should send us preprocessor output, and that can't have conditionals. @item A patch for the bug. A patch for the bug is useful if it is a good one. But don't omit the necessary information, such as the test case, on the assumption that a patch is all we need. We might see problems with your patch and decide to fix the problem another way, or we might not understand it at all. Sometimes with a program as complicated as GNU Fortran it is very hard to construct an example that will make the program follow a certain path through the code. If you don't send the example, we won't be able to construct one, so we won't be able to verify that the bug is fixed. And if we can't understand what bug you are trying to fix, or why your patch should be an improvement, we won't install it. A test case will help us to understand. See @uref{http://gcc.gnu.org/contribute.html} for guidelines on how to make it easy for us to understand and install your patches. @item A guess about what the bug is or what it depends on. Such guesses are usually wrong. Even the maintainer can't guess right about such things without first using the debugger to find the facts. @item A core dump file. We have no way of examining a core dump for your type of machine unless we have an identical system---and if we do have one, we should be able to reproduce the crash ourselves. @end itemize @node Service @chapter How To Get Help with GNU Fortran If you need help installing, using or changing GNU Fortran, there are two ways to find it: @itemize @bullet @item Look in the service directory for someone who might help you for a fee. The service directory is found in the file named @file{SERVICE} in the GNU CC distribution. @item Send a message to @email{@value{email-help}}. @end itemize @end ifset @ifset INTERNALS @node Adding Options @chapter Adding Options @cindex options, adding @cindex adding options To add a new command-line option to @command{g77}, first decide what kind of option you wish to add. Search the @command{g77} and @command{gcc} documentation for one or more options that is most closely like the one you want to add (in terms of what kind of effect it has, and so on) to help clarify its nature. @itemize @bullet @item @emph{Fortran options} are options that apply only when compiling Fortran programs. They are accepted by @command{g77} and @command{gcc}, but they apply only when compiling Fortran programs. @item @emph{Compiler options} are options that apply when compiling most any kind of program. @end itemize @emph{Fortran options} are listed in the file @file{@value{path-g77}/lang-options.h}, which is used during the build of @command{gcc} to build a list of all options that are accepted by at least one language's compiler. This list goes into the @code{documented_lang_options} array in @file{gcc/toplev.c}, which uses this array to determine whether a particular option should be offered to the linked-in front end for processing by calling @code{lang_option_decode}, which, for @command{g77}, is in @file{@value{path-g77}/com.c} and just calls @code{ffe_decode_option}. If the linked-in front end ``rejects'' a particular option passed to it, @file{toplev.c} just ignores the option, because @emph{some} language's compiler is willing to accept it. This allows commands like @samp{gcc -fno-asm foo.c bar.f} to work, even though Fortran compilation does not currently support the @option{-fno-asm} option; even though the @code{f771} version of @code{lang_decode_option} rejects @option{-fno-asm}, @file{toplev.c} doesn't produce a diagnostic because some other language (C) does accept it. This also means that commands like @samp{g77 -fno-asm foo.f} yield no diagnostics, despite the fact that no phase of the command was able to recognize and process @option{-fno-asm}---perhaps a warning about this would be helpful if it were possible. Code that processes Fortran options is found in @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}. This code needs to check positive and negative forms of each option. The defaults for Fortran options are set in their global definitions, also found in @file{@value{path-g77}/top.c}. Many of these defaults are actually macros defined in @file{@value{path-g77}/target.h}, since they might be machine-specific. However, since, in practice, GNU compilers should behave the same way on all configurations (especially when it comes to language constructs), the practice of setting defaults in @file{target.h} is likely to be deprecated and, ultimately, stopped in future versions of @command{g77}. Accessor macros for Fortran options, used by code in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}. @emph{Compiler options} are listed in @file{gcc/toplev.c} in the array @code{f_options}. An option not listed in @code{lang_options} is looked up in @code{f_options} and handled from there. The defaults for compiler options are set in the global definitions for the corresponding variables, some of which are in @file{gcc/toplev.c}. You can set different defaults for @emph{Fortran-oriented} or @emph{Fortran-reticent} compiler options by changing the source code of @command{g77} and rebuilding. How to do this depends on the version of @command{g77}: @table @code @item G77 0.5.24 (EGCS 1.1) @itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95) Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}. (Note that these versions of @command{g77} perform internal consistency checking automatically when the @option{-fversion} option is specified.) @item G77 0.5.23 @itemx G77 0.5.24 (EGCS 1.0) Change the way @code{f771} handles the @option{-fset-g77-defaults} option, which is always provided as the first option when called by @command{g77} or @command{gcc}. This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}. Have it change just the variables that you want to default to a different setting for Fortran compiles compared to compiles of other languages. The @option{-fset-g77-defaults} option is passed to @code{f771} automatically because of the specification information kept in @file{@value{path-g77}/lang-specs.h}. This file tells the @command{gcc} command how to recognize, in this case, Fortran source files (those to be preprocessed, and those that are not), and further, how to invoke the appropriate programs (including @code{f771}) to process those source files. It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults}, @option{-fversion}, and other options are passed, as appropriate, even when the user has not explicitly specified them. Other ``internal'' options such as @option{-quiet} also are passed via this mechanism. @end table @node Projects @chapter Projects @cindex projects If you want to contribute to @command{g77} by doing research, design, specification, documentation, coding, or testing, the following information should give you some ideas. More relevant information might be available from @uref{ftp://alpha.gnu.org/gnu/g77/projects/}. @menu * Efficiency:: Make @command{g77} itself compile code faster. * Better Optimization:: Teach @command{g77} to generate faster code. * Simplify Porting:: Make @command{g77} easier to configure, build, and install. * More Extensions:: Features many users won't know to ask for. * Machine Model:: @command{g77} should better leverage @command{gcc}. * Internals Documentation:: Make maintenance easier. * Internals Improvements:: Make internals more robust. * Better Diagnostics:: Make using @command{g77} on new code easier. @end menu @node Efficiency @section Improve Efficiency @cindex efficiency Don't bother doing any performance analysis until most of the following items are taken care of, because there's no question they represent serious space/time problems, although some of them show up only given certain kinds of (popular) input. @itemize @bullet @item Improve @code{malloc} package and its uses to specify more info about memory pools and, where feasible, use obstacks to implement them. @item Skip over uninitialized portions of aggregate areas (arrays, @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output. This would reduce memory usage for large initialized aggregate areas, even ones with only one initialized element. As of version 0.5.18, a portion of this item has already been accomplished. @item Prescan the statement (in @file{sta.c}) so that the nature of the statement is determined as much as possible by looking entirely at its form, and not looking at any context (previous statements, including types of symbols). This would allow ripping out of the statement-confirmation, symbol retraction/confirmation, and diagnostic inhibition mechanisms. Plus, it would result in much-improved diagnostics. For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic is not a subroutine intrinsic, would result actual error instead of the unimplemented-statement catch-all. @item Throughout @command{g77}, don't pass line/column pairs where a simple @code{ffewhere} type, which points to the error as much as is desired by the configuration, will do, and don't pass @code{ffelexToken} types where a simple @code{ffewhere} type will do. Then, allow new default configuration of @code{ffewhere} such that the source line text is not preserved, and leave it to things like Emacs' next-error function to point to them (now that @samp{next-error} supports column, or, perhaps, character-offset, numbers). The change in calling sequences should improve performance somewhat, as should not having to save source lines. (Whether this whole item will improve performance is questionable, but it should improve maintainability.) @item Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially as regards the assembly output. Some of this might require improving the back end, but lots of improvement in space/time required in @command{g77} itself can be fairly easily obtained without touching the back end. Maybe type-conversion, where necessary, can be speeded up as well in cases like the one shown (converting the @samp{2} into @samp{2.}). @item If analysis shows it to be worthwhile, optimize @file{lex.c}. @item Consider redesigning @file{lex.c} to not need any feedback during tokenization, by keeping track of enough parse state on its own. @end itemize @node Better Optimization @section Better Optimization @cindex optimization, better @cindex code generation, improving Much of this work should be put off until after @command{g77} has all the features necessary for its widespread acceptance as a useful F77 compiler. However, perhaps this work can be done in parallel during the feature-adding work. @itemize @bullet @item Do the equivalent of the trick of putting @samp{extern inline} in front of every function definition in @code{libg2c} and #include'ing the resulting file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions that are at all worth inlining. (Some of this has already been done, such as for integral exponentiation.) @item When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})}, and it's clear that types line up and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL}, make @samp{CHAR_VAR}, not a temporary, be the receiver for @samp{CHAR_FUNC}. (This is now done for @code{COMPLEX} variables.) @item Design and implement Fortran-specific optimizations that don't really belong in the back end, or where the front end needs to give the back end more info than it currently does. @item Design and implement a new run-time library interface, with the code going into @code{libgcc} so no special linking is required to link Fortran programs using standard language features. This library would speed up lots of things, from I/O (using precompiled formats, doing just one, or, at most, very few, calls for arrays or array sections, and so on) to general computing (array/section implementations of various intrinsics, implementation of commonly performed loops that aren't likely to be optimally compiled otherwise, etc.). Among the important things the library would do are: @itemize @bullet @item Be a one-stop-shop-type library, hence shareable and usable by all, in that what are now library-build-time options in @code{libg2c} would be moved at least to the @command{g77} compile phase, if not to finer grains (such as choosing how list-directed I/O formatting is done by default at @code{OPEN} time, for preconnected units via options or even statements in the main program unit, maybe even on a per-I/O basis with appropriate pragma-like devices). @end itemize @item Probably requiring the new library design, change interface to normally have @code{COMPLEX} functions return their values in the way @command{gcc} would if they were declared @code{__complex__ float}, rather than using the mechanism currently used by @code{CHARACTER} functions (whereby the functions are compiled as returning void and their first arg is a pointer to where to store the result). (Don't append underscores to external names for @code{COMPLEX} functions in some cases once @command{g77} uses @command{gcc} rather than @command{f2c} calling conventions.) @item Do something useful with @code{doiter} references where possible. For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within a @code{DO} loop that uses @samp{I} as the iteration variable, and the back end might find that info useful in determining whether it needs to read @samp{I} back into a register after the call. (It normally has to do that, unless it knows @samp{FOO} never modifies its passed-by-reference argument, which is rarely the case for Fortran-77 code.) @end itemize @node Simplify Porting @section Simplify Porting @cindex porting, simplify @cindex simplify porting Making @command{g77} easier to configure, port, build, and install, either as a single-system compiler or as a cross-compiler, would be very useful. @itemize @bullet @item A new library (replacing @code{libg2c}) should improve portability as well as produce more optimal code. Further, @command{g77} and the new library should conspire to simplify naming of externals, such as by removing unnecessarily added underscores, and to reduce/eliminate the possibility of naming conflicts, while making debugger more straightforward. Also, it should make multi-language applications more feasible, such as by providing Fortran intrinsics that get Fortran unit numbers given C @code{FILE *} descriptors. @item Possibly related to a new library, @command{g77} should produce the equivalent of a @command{gcc} @samp{main(argc, argv)} function when it compiles a main program unit, instead of compiling something that must be called by a library implementation of @code{main()}. This would do many useful things such as provide more flexibility in terms of setting up exception handling, not requiring programmers to start their debugging sessions with @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on. @item The GBE needs to understand the difference between alignment requirements and desires. For example, on Intel x86 machines, @command{g77} currently imposes overly strict alignment requirements, due to the back end, but it would be useful for Fortran and C programmers to be able to override these @emph{recommendations} as long as they don't violate the actual processor @emph{requirements}. @end itemize @node More Extensions @section More Extensions @cindex extensions, more These extensions are not the sort of things users ask for ``by name'', but they might improve the usability of @command{g77}, and Fortran in general, in the long run. Some of these items really pertain to improving @command{g77} internals so that some popular extensions can be more easily supported. @itemize @bullet @item Look through all the documentation on the GNU Fortran language, dialects, compiler, missing features, bugs, and so on. Many mentions of incomplete or missing features are sprinkled throughout. It is not worth repeating them here. @item Consider adding a @code{NUMERIC} type to designate typeless numeric constants, named and unnamed. The idea is to provide a forward-looking, effective replacement for things like the old-style @code{PARAMETER} statement when people really need typelessness in a maintainable, portable, clearly documented way. Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER}, and whatever else might come along. (This is not really a call for polymorphism per se, just an ability to express limited, syntactic polymorphism.) @item Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}. @item Support arbitrary file unit numbers, instead of limiting them to 0 through @samp{MXUNIT-1}. (This is a @code{libg2c} issue.) @item @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a later @code{UNIT=} in the first example is invalid. Make sure this is what users of this feature would expect. @item Currently @command{g77} disallows @samp{READ(1'10)} since it is an obnoxious syntax, but supporting it might be pretty easy if needed. More details are needed, such as whether general expressions separated by an apostrophe are supported, or maybe the record number can be a general expression, and so on. @item Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD} fully. Currently there is no support at all for @code{%FILL} in @code{STRUCTURE} and related syntax, whereas the rest of the stuff has at least some parsing support. This requires either major changes to @code{libg2c} or its replacement. @item F90 and @command{g77} probably disagree about label scoping relative to @code{INTERFACE} and @code{END INTERFACE}, and their contained procedure interface bodies (blocks?). @item @code{ENTRY} doesn't support F90 @code{RESULT()} yet, since that was added after S8.112. @item Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent with the final form of the standard (it was vague at S8.112). @item It seems to be an ``open'' question whether a file, immediately after being @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it might be nice to offer an option of opening to ``undefined'' status, requiring an explicit absolute-positioning operation to be performed before any other (besides @code{CLOSE}) to assist in making applications port to systems (some IBM?) that @code{OPEN} to the end of a file or some such thing. @end itemize @node Machine Model @section Machine Model This items pertain to generalizing @command{g77}'s view of the machine model to more fully accept whatever the GBE provides it via its configuration. @itemize @bullet @item Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants exclusively so the target float format need not be required. This means changing the way @command{g77} handles initialization of aggregate areas having more than one type, such as @code{REAL} and @code{INTEGER}, because currently it initializes them as if they were arrays of @code{char} and uses the bit patterns of the constants of the various types in them to determine what to stuff in elements of the arrays. @item Rely more and more on back-end info and capabilities, especially in the area of constants (where having the @command{g77} front-end's IL just store the appropriate tree nodes containing constants might be best). @item Suite of C and Fortran programs that a user/administrator can run on a machine to help determine the configuration for @command{g77} before building and help determine if the compiler works (especially with whatever libraries are installed) after building. @end itemize @node Internals Documentation @section Internals Documentation Better info on how @command{g77} works and how to port it is needed. @xref{Front End}, which contains some information on @command{g77} internals. @node Internals Improvements @section Internals Improvements Some more items that would make @command{g77} more reliable and easier to maintain: @itemize @bullet @item Generally make expression handling focus more on critical syntax stuff, leaving semantics to callers. For example, anything a caller can check, semantically, let it do so, rather than having @file{expr.c} do it. (Exceptions might include things like diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if it seems important to preserve the left-to-right-in-source order of production of diagnostics.) @item Come up with better naming conventions for @option{-D} to establish requirements to achieve desired implementation dialect via @file{proj.h}. @item Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}. @item Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}. @item Check for @code{opANY} in more places in @file{com.c}, @file{std.c}, and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge (after determining if there is indeed no real need for it). @item Utility to read and check @file{bad.def} messages and their references in the code, to make sure calls are consistent with message templates. @item Search and fix @samp{&ffe@dots{}} and similar so that @samp{ffe@dots{}ptr@dots{}} macros are available instead (a good argument for wishing this could have written all this stuff in C++, perhaps). On the other hand, it's questionable whether this sort of improvement is really necessary, given the availability of tools such as Emacs and Perl, which make finding any address-taking of structure members easy enough? @item Some modules truly export the member names of their structures (and the structures themselves), maybe fix this, and fix other modules that just appear to as well (by appending @samp{_}, though it'd be ugly and probably not worth the time). @item Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)} in @file{proj.h} and use them throughout @command{g77} source code (especially in the definitions of access macros in @samp{.h} files) so they can be tailored to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}. @item Decorate throughout with @code{const} and other such stuff. @item All F90 notational derivations in the source code are still based on the S8.112 version of the draft standard. Probably should update to the official standard, or put documentation of the rules as used in the code@dots{}uh@dots{}in the code. @item Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or inside but invoked via paths not involving @code{ffeexpr_lhs} or @code{ffeexpr_rhs}) might be creating things in improper pools, leading to such things staying around too long or (doubtful, but possible and dangerous) not long enough. @item Some @code{ffebld_list_new} (or whatever) calls might not be matched by @code{ffebld_list_bottom} (or whatever) calls, which might someday matter. (It definitely is not a problem just yet.) @item Probably not doing clean things when we fail to @code{EQUIVALENCE} something due to alignment/mismatch or other problems---they end up without @code{ffestorag} objects, so maybe the backend (and other parts of the front end) can notice that and handle like an @code{opANY} (do what it wants, just don't complain or crash). Most of this seems to have been addressed by now, but a code review wouldn't hurt. @end itemize @node Better Diagnostics @section Better Diagnostics These are things users might not ask about, or that need to be looked into, before worrying about. Also here are items that involve reducing unnecessary diagnostic clutter. @itemize @bullet @item When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER} lengths, type classes, and so on), @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies it specifies. @item Speed up and improve error handling for data when repeat-count is specified. For example, don't output 20 unnecessary messages after the first necessary one for: @smallexample INTEGER X(20) CONTINUE DATA (X(I), J= 1, 20) /20*5/ END @end smallexample @noindent (The @code{CONTINUE} statement ensures the @code{DATA} statement is processed in the context of executable, not specification, statements.) @end itemize @include ffe.texi @end ifset @ifset USING @node Diagnostics @chapter Diagnostics @cindex diagnostics Some diagnostics produced by @command{g77} require sufficient explanation that the explanations are given below, and the diagnostics themselves identify the appropriate explanation. Identification uses the GNU Info format---specifically, the @command{info} command that displays the explanation is given within square brackets in the diagnostic. For example: @smallexample foo.f:5: Invalid statement [info -f g77 M FOOEY] @end smallexample More details about the above diagnostic is found in the @command{g77} Info documentation, menu item @samp{M}, submenu item @samp{FOOEY}, which is displayed by typing the UNIX command @samp{info -f g77 M FOOEY}. Other Info readers, such as EMACS, may be just as easily used to display the pertinent node. In the above example, @samp{g77} is the Info document name, @samp{M} is the top-level menu item to select, and, in that node (named @samp{Diagnostics}, the name of this chapter, which is the very text you're reading now), @samp{FOOEY} is the menu item to select. @iftex In this printed version of the @command{g77} manual, the above example points to a section, below, entitled @samp{FOOEY}---though, of course, as the above is just a sample, no such section exists. @end iftex @menu * CMPAMBIG:: Ambiguous use of intrinsic. * EXPIMP:: Intrinsic used explicitly and implicitly. * INTGLOB:: Intrinsic also used as name of global. * LEX:: Various lexer messages * GLOBALS:: Disagreements about globals. * LINKFAIL:: When linking @code{f771} fails. * Y2KBAD:: Use of non-Y2K-compliant intrinsic. @end menu @node CMPAMBIG @section @code{CMPAMBIG} @noindent @smallexample Ambiguous use of intrinsic @var{intrinsic} @dots{} @end smallexample The type of the argument to the invocation of the @var{intrinsic} intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}. Typically, it is @code{COMPLEX(KIND=2)}, also known as @code{DOUBLE COMPLEX}. The interpretation of this invocation depends on the particular dialect of Fortran for which the code was written. Some dialects convert the real part of the argument to @code{REAL(KIND=1)}, thus losing precision; other dialects, and Fortran 90, do no such conversion. So, GNU Fortran rejects such invocations except under certain circumstances, to avoid making an incorrect assumption that results in generating the wrong code. To determine the dialect of the program unit, perhaps even whether that particular invocation is properly coded, determine how the result of the intrinsic is used. The result of @var{intrinsic} is expected (by the original programmer) to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if: @itemize @bullet @item It is passed as an argument to a procedure that explicitly or implicitly declares that argument @code{REAL(KIND=1)}. For example, a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION} statement specifying the dummy argument corresponding to an actual argument of @samp{REAL(Z)}, where @samp{Z} is declared @code{DOUBLE COMPLEX}, strongly suggests that the programmer expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead of @code{REAL(KIND=2)}. @item It is used in a context that would otherwise not include any @code{REAL(KIND=2)} but where treating the @var{intrinsic} invocation as @code{REAL(KIND=2)} would result in unnecessary promotions and (typically) more expensive operations on the wider type. For example: @smallexample DOUBLE COMPLEX Z @dots{} R(1) = T * REAL(Z) @end smallexample The above example suggests the programmer expected the real part of @samp{Z} to be converted to @code{REAL(KIND=1)} before being multiplied by @samp{T} (presumed, along with @samp{R} above, to be type @code{REAL(KIND=1)}). Otherwise, the conversion would have to be delayed until after the multiplication, requiring not only an extra conversion (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more expensive multiplication (a double-precision multiplication instead of a single-precision one). @end itemize The result of @var{intrinsic} is expected (by the original programmer) to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if: @itemize @bullet @item It is passed as an argument to a procedure that explicitly or implicitly declares that argument @code{REAL(KIND=2)}. For example, a procedure specifying a @code{DOUBLE PRECISION} dummy argument corresponding to an actual argument of @samp{REAL(Z)}, where @samp{Z} is declared @code{DOUBLE COMPLEX}, strongly suggests that the programmer expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead of @code{REAL(KIND=1)}. @item It is used in an expression context that includes other @code{REAL(KIND=2)} operands, or is assigned to a @code{REAL(KIND=2)} variable or array element. For example: @smallexample DOUBLE COMPLEX Z DOUBLE PRECISION R, T @dots{} R(1) = T * REAL(Z) @end smallexample The above example suggests the programmer expected the real part of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)} by the @code{REAL()} intrinsic. Otherwise, the conversion would have to be immediately followed by a conversion back to @code{REAL(KIND=2)}, losing the original, full precision of the real part of @code{Z}, before being multiplied by @samp{T}. @end itemize Once you have determined whether a particular invocation of @var{intrinsic} expects the Fortran 90 interpretation, you can: @itemize @bullet @item Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic} is @code{AIMAG}) if it expected the Fortran 90 interpretation. This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is some other type, such as @code{COMPLEX*32}, you should use the appropriate intrinsic, such as the one to convert to @code{REAL*16} (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and @code{QIMAG()} in place of @code{DIMAG()}). @item Change it to @samp{REAL(@var{intrinsic}(@var{expr}))}, otherwise. This converts to @code{REAL(KIND=1)} in all working Fortran compilers. @end itemize If you don't want to change the code, and you are certain that all ambiguous invocations of @var{intrinsic} in the source file have the same expectation regarding interpretation, you can: @itemize @bullet @item Compile with the @command{g77} option @option{-ff90}, to enable the Fortran 90 interpretation. @item Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex}, to enable the non-Fortran-90 interpretations. @end itemize @xref{REAL() and AIMAG() of Complex}, for more information on this issue. Note: If the above suggestions don't produce enough evidence as to whether a particular program expects the Fortran 90 interpretation of this ambiguous invocation of @var{intrinsic}, there is one more thing you can try. If you have access to most or all the compilers used on the program to create successfully tested and deployed executables, read the documentation for, and @emph{also} test out, each compiler to determine how it treats the @var{intrinsic} intrinsic in this case. (If all the compilers don't agree on an interpretation, there might be lurking bugs in the deployed versions of the program.) The following sample program might help: @cindex JCB003 program @smallexample PROGRAM JCB003 C C Written by James Craig Burley 1997-02-23. C C Determine how compilers handle non-standard REAL C and AIMAG on DOUBLE COMPLEX operands. C DOUBLE COMPLEX Z REAL R Z = (3.3D0, 4.4D0) R = Z CALL DUMDUM(Z, R) R = REAL(Z) - R IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90' IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90' R = 4.4D0 CALL DUMDUM(Z, R) R = AIMAG(Z) - R IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90' IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90' END C C Just to make sure compiler doesn't use naive flow C analysis to optimize away careful work above, C which might invalidate results.... C SUBROUTINE DUMDUM(Z, R) DOUBLE COMPLEX Z REAL R END @end smallexample If the above program prints contradictory results on a particular compiler, run away! @node EXPIMP @section @code{EXPIMP} @noindent @smallexample Intrinsic @var{intrinsic} referenced @dots{} @end smallexample The @var{intrinsic} is explicitly declared in one program unit in the source file and implicitly used as an intrinsic in another program unit in the same source file. This diagnostic is designed to catch cases where a program might depend on using the name @var{intrinsic} as an intrinsic in one program unit and as a global name (such as the name of a subroutine or function) in another, but @command{g77} recognizes the name as an intrinsic in both cases. After verifying that the program unit making implicit use of the intrinsic is indeed written expecting the intrinsic, add an @samp{INTRINSIC @var{intrinsic}} statement to that program unit to prevent this warning. This and related warnings are disabled by using the @option{-Wno-globals} option when compiling. Note that this warning is not issued for standard intrinsics. Standard intrinsics include those described in the FORTRAN 77 standard and, if @option{-ff90} is specified, those described in the Fortran 90 standard. Such intrinsics are not as likely to be confused with user procedures as intrinsics provided as extensions to the standard by @command{g77}. @node INTGLOB @section @code{INTGLOB} @noindent @smallexample Same name `@var{intrinsic}' given @dots{} @end smallexample The name @var{intrinsic} is used for a global entity (a common block or a program unit) in one program unit and implicitly used as an intrinsic in another program unit. This diagnostic is designed to catch cases where a program intends to use a name entirely as a global name, but @command{g77} recognizes the name as an intrinsic in the program unit that references the name, a situation that would likely produce incorrect code. For example: @smallexample INTEGER FUNCTION TIME() @dots{} END @dots{} PROGRAM SAMP INTEGER TIME PRINT *, 'Time is ', TIME() END @end smallexample The above example defines a program unit named @samp{TIME}, but the reference to @samp{TIME} in the main program unit @samp{SAMP} is normally treated by @command{g77} as a reference to the intrinsic @code{TIME()} (unless a command-line option that prevents such treatment has been specified). As a result, the program @samp{SAMP} will @emph{not} invoke the @samp{TIME} function in the same source file. Since @command{g77} recognizes @code{libU77} procedures as intrinsics, and since some existing code uses the same names for its own procedures as used by some @code{libU77} procedures, this situation is expected to arise often enough to make this sort of warning worth issuing. After verifying that the program unit making implicit use of the intrinsic is indeed written expecting the intrinsic, add an @samp{INTRINSIC @var{intrinsic}} statement to that program unit to prevent this warning. Or, if you believe the program unit is designed to invoke the program-defined procedure instead of the intrinsic (as recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}} statement to the program unit that references the name to prevent this warning. This and related warnings are disabled by using the @option{-Wno-globals} option when compiling. Note that this warning is not issued for standard intrinsics. Standard intrinsics include those described in the FORTRAN 77 standard and, if @option{-ff90} is specified, those described in the Fortran 90 standard. Such intrinsics are not as likely to be confused with user procedures as intrinsics provided as extensions to the standard by @command{g77}. @node LEX @section @code{LEX} @noindent @smallexample Unrecognized character @dots{} Invalid first character @dots{} Line too long @dots{} Non-numeric character @dots{} Continuation indicator @dots{} Label at @dots{} invalid with continuation line indicator @dots{} Character constant @dots{} Continuation line @dots{} Statement at @dots{} begins with invalid token @end smallexample Although the diagnostics identify specific problems, they can be produced when general problems such as the following occur: @itemize @bullet @item The source file contains something other than Fortran code. If the code in the file does not look like many of the examples elsewhere in this document, it might not be Fortran code. (Note that Fortran code often is written in lower case letters, while the examples in this document use upper case letters, for stylistic reasons.) For example, if the file contains lots of strange-looking characters, it might be APL source code; if it contains lots of parentheses, it might be Lisp source code; if it contains lots of bugs, it might be C++ source code. @item The source file contains free-form Fortran code, but @option{-ffree-form} was not specified on the command line to compile it. Free form is a newer form for Fortran code. The older, classic form is called fixed form. @cindex continuation character @cindex characters, continuation Fixed-form code is visually fairly distinctive, because numerical labels and comments are all that appear in the first five columns of a line, the sixth column is reserved to denote continuation lines, and actual statements start at or beyond column 7. Spaces generally are not significant, so if you see statements such as @samp{REALX,Y} and @samp{DO10I=1,100}, you are looking at fixed-form code. @cindex * @cindex asterisk Comment lines are indicated by the letter @samp{C} or the symbol @samp{*} in column 1. @cindex trailing comment @cindex comment @cindex characters, comment @cindex ! @cindex exclamation point (Some code uses @samp{!} or @samp{/*} to begin in-line comments, which many compilers support.) Free-form code is distinguished from fixed-form source primarily by the fact that statements may start anywhere. (If lots of statements start in columns 1 through 6, that's a strong indicator of free-form source.) Consecutive keywords must be separated by spaces, so @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is. There are no comment lines per se, but @samp{!} starts a comment anywhere in a line (other than within a character or Hollerith constant). @xref{Source Form}, for more information. @item The source file is in fixed form and has been edited without sensitivity to the column requirements. Statements in fixed-form code must be entirely contained within columns 7 through 72 on a given line. Starting them ``early'' is more likely to result in diagnostics than finishing them ``late'', though both kinds of errors are often caught at compile time. For example, if the following code fragment is edited by following the commented instructions literally, the result, shown afterward, would produce a diagnostic when compiled: @smallexample C On XYZZY systems, remove "C" on next line: C CALL XYZZY_RESET @end smallexample The result of editing the above line might be: @smallexample C On XYZZY systems, remove "C" on next line: CALL XYZZY_RESET @end smallexample However, that leaves the first @samp{C} in the @code{CALL} statement in column 6, making it a comment line, which is not really what the author intended, and which is likely to result in one of the above-listed diagnostics. @emph{Replacing} the @samp{C} in column 1 with a space is the proper change to make, to ensure the @code{CALL} keyword starts in or after column 7. Another common mistake like this is to forget that fixed-form source lines are significant through only column 72, and that, normally, any text beyond column 72 is ignored or is diagnosed at compile time. @xref{Source Form}, for more information. @item The source file requires preprocessing, and the preprocessing is not being specified at compile time. A source file containing lines beginning with @code{#define}, @code{#include}, @code{#if}, and so on is likely one that requires preprocessing. If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR}, the file normally will be compiled @emph{without} preprocessing by @command{g77}. Change the file's suffix from @samp{.f} to @samp{.F} (or, on systems with case-insensitive file names, to @samp{.fpp} or @samp{.FPP}), from @samp{.for} to @samp{.fpp}, or from @samp{.FOR} to @samp{.FPP}. @command{g77} compiles files with such names @emph{with} preprocessing. @pindex cpp @cindex preprocessor @cindex cpp program @cindex programs, cpp @cindex @option{-x f77-cpp-input} option @cindex options, @option{-x f77-cpp-input} Or, learn how to use @command{gcc}'s @option{-x} option to specify the language @samp{f77-cpp-input} for Fortran files that require preprocessing. @xref{Overall Options,,Options Controlling the Kind of Output,gcc,Using the GNU Compiler Collection (GCC)}. @item The source file is preprocessed, and the results of preprocessing result in syntactic errors that are not necessarily obvious to someone examining the source file itself. Examples of errors resulting from preprocessor macro expansion include exceeding the line-length limit, improperly starting, terminating, or incorporating the apostrophe or double-quote in a character constant, improperly forming a Hollerith constant, and so on. @xref{Overall Options,,Options Controlling the Kind of Output}, for suggestions about how to use, and not use, preprocessing for Fortran code. @end itemize @node GLOBALS @section @code{GLOBALS} @noindent @smallexample Global name @var{name} defined at @dots{} already defined@dots{} Global name @var{name} at @dots{} has different type@dots{} Too many arguments passed to @var{name} at @dots{} Too few arguments passed to @var{name} at @dots{} Argument #@var{n} of @var{name} is @dots{} @end smallexample These messages all identify disagreements about the global procedure named @var{name} among different program units (usually including @var{name} itself). Whether a particular disagreement is reported as a warning or an error can depend on the relative order of the disagreeing portions of the source file. Disagreements between a procedure invocation and the @emph{subsequent} procedure itself are, usually, diagnosed as errors when the procedure itself @emph{precedes} the invocation. Other disagreements are diagnosed via warnings. @cindex forward references @cindex in-line code @cindex compilation, in-line This distinction, between warnings and errors, is due primarily to the present tendency of the @command{gcc} back end to inline only those procedure invocations that are @emph{preceded} by the corresponding procedure definitions. If the @command{gcc} back end is changed to inline ``forward references'', in which invocations precede definitions, the @command{g77} front end will be changed to treat both orderings as errors, accordingly. The sorts of disagreements that are diagnosed by @command{g77} include whether a procedure is a subroutine or function; if it is a function, the type of the return value of the procedure; the number of arguments the procedure accepts; and the type of each argument. Disagreements regarding global names among program units in a Fortran program @emph{should} be fixed in the code itself. However, if that is not immediately practical, and the code has been working for some time, it is possible it will work when compiled with the @option{-fno-globals} option. The @option{-fno-globals} option causes these diagnostics to all be warnings and disables all inlining of references to global procedures (to avoid subsequent compiler crashes and bad-code generation). Use of the @option{-Wno-globals} option as well as @option{-fno-globals} suppresses all of these diagnostics. (@option{-Wno-globals} by itself disables only the warnings, not the errors.) After using @option{-fno-globals} to work around these problems, it is wise to stop using that option and address them by fixing the Fortran code, because such problems, while they might not actually result in bugs on some systems, indicate that the code is not as portable as it could be. In particular, the code might appear to work on a particular system, but have bugs that affect the reliability of the data without exhibiting any other outward manifestations of the bugs. @node LINKFAIL @section @code{LINKFAIL} @noindent On AIX 4.1, @command{g77} might not build with the native (non-GNU) tools due to a linker bug in coping with the @option{-bbigtoc} option which leads to a @samp{Relocation overflow} error. The GNU linker is not recommended on current AIX versions, though; it was developed under a now-unsupported version. This bug is said to be fixed by `update PTF U455193 for APAR IX75823'. Compiling with @option{-mminimal-toc} might solve this problem, e.g.@: by adding @smallexample BOOT_CFLAGS='-mminimal-toc -O2 -g' @end smallexample to the @code{make bootstrap} command line. @node Y2KBAD @section @code{Y2KBAD} @cindex Y2K compliance @cindex Year 2000 compliance @noindent @smallexample Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{} @end smallexample This diagnostic indicates that the specific intrinsic invoked by the name @var{name} is known to have an interface that is not Year-2000 (Y2K) compliant. @xref{Year 2000 (Y2K) Problems}. @end ifset @node Index @unnumbered Index @printindex cp @bye