1 \input texinfo @c -*-texinfo-*-
5 @set last-update 2001-11-14
6 @set copyrights-g77 1995,1996,1997,1998,1999,2000,2001
10 @c This tells @include'd files that they're part of the overall G77 doc
11 @c set. (They might be part of a higher-level doc set too.)
14 @c @setfilename useg77.info
15 @c @setfilename portg77.info
16 @c To produce the full manual, use the "g77.info" setfilename, and
17 @c make sure the following do NOT begin with '@c' (and the @clear lines DO)
20 @c To produce a user-only manual, use the "useg77.info" setfilename, and
21 @c make sure the following does NOT begin with '@c':
23 @c To produce a porter-only manual, use the "portg77.info" setfilename,
24 @c and make sure the following does NOT begin with '@c':
27 @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi)
30 @c i also commented out the finalout command, so if there *are* any
31 @c overfulls, you'll (hopefully) see the rectangle in the right hand
32 @c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi).
35 @macro gcctabopt{body}
38 @macro gccoptlist{body}
43 @c Makeinfo handles the above macro OK, TeX needs manual line breaks;
44 @c they get lost at some point in handling the macro. But if @macro is
45 @c used here rather than @alias, it produces double line breaks.
56 @settitle Using and Porting GNU Fortran
59 @c seems reasonable to assume at least one of INTERNALS or USING is set...
61 @settitle Using GNU Fortran
64 @settitle Porting GNU Fortran
66 @c then again, have some fun
69 @settitle Doing Squat with GNU Fortran
77 @c Cause even numbered pages to be printed on the left hand side of
78 @c the page and odd numbered pages to be printed on the right hand
79 @c side of the page. Using this, you can print on both sides of a
80 @c sheet of paper and have the text on the same part of the sheet.
82 @c The text on right hand pages is pushed towards the right hand
83 @c margin and the text on left hand pages is pushed toward the left
85 @c (To provide the reverse effect, set bindingoffset to -0.75in.)
88 @c \global\bindingoffset=0.75in
89 @c \global\normaloffset =0.75in
93 @dircategory Programming
95 * g77: (g77). The GNU Fortran compiler.
99 This file documents the use and the internals of the GNU Fortran (@command{g77})
101 It corresponds to the @value{which-g77} version of @command{g77}.
105 This file documents the internals of the GNU Fortran (@command{g77}) compiler.
106 It corresponds to the @value{which-g77} version of @command{g77}.
109 This file documents the use of the GNU Fortran (@command{g77}) compiler.
110 It corresponds to the @value{which-g77} version of @command{g77}.
113 Published by the Free Software Foundation
114 59 Temple Place - Suite 330
115 Boston, MA 02111-1307 USA
117 Copyright (C) @value{copyrights-g77} Free Software Foundation, Inc.
120 Permission is granted to copy, distribute and/or modify this document
121 under the terms of the GNU Free Documentation License, Version 1.1 or
122 any later version published by the Free Software Foundation; with the
123 Invariant Sections being ``GNU General Public License'' and ``Funding
124 Free Software'', the Front-Cover
125 texts being (a) (see below), and with the Back-Cover Texts being (b)
126 (see below). A copy of the license is included in the section entitled
127 ``GNU Free Documentation License''.
129 (a) The FSF's Front-Cover Text is:
133 (b) The FSF's Back-Cover Text is:
135 You have freedom to copy and modify this GNU Manual, like GNU
136 software. Copies published by the Free Software Foundation raise
137 funds for GNU development.
140 Contributed by James Craig Burley (@email{@value{email-burley}}).
141 Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
142 was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).
144 @setchapternewpage odd
149 @center @titlefont{Using and Porting GNU Fortran}
154 @title Using GNU Fortran
157 @title Porting GNU Fortran
160 @center James Craig Burley
162 @center Last updated @value{last-update}
164 @center for version @value{version-g77}
166 @vskip 0pt plus 1filll
167 Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.
169 For the @value{which-g77} Version*
171 Published by the Free Software Foundation @*
172 59 Temple Place - Suite 330@*
173 Boston, MA 02111-1307, USA@*
174 @c Last printed ??ber, 19??.@*
175 @c Printed copies are available for $? each.@*
178 Permission is granted to copy, distribute and/or modify this document
179 under the terms of the GNU Free Documentation License, Version 1.1 or
180 any later version published by the Free Software Foundation; with the
181 Invariant Sections being ``GNU General Public License'' and ``Funding
182 Free Software'', the Front-Cover
183 texts being (a) (see below), and with the Back-Cover Texts being (b)
184 (see below). A copy of the license is included in the section entitled
185 ``GNU Free Documentation License''.
187 (a) The FSF's Front-Cover Text is:
191 (b) The FSF's Back-Cover Text is:
193 You have freedom to copy and modify this GNU Manual, like GNU
194 software. Copies published by the Free Software Foundation raise
195 funds for GNU development.
203 @node Top, Copying,, (DIR)
209 This manual documents how to run, install and port @command{g77},
210 as well as its new features and incompatibilities,
211 and how to report bugs.
212 It corresponds to the @value{which-g77} version of @command{g77}.
217 This manual documents how to run and install @command{g77},
218 as well as its new features and incompatibilities, and how to report
220 It corresponds to the @value{which-g77} version of @command{g77}.
223 This manual documents how to port @command{g77},
224 as well as its new features and incompatibilities,
225 and how to report bugs.
226 It corresponds to the @value{which-g77} version of @command{g77}.
232 @emph{Warning:} This document is still under development,
233 and might not accurately reflect the @command{g77} code base
234 of which it is a part.
235 Efforts are made to keep it somewhat up-to-date,
236 but they are particularly concentrated
237 on any version of this information
238 that is distributed as part of a @emph{released} @command{g77}.
240 In particular, while this document is intended to apply to
241 the @value{which-g77} version of @command{g77},
242 only an official @emph{release} of that version
243 is expected to contain documentation that is
244 most consistent with the @command{g77} product in that version.
248 * Copying:: GNU General Public License says
249 how you can copy and share GNU Fortran.
250 * GNU Free Documentation License::
251 How you can copy and share this manual.
252 * Contributors:: People who have contributed to GNU Fortran.
253 * Funding:: How to help assure continued work for free software.
254 * Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
256 * Getting Started:: Finding your way around this manual.
257 * What is GNU Fortran?:: How @command{g77} fits into the universe.
258 * G77 and GCC:: You can compile Fortran, C, or other programs.
259 * Invoking G77:: Command options supported by @command{g77}.
260 * News:: News about recent releases of @command{g77}.
261 * Changes:: User-visible changes to recent releases of @command{g77}.
262 * Language:: The GNU Fortran language.
263 * Compiler:: The GNU Fortran compiler.
264 * Other Dialects:: Dialects of Fortran supported by @command{g77}.
265 * Other Compilers:: Fortran compilers other than @command{g77}.
266 * Other Languages:: Languages other than Fortran.
267 * Debugging and Interfacing:: How @command{g77} generates code.
268 * Collected Fortran Wisdom:: How to avoid Trouble.
269 * Trouble:: If you have trouble with GNU Fortran.
270 * Open Questions:: Things we'd like to know.
271 * Bugs:: How, why, and where to report bugs.
272 * Service:: How to find suppliers of support for GNU Fortran.
275 * Adding Options:: Guidance on teaching @command{g77} about new options.
276 * Projects:: Projects for @command{g77} internals hackers.
277 * Front End:: Design and implementation of the @command{g77} front end.
280 * M: Diagnostics. Diagnostics produced by @command{g77}.
282 * Index:: Index of concepts and symbol names.
284 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
291 @unnumbered Contributors to GNU Fortran
295 In addition to James Craig Burley, who wrote the front end,
296 many people have helped create and improve GNU Fortran.
300 The packaging and compiler portions of GNU Fortran are based largely
301 on the GNU CC compiler.
302 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
303 for more information.
306 The run-time library used by GNU Fortran is a repackaged version
307 of the @code{libf2c} library (combined from the @code{libF77} and
308 @code{libI77} libraries) provided as part of @command{f2c}, available for
309 free from @code{netlib} sites on the Internet.
312 Cygnus Support and The Free Software Foundation contributed
313 significant money and/or equipment to Craig's efforts.
316 The following individuals served as alpha testers prior to @command{g77}'s
317 public release. This work consisted of testing, researching, sometimes
318 debugging, and occasionally providing small amounts of code and fixes
319 for @command{g77}, plus offering plenty of helpful advice to Craig:
325 Dr.@: Mark Fernyhough
327 Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
331 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
333 Dr.@: A. O. V. Le Blanc
355 Dave Love (@email{d.love@@dl.ac.uk})
356 wrote the libU77 part of the run-time library.
359 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
360 provided the patch to add rudimentary support
361 for @code{INTEGER*1}, @code{INTEGER*2}, and
363 This inspired Craig to add further support,
364 even though the resulting support
365 would still be incomplete, because version 0.6 is still
369 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
370 and encouraged Craig to rewrite the documentation in texinfo
371 format by contributing a first pass at a translation of the
372 old @file{g77-0.5.16/f/DOC} file.
375 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
376 some analysis of generated code as part of an overall project
377 to improve @command{g77} code generation to at least be as good
378 as @command{f2c} used in conjunction with @command{gcc}.
379 So far, this has resulted in the three, somewhat
380 experimental, options added by @command{g77} to the @command{gcc}
381 compiler and its back end.
383 (These, in turn, had made their way into the @command{egcs}
384 version of the compiler, and do not exist in @command{gcc}
385 version 2.8 or versions of @command{g77} based on that version
389 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
392 Thanks to Mary Cortani and the staff at Craftwork Solutions
393 (@email{support@@craftwork.com}) for all of their support.
396 Many other individuals have helped debug, test, and improve @command{g77}
397 over the past several years, and undoubtedly more people
398 will be doing so in the future.
399 If you have done so, and would like
400 to see your name listed in the above list, please ask!
401 The default is that people wish to remain anonymous.
404 @include funding.texi
406 @node Funding GNU Fortran
407 @chapter Funding GNU Fortran
408 @cindex funding improvements
409 @cindex improvements, funding
411 James Craig Burley (@email{@value{email-burley}}), the original author
412 of g77, stopped working on it in September 1999
413 (He has a web page at @uref{@value{www-burley}}.)
415 GNU Fortran is currently maintained by Toon Moene
416 (@email{toon@@moene.indiv.nluug.nl}), with the help of countless other
419 As with other GNU software, funding is important because it can pay for
420 needed equipment, personnel, and so on.
422 @cindex FSF, funding the
423 @cindex funding the FSF
424 The FSF provides information on the best way to fund ongoing
425 development of GNU software (such as GNU Fortran) in documents
426 such as the ``GNUS Bulletin''.
427 Email @email{gnu@@gnu.org} for information on funding the FSF.
429 Another important way to support work on GNU Fortran is to volunteer
431 Work is needed on documentation, testing, porting
432 to various machines, and in some cases, coding (although major
433 changes planned for version 0.6 make it difficult to add manpower to this
436 Email @email{@value{email-general}} to volunteer for this work.
438 However, we strongly expect that there will never be a version 0.6
439 of @command{g77}. Work on this compiler has stopped as of the release
440 of GCC 3.1, except for bug fixing. @command{g77} will be succeeded by
441 @command{g95} - see @uref{http://g95.sourceforge.net}.
443 @xref{Funding,,Funding Free Software}, for more information.
445 @node Getting Started
446 @chapter Getting Started
447 @cindex getting started
452 If you don't need help getting started reading the portions
453 of this manual that are most important to you, you should skip
454 this portion of the manual.
456 If you are new to compilers, especially Fortran compilers, or
457 new to how compilers are structured under UNIX and UNIX-like
458 systems, you'll want to see @ref{What is GNU Fortran?}.
460 If you are new to GNU compilers, or have used only one GNU
461 compiler in the past and not had to delve into how it lets
462 you manage various versions and configurations of @command{gcc},
463 you should see @ref{G77 and GCC}.
465 Everyone except experienced @command{g77} users should
466 see @ref{Invoking G77}.
468 If you're acquainted with previous versions of @command{g77},
469 you should see @ref{News,,News About GNU Fortran}.
470 Further, if you've actually used previous versions of @command{g77},
471 especially if you've written or modified Fortran code to
472 be compiled by previous versions of @command{g77}, you
473 should see @ref{Changes}.
475 If you intend to write or otherwise compile code that is
476 not already strictly conforming ANSI FORTRAN 77---and this
477 is probably everyone---you should see @ref{Language}.
479 If you run into trouble getting Fortran code to compile,
480 link, run, or work properly, you might find answers
481 if you see @ref{Debugging and Interfacing},
482 see @ref{Collected Fortran Wisdom},
483 and see @ref{Trouble}.
484 You might also find that the problems you are encountering
485 are bugs in @command{g77}---see @ref{Bugs}, for information on
486 reporting them, after reading the other material.
488 If you need further help with @command{g77}, or with
489 freely redistributable software in general,
492 If you would like to help the @command{g77} project,
493 see @ref{Funding GNU Fortran}, for information on
494 helping financially, and see @ref{Projects}, for information
495 on helping in other ways.
497 If you're generally curious about the future of
498 @command{g77}, see @ref{Projects}.
499 If you're curious about its past,
500 see @ref{Contributors},
501 and see @ref{Funding GNU Fortran}.
503 To see a few of the questions maintainers of @command{g77} have,
504 and that you might be able to answer,
505 see @ref{Open Questions}.
508 @node What is GNU Fortran?
509 @chapter What is GNU Fortran?
510 @cindex concepts, basic
511 @cindex basic concepts
513 GNU Fortran, or @command{g77}, is designed initially as a free replacement
514 for, or alternative to, the UNIX @command{f77} command.
515 (Similarly, @command{gcc} is designed as a replacement
516 for the UNIX @command{cc} command.)
518 @command{g77} also is designed to fit in well with the other
519 fine GNU compilers and tools.
521 Sometimes these design goals conflict---in such cases, resolution
522 often is made in favor of fitting in well with Project GNU.
523 These cases are usually identified in the appropriate
524 sections of this manual.
527 As compilers, @command{g77}, @command{gcc}, and @command{f77}
528 share the following characteristics:
536 They read a user's program, stored in a file and
537 containing instructions written in the appropriate
538 language (Fortran, C, and so on).
539 This file contains @dfn{source code}.
541 @cindex translation of user programs
543 @cindex code, machine
546 They translate the user's program into instructions
547 a computer can carry out more quickly than it takes
548 to translate the instructions in the first place.
549 These instructions are called @dfn{machine code}---code
550 designed to be efficiently translated and processed
551 by a machine such as a computer.
552 Humans usually aren't as good writing machine code
553 as they are at writing Fortran or C, because
554 it is easy to make tiny mistakes writing machine code.
555 When writing Fortran or C, it is easy
556 to make big mistakes.
559 @cindex bugs, finding
560 @cindex @command{gdb}, command
561 @cindex commands, @command{gdb}
563 They provide information in the generated machine code
564 that can make it easier to find bugs in the program
565 (using a debugging tool, called a @dfn{debugger},
566 such as @command{gdb}).
570 @cindex @command{ld} command
571 @cindex commands, @command{ld}
573 They locate and gather machine code already generated
574 to perform actions requested by statements in
576 This machine code is organized
577 into @dfn{libraries} and is located and gathered
578 during the @dfn{link} phase of the compilation
580 (Linking often is thought of as a separate
581 step, because it can be directly invoked via the
582 @command{ld} command.
583 However, the @command{g77} and @command{gcc}
584 commands, as with most compiler commands, automatically
585 perform the linking step by calling on @command{ld}
586 directly, unless asked to not do so by the user.)
588 @cindex language, incorrect use of
589 @cindex incorrect use of language
591 They attempt to diagnose cases where the user's
592 program contains incorrect usages of the language.
593 The @dfn{diagnostics} produced by the compiler
594 indicate the problem and the location in the user's
595 source file where the problem was first noticed.
596 The user can use this information to locate and
598 @cindex diagnostics, incorrect
599 @cindex incorrect diagnostics
600 @cindex error messages, incorrect
601 @cindex incorrect error messages
602 (Sometimes an incorrect usage
603 of the language leads to a situation where the
604 compiler can no longer make any sense of what
605 follows---while a human might be able to---and
606 thus ends up complaining about many ``problems''
607 it encounters that, in fact, stem from just one
608 problem, usually the first one reported.)
611 @cindex questionable instructions
613 They attempt to diagnose cases where the user's
614 program contains a correct usage of the language,
615 but instructs the computer to do something questionable.
616 These diagnostics often are in the form of @dfn{warnings},
617 instead of the @dfn{errors} that indicate incorrect
618 usage of the language.
621 How these actions are performed is generally under the
623 Using command-line options, the user can specify
624 how persnickety the compiler is to be regarding
625 the program (whether to diagnose questionable usage
626 of the language), how much time to spend making
627 the generated machine code run faster, and so on.
629 @cindex components of g77
630 @cindex @command{g77}, components of
631 @command{g77} consists of several components:
633 @cindex @command{gcc}, command
634 @cindex commands, @command{gcc}
637 A modified version of the @command{gcc} command, which also might be
638 installed as the system's @command{cc} command.
639 (In many cases, @command{cc} refers to the
640 system's ``native'' C compiler, which
641 might be a non-GNU compiler, or an older version
642 of @command{gcc} considered more stable or that is
643 used to build the operating system kernel.)
645 @cindex @command{g77}, command
646 @cindex commands, @command{g77}
648 The @command{g77} command itself, which also might be installed as the
649 system's @command{f77} command.
651 @cindex libg2c library
652 @cindex libf2c library
653 @cindex libraries, libf2c
654 @cindex libraries, libg2c
655 @cindex run-time, library
657 The @code{libg2c} run-time library.
658 This library contains the machine code needed to support
659 capabilities of the Fortran language that are not directly
660 provided by the machine code generated by the @command{g77}
663 @code{libg2c} is just the unique name @command{g77} gives
664 to its version of @code{libf2c} to distinguish it from
665 any copy of @code{libf2c} installed from @command{f2c}
666 (or versions of @command{g77} that built @code{libf2c} under
670 The maintainer of @code{libf2c} currently is
671 @email{dmg@@bell-labs.com}.
673 @cindex @code{f771}, program
674 @cindex programs, @code{f771}
676 @cindex @command{as} command
677 @cindex commands, @command{as}
678 @cindex assembly code
679 @cindex code, assembly
681 The compiler itself, internally named @code{f771}.
683 Note that @code{f771} does not generate machine code directly---it
684 generates @dfn{assembly code} that is a more readable form
685 of machine code, leaving the conversion to actual machine code
686 to an @dfn{assembler}, usually named @command{as}.
689 @command{gcc} is often thought of as ``the C compiler'' only,
690 but it does more than that.
691 Based on command-line options and the names given for files
692 on the command line, @command{gcc} determines which actions to perform, including
693 preprocessing, compiling (in a variety of possible languages), assembling,
696 @cindex driver, gcc command as
697 @cindex @command{gcc}, command as driver
698 @cindex executable file
699 @cindex files, executable
701 @cindex programs, cc1
704 @cindex programs, cpp
705 For example, the command @samp{gcc foo.c} @dfn{drives} the file
706 @file{foo.c} through the preprocessor @command{cpp}, then
707 the C compiler (internally named
708 @code{cc1}), then the assembler (usually @command{as}), then the linker
709 (@command{ld}), producing an executable program named @file{a.out} (on
712 @cindex cc1plus program
713 @cindex programs, cc1plus
714 As another example, the command @samp{gcc foo.cc} would do much the same as
715 @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
716 @command{gcc} would use the C++ compiler (named @code{cc1plus}).
718 @cindex @code{f771}, program
719 @cindex programs, @code{f771}
720 In a GNU Fortran installation, @command{gcc} recognizes Fortran source
721 files by name just like it does C and C++ source files.
722 It knows to use the Fortran compiler named @code{f771}, instead of
723 @code{cc1} or @code{cc1plus}, to compile Fortran files.
725 @cindex @command{gcc}, not recognizing Fortran source
726 @cindex unrecognized file format
727 @cindex file format not recognized
728 Non-Fortran-related operation of @command{gcc} is generally
729 unaffected by installing the GNU Fortran version of @command{gcc}.
730 However, without the installed version of @command{gcc} being the
731 GNU Fortran version, @command{gcc} will not be able to compile
732 and link Fortran programs---and since @command{g77} uses @command{gcc}
733 to do most of the actual work, neither will @command{g77}!
735 @cindex @command{g77}, command
736 @cindex commands, @command{g77}
737 The @command{g77} command is essentially just a front-end for
738 the @command{gcc} command.
739 Fortran users will normally use @command{g77} instead of @command{gcc},
740 because @command{g77}
741 knows how to specify the libraries needed to link with Fortran programs
742 (@code{libg2c} and @code{lm}).
743 @command{g77} can still compile and link programs and
744 source files written in other languages, just like @command{gcc}.
746 @cindex printing version information
747 @cindex version information, printing
748 The command @samp{g77 -v} is a quick
749 way to display lots of version information for the various programs
750 used to compile a typical preprocessed Fortran source file---this
751 produces much more output than @samp{gcc -v} currently does.
752 (If it produces an error message near the end of the output---diagnostics
753 from the linker, usually @command{ld}---you might
754 have an out-of-date @code{libf2c} that improperly handles
756 In the output of this command, the line beginning @samp{GNU Fortran Front
757 End} identifies the version number of GNU Fortran; immediately
758 preceding that line is a line identifying the version of @command{gcc}
759 with which that version of @command{g77} was built.
761 @cindex libf2c library
762 @cindex libraries, libf2c
763 The @code{libf2c} library is distributed with GNU Fortran for
764 the convenience of its users, but is not part of GNU Fortran.
765 It contains the procedures
766 needed by Fortran programs while they are running.
769 @cindex code, in-line
770 For example, while code generated by @command{g77} is likely
771 to do additions, subtractions, and multiplications @dfn{in line}---in
772 the actual compiled code---it is not likely to do trigonometric
775 Instead, operations like trigonometric
776 functions are compiled by the @code{f771} compiler
777 (invoked by @command{g77} when compiling Fortran code) into machine
778 code that, when run, calls on functions in @code{libg2c}, so
779 @code{libg2c} must be linked with almost every useful program
780 having any component compiled by GNU Fortran.
781 (As mentioned above, the @command{g77} command takes
782 care of all this for you.)
784 The @code{f771} program represents most of what is unique to GNU Fortran.
785 While much of the @code{libg2c} component comes from
786 the @code{libf2c} component of @command{f2c},
787 a free Fortran-to-C converter distributed by Bellcore (AT&T),
788 plus @code{libU77}, provided by Dave Love,
789 and the @command{g77} command is just a small front-end to @command{gcc},
790 @code{f771} is a combination of two rather
791 large chunks of code.
793 @cindex GNU Back End (GBE)
795 @cindex @command{gcc}, back end
796 @cindex back end, gcc
797 @cindex code generator
798 One chunk is the so-called @dfn{GNU Back End}, or GBE,
799 which knows how to generate fast code for a wide variety of processors.
800 The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
801 @code{cc1plus}, and @code{f771}, plus others.
802 Often the GBE is referred to as the ``gcc back end'' or
803 even just ``gcc''---in this manual, the term GBE is used
804 whenever the distinction is important.
806 @cindex GNU Fortran Front End (FFE)
808 @cindex @command{g77}, front end
809 @cindex front end, @command{g77}
810 The other chunk of @code{f771} is the
811 majority of what is unique about GNU Fortran---the code that knows how
812 to interpret Fortran programs to determine what they are intending to
813 do, and then communicate that knowledge to the GBE for actual compilation
815 This chunk is called the @dfn{Fortran Front End} (FFE).
816 The @code{cc1} and @code{cc1plus} programs have their own front ends,
817 for the C and C++ languages, respectively.
818 These fronts ends are responsible for diagnosing
819 incorrect usage of their respective languages by the
820 programs the process, and are responsible for most of
821 the warnings about questionable constructs as well.
822 (The GBE handles producing some warnings, like those
823 concerning possible references to undefined variables.)
825 Because so much is shared among the compilers for various languages,
826 much of the behavior and many of the user-selectable options for these
827 compilers are similar.
828 For example, diagnostics (error messages and
829 warnings) are similar in appearance; command-line
830 options like @option{-Wall} have generally similar effects; and the quality
831 of generated code (in terms of speed and size) is roughly similar
832 (since that work is done by the shared GBE).
835 @chapter Compile Fortran, C, or Other Programs
836 @cindex compiling programs
837 @cindex programs, compiling
839 @cindex @command{gcc}, command
840 @cindex commands, @command{gcc}
841 A GNU Fortran installation includes a modified version of the @command{gcc}
844 In a non-Fortran installation, @command{gcc} recognizes C, C++,
845 and Objective-C source files.
847 In a GNU Fortran installation, @command{gcc} also recognizes Fortran source
848 files and accepts Fortran-specific command-line options, plus some
849 command-line options that are designed to cater to Fortran users
850 but apply to other languages as well.
852 @xref{G++ and GCC,,Compile C; C++; or Objective-C,gcc,Using and Porting GNU CC},
853 for information on the way different languages are handled
854 by the GNU CC compiler (@command{gcc}).
856 @cindex @command{g77}, command
857 @cindex commands, @command{g77}
858 Also provided as part of GNU Fortran is the @command{g77} command.
859 The @command{g77} command is designed to make compiling and linking Fortran
860 programs somewhat easier than when using the @command{gcc} command for
862 It does this by analyzing the command line somewhat and changing it
863 appropriately before submitting it to the @command{gcc} command.
866 @cindex @command{g77} options, -v
868 Use the @option{-v} option with @command{g77}
869 to see what is going on---the first line of output is the invocation
870 of the @command{gcc} command.
881 @chapter The GNU Fortran Language
883 @cindex standard, ANSI FORTRAN 77
884 @cindex ANSI FORTRAN 77 standard
885 @cindex reference works
886 GNU Fortran supports a variety of extensions to, and dialects
887 of, the Fortran language.
888 Its primary base is the ANSI FORTRAN 77 standard, currently available on
890 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
891 or as monolithic text at
892 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
893 It offers some extensions that are popular among users
894 of UNIX @command{f77} and @command{f2c} compilers, some that
895 are popular among users of other compilers (such as Digital
896 products), some that are popular among users of the
897 newer Fortran 90 standard, and some that are introduced
901 (If you need a text on Fortran,
902 a few freely available electronic references have pointers from
903 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
904 net project', @cite{User Notes on Fortran Programming} at
905 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
906 material might not apply specifically to @command{g77}.)
908 Part of what defines a particular implementation of a Fortran
909 system, such as @command{g77}, is the particular characteristics
910 of how it supports types, constants, and so on.
911 Much of this is left up to the implementation by the various
912 Fortran standards and accepted practice in the industry.
914 The GNU Fortran @emph{language} is described below.
915 Much of the material is organized along the same lines
916 as the ANSI FORTRAN 77 standard itself.
918 @xref{Other Dialects}, for information on features @command{g77} supports
919 that are not part of the GNU Fortran language.
921 @emph{Note}: This portion of the documentation definitely needs a lot
925 Relationship to the ANSI FORTRAN 77 standard:
926 * Direction of Language Development:: Where GNU Fortran is headed.
927 * Standard Support:: Degree of support for the standard.
929 Extensions to the ANSI FORTRAN 77 standard:
932 * Terms and Concepts::
933 * Characters Lines Sequence::
934 * Data Types and Constants::
936 * Specification Statements::
937 * Control Statements::
938 * Functions and Subroutines::
939 * Scope and Classes of Names::
941 * Fortran 90 Features::
944 @node Direction of Language Development
945 @section Direction of Language Development
946 @cindex direction of language development
947 @cindex features, language
948 @cindex language, features
950 The purpose of the following description of the GNU Fortran
951 language is to promote wide portability of GNU Fortran programs.
953 GNU Fortran is an evolving language, due to the
954 fact that @command{g77} itself is in beta test.
955 Some current features of the language might later
956 be redefined as dialects of Fortran supported by @command{g77}
957 when better ways to express these features are added to @command{g77},
959 Such features would still be supported by
960 @command{g77}, but would be available only when
961 one or more command-line options were used.
963 The GNU Fortran @emph{language} is distinct from the
964 GNU Fortran @emph{compilation system} (@command{g77}).
966 For example, @command{g77} supports various dialects of
967 Fortran---in a sense, these are languages other than
968 GNU Fortran---though its primary
969 purpose is to support the GNU Fortran language, which also is
970 described in its documentation and by its implementation.
972 On the other hand, non-GNU compilers might offer
973 support for the GNU Fortran language, and are encouraged
976 Currently, the GNU Fortran language is a fairly fuzzy object.
977 It represents something of a cross between what @command{g77} accepts
978 when compiling using the prevailing defaults and what this
979 document describes as being part of the language.
981 Future versions of @command{g77} are expected to clarify the
982 definition of the language in the documentation.
983 Often, this will mean adding new features to the language, in the form
984 of both new documentation and new support in @command{g77}.
985 However, it might occasionally mean removing a feature
986 from the language itself to ``dialect'' status.
987 In such a case, the documentation would be adjusted
988 to reflect the change, and @command{g77} itself would likely be changed
989 to require one or more command-line options to continue supporting
992 The development of the GNU Fortran language is intended to strike
997 Serving as a mostly-upwards-compatible language from the
998 de facto UNIX Fortran dialect as supported by @command{f77}.
1001 Offering new, well-designed language features.
1002 Attributes of such features include
1003 not making existing code any harder to read
1004 (for those who might be unaware that the new
1005 features are not in use) and
1006 not making state-of-the-art
1007 compilers take longer to issue diagnostics,
1011 Supporting existing, well-written code without gratuitously
1012 rejecting non-standard constructs, regardless of the origin
1013 of the code (its dialect).
1016 Offering default behavior and command-line options to reduce
1017 and, where reasonable, eliminate the need for programmers to make
1018 any modifications to code that already works in existing
1019 production environments.
1022 Diagnosing constructs that have different meanings in different
1023 systems, languages, and dialects, while offering clear,
1024 less ambiguous ways to express each of the different meanings
1025 so programmers can change their code appropriately.
1028 One of the biggest practical challenges for the developers of the
1029 GNU Fortran language is meeting the sometimes contradictory demands
1032 For example, a feature might be widely used in one popular environment,
1033 but the exact same code that utilizes that feature might not work
1034 as expected---perhaps it might mean something entirely different---in
1035 another popular environment.
1037 Traditionally, Fortran compilers---even portable ones---have solved this
1038 problem by simply offering the appropriate feature to users of
1039 the respective systems.
1040 This approach treats users of various Fortran systems and dialects
1041 as remote ``islands'', or camps, of programmers, and assume that these
1042 camps rarely come into contact with each other (or,
1043 especially, with each other's code).
1045 Project GNU takes a radically different approach to software and language
1046 design, in that it assumes that users of GNU software do not necessarily
1047 care what kind of underlying system they are using, regardless
1048 of whether they are using software (at the user-interface
1049 level) or writing it (for example, writing Fortran or C code).
1051 As such, GNU users rarely need consider just what kind of underlying
1052 hardware (or, in many cases, operating system) they are using at any
1054 They can use and write software designed for a general-purpose,
1055 widely portable, heterogenous environment---the GNU environment.
1057 In line with this philosophy, GNU Fortran must evolve into a product
1058 that is widely ported and portable not only in the sense that it can
1059 be successfully built, installed, and run by users, but in the larger
1060 sense that its users can use it in the same way, and expect largely the
1061 same behaviors from it, regardless of the kind of system they are using
1062 at any particular time.
1064 This approach constrains the solutions @command{g77} can use to resolve
1065 conflicts between various camps of Fortran users.
1066 If these two camps disagree about what a particular construct should
1067 mean, @command{g77} cannot simply be changed to treat that particular construct as
1068 having one meaning without comment (such as a warning), lest the users
1069 expecting it to have the other meaning are unpleasantly surprised that
1070 their code misbehaves when executed.
1072 The use of the ASCII backslash character in character constants is
1073 an excellent (and still somewhat unresolved) example of this kind of
1075 @xref{Backslash in Constants}.
1076 Other examples are likely to arise in the future, as @command{g77} developers
1077 strive to improve its ability to accept an ever-wider variety of existing
1078 Fortran code without requiring significant modifications to said code.
1080 Development of GNU Fortran is further constrained by the desire
1081 to avoid requiring programmers to change their code.
1082 This is important because it allows programmers, administrators,
1083 and others to more faithfully evaluate and validate @command{g77}
1084 (as an overall product and as new versions are distributed)
1085 without having to support multiple versions of their programs
1086 so that they continue to work the same way on their existing
1087 systems (non-GNU perhaps, but possibly also earlier versions
1090 @node Standard Support
1091 @section ANSI FORTRAN 77 Standard Support
1092 @cindex ANSI FORTRAN 77 support
1093 @cindex standard, support for
1094 @cindex support, FORTRAN 77
1095 @cindex compatibility, FORTRAN 77
1096 @cindex FORTRAN 77 compatibility
1098 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
1099 In summary, the only ANSI FORTRAN 77 features @command{g77} doesn't
1100 support are those that are probably rarely used in actual code,
1101 some of which are explicitly disallowed by the Fortran 90 standard.
1104 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
1105 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
1106 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
1107 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
1110 @node No Passing External Assumed-length
1111 @subsection No Passing External Assumed-length
1113 @command{g77} disallows passing of an external procedure
1114 as an actual argument if the procedure's
1115 type is declared @code{CHARACTER*(*)}. For example:
1125 It isn't clear whether the standard considers this conforming.
1127 @node No Passing Dummy Assumed-length
1128 @subsection No Passing Dummy Assumed-length
1130 @command{g77} disallows passing of a dummy procedure
1131 as an actual argument if the procedure's
1132 type is declared @code{CHARACTER*(*)}.
1135 SUBROUTINE BAR(CFUNC)
1143 It isn't clear whether the standard considers this conforming.
1145 @node No Pathological Implied-DO
1146 @subsection No Pathological Implied-DO
1148 The @code{DO} variable for an implied-@code{DO} construct in a
1149 @code{DATA} statement may not be used as the @code{DO} variable
1150 for an outer implied-@code{DO} construct. For example, this
1151 fragment is disallowed by @command{g77}:
1154 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
1158 This also is disallowed by Fortran 90, as it offers no additional
1159 capabilities and would have a variety of possible meanings.
1161 Note that it is @emph{very} unlikely that any production Fortran code
1162 tries to use this unsupported construct.
1164 @node No Useless Implied-DO
1165 @subsection No Useless Implied-DO
1167 An array element initializer in an implied-@code{DO} construct in a
1168 @code{DATA} statement must contain at least one reference to the @code{DO}
1169 variables of each outer implied-@code{DO} construct. For example,
1170 this fragment is disallowed by @command{g77}:
1173 DATA (A, I= 1, 1) /1./
1177 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
1178 requirements offer no additional capabilities.
1179 However, @command{g77} doesn't necessarily diagnose all cases
1180 where this requirement is not met.
1182 Note that it is @emph{very} unlikely that any production Fortran code
1183 tries to use this unsupported construct.
1186 @section Conformance
1188 (The following information augments or overrides the information in
1189 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1191 Chapter 1 of that document otherwise serves as the basis
1192 for the relevant aspects of GNU Fortran.)
1194 The definition of the GNU Fortran language is akin to that of
1195 the ANSI FORTRAN 77 language in that it does not generally require
1196 conforming implementations to diagnose cases where programs do
1197 not conform to the language.
1199 However, @command{g77} as a compiler is being developed in a way that
1200 is intended to enable it to diagnose such cases in an easy-to-understand
1203 A program that conforms to the GNU Fortran language should, when
1204 compiled, linked, and executed using a properly installed @command{g77}
1205 system, perform as described by the GNU Fortran language definition.
1206 Reasons for different behavior include, among others:
1210 Use of resources (memory---heap, stack, and so on; disk space; CPU
1211 time; etc.) exceeds those of the system.
1214 Range and/or precision of calculations required by the program
1215 exceeds that of the system.
1218 Excessive reliance on behaviors that are system-dependent
1219 (non-portable Fortran code).
1222 Bugs in the program.
1225 Bug in @command{g77}.
1231 Despite these ``loopholes'', the availability of a clear specification
1232 of the language of programs submitted to @command{g77}, as this document
1233 is intended to provide, is considered an important aspect of providing
1234 a robust, clean, predictable Fortran implementation.
1236 The definition of the GNU Fortran language, while having no special
1237 legal status, can therefore be viewed as a sort of contract, or agreement.
1238 This agreement says, in essence, ``if you write a program in this language,
1239 and run it in an environment (such as a @command{g77} system) that supports
1240 this language, the program should behave in a largely predictable way''.
1243 @section Notation Used in This Chapter
1245 (The following information augments or overrides the information in
1246 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1248 Chapter 1 of that document otherwise serves as the basis
1249 for the relevant aspects of GNU Fortran.)
1251 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
1252 and ``must not'' and ``may not'' denote prohibition.
1253 Terms such as ``might'', ``should'', and ``can'' generally add little or
1254 nothing in the way of weight to the GNU Fortran language itself,
1255 but are used to explain or illustrate the language.
1260 ``The @code{FROBNITZ} statement must precede all executable
1261 statements in a program unit, and may not specify any dummy
1262 arguments. It may specify local or common variables and arrays.
1263 Its use should be limited to portions of the program designed to
1264 be non-portable and system-specific, because it might cause the
1265 containing program unit to behave quite differently on different
1269 Insofar as the GNU Fortran language is specified,
1270 the requirements and permissions denoted by the above sample statement
1271 are limited to the placement of the statement and the kinds of
1272 things it may specify.
1273 The rest of the statement---the content regarding non-portable portions
1274 of the program and the differing behavior of program units containing
1275 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
1277 That content offers advice and warnings about the @code{FROBNITZ}
1280 @emph{Remember:} The GNU Fortran language definition specifies
1281 both what constitutes a valid GNU Fortran program and how,
1282 given such a program, a valid GNU Fortran implementation is
1283 to interpret that program.
1285 It is @emph{not} incumbent upon a valid GNU Fortran implementation
1286 to behave in any particular way, any consistent way, or any
1287 predictable way when it is asked to interpret input that is
1288 @emph{not} a valid GNU Fortran program.
1290 Such input is said to have @dfn{undefined} behavior when
1291 interpreted by a valid GNU Fortran implementation, though
1292 an implementation may choose to specify behaviors for some
1293 cases of inputs that are not valid GNU Fortran programs.
1295 Other notation used herein is that of the GNU texinfo format,
1296 which is used to generate printed hardcopy, on-line hypertext
1297 (Info), and on-line HTML versions, all from a single source
1299 This notation is used as follows:
1303 Keywords defined by the GNU Fortran language are shown
1304 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
1307 Note that, in practice, many Fortran programs are written
1308 in lowercase---uppercase is used in this manual as a
1309 means to readily distinguish keywords and sample Fortran-related
1310 text from the prose in this document.
1313 Portions of actual sample program, input, or output text
1314 look like this: @samp{Actual program text}.
1316 Generally, uppercase is used for all Fortran-specific and
1317 Fortran-related text, though this does not always include
1318 literal text within Fortran code.
1320 For example: @samp{PRINT *, 'My name is Bob'}.
1323 A metasyntactic variable---that is, a name used in this document
1324 to serve as a placeholder for whatever text is used by the
1325 user or programmer---appears as shown in the following example:
1327 ``The @code{INTEGER @var{ivar}} statement specifies that
1328 @var{ivar} is a variable or array of type @code{INTEGER}.''
1330 In the above example, any valid text may be substituted for
1331 the metasyntactic variable @var{ivar} to make the statement
1332 apply to a specific instance, as long as the same text is
1333 substituted for @emph{both} occurrences of @var{ivar}.
1336 Ellipses (``@dots{}'') are used to indicate further text that
1337 is either unimportant or expanded upon further, elsewhere.
1340 Names of data types are in the style of Fortran 90, in most
1343 @xref{Kind Notation}, for information on the relationship
1344 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
1345 and the more traditional, less portably concise nomenclature
1346 (such as @code{INTEGER*4}).
1349 @node Terms and Concepts
1350 @section Fortran Terms and Concepts
1352 (The following information augments or overrides the information in
1353 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1355 Chapter 2 of that document otherwise serves as the basis
1356 for the relevant aspects of GNU Fortran.)
1360 * Statements Comments Lines::
1361 * Scope of Names and Labels::
1364 @node Syntactic Items
1365 @subsection Syntactic Items
1367 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
1369 @cindex limits, lengths of names
1370 In GNU Fortran, a symbolic name is at least one character long,
1371 and has no arbitrary upper limit on length.
1372 However, names of entities requiring external linkage (such as
1373 external functions, external subroutines, and @code{COMMON} areas)
1374 might be restricted to some arbitrary length by the system.
1375 Such a restriction is no more constrained than that of one
1376 through six characters.
1378 Underscores (@samp{_}) are accepted in symbol names after the first
1379 character (which must be a letter).
1381 @node Statements Comments Lines
1382 @subsection Statements, Comments, and Lines
1384 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
1386 @cindex trailing comment
1388 @cindex characters, comment
1390 @cindex exclamation point
1391 @cindex continuation character
1392 @cindex characters, continuation
1393 Use of an exclamation point (@samp{!}) to begin a
1394 trailing comment (a comment that extends to the end of the same
1395 source line) is permitted under the following conditions:
1399 The exclamation point does not appear in column 6.
1400 Otherwise, it is treated as an indicator of a continuation
1404 The exclamation point appears outside a character or Hollerith
1406 Otherwise, the exclamation point is considered part of the
1410 The exclamation point appears to the left of any other possible
1412 That is, a trailing comment may contain exclamation points
1413 in their commentary text.
1418 @cindex statements, separated by semicolon
1419 Use of a semicolon (@samp{;}) as a statement separator
1420 is permitted under the following conditions:
1424 The semicolon appears outside a character or Hollerith
1426 Otherwise, the semicolon is considered part of the
1430 The semicolon appears to the left of a trailing comment.
1431 Otherwise, the semicolon is considered part of that
1435 Neither a logical @code{IF} statement nor a non-construct
1436 @code{WHERE} statement (a Fortran 90 feature) may be
1437 followed (in the same, possibly continued, line) by
1438 a semicolon used as a statement separator.
1440 This restriction avoids the confusion
1441 that can result when reading a line such as:
1444 IF (VALIDP) CALL FOO; CALL BAR
1448 Some readers might think the @samp{CALL BAR} is executed
1449 only if @samp{VALIDP} is @code{.TRUE.}, while others might
1450 assume its execution is unconditional.
1452 (At present, @command{g77} does not diagnose code that
1453 violates this restriction.)
1456 @node Scope of Names and Labels
1457 @subsection Scope of Symbolic Names and Statement Labels
1460 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
1462 Included in the list of entities that have a scope of a
1463 program unit are construct names (a Fortran 90 feature).
1464 @xref{Construct Names}, for more information.
1466 @node Characters Lines Sequence
1467 @section Characters, Lines, and Execution Sequence
1469 (The following information augments or overrides the information in
1470 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1472 Chapter 3 of that document otherwise serves as the basis
1473 for the relevant aspects of GNU Fortran.)
1478 * Continuation Line::
1480 * Statement Labels::
1483 * Cpp-style directives::
1487 @subsection GNU Fortran Character Set
1490 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
1492 Letters include uppercase letters (the twenty-six characters
1493 of the English alphabet) and lowercase letters (their lowercase
1495 Generally, lowercase letters may be used in place of uppercase
1496 letters, though in character and Hollerith constants, they
1499 Special characters include:
1505 Semicolon (@samp{;})
1509 @cindex exclamation point
1510 Exclamation point (@samp{!})
1514 @cindex double quote
1515 Double quote (@samp{"})
1520 Backslash (@samp{\})
1524 @cindex question mark
1525 Question mark (@samp{?})
1531 Hash mark (@samp{#})
1536 Ampersand (@samp{&})
1540 @cindex percent sign
1541 Percent sign (@samp{%})
1546 Underscore (@samp{_})
1552 @cindex open bracket
1553 @cindex left bracket
1554 Open angle (@samp{<})
1560 @cindex close bracket
1561 @cindex right bracket
1562 Close angle (@samp{>})
1565 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
1566 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
1567 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
1574 Note that this document refers to @key{SPC} as @dfn{space},
1575 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
1580 @cindex source file format
1581 @cindex source format
1582 @cindex file, source
1584 @cindex code, source
1588 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
1590 The way a Fortran compiler views source files depends entirely on the
1591 implementation choices made for the compiler, since those choices
1592 are explicitly left to the implementation by the published Fortran
1595 The GNU Fortran language mandates a view applicable to UNIX-like
1596 text files---files that are made up of an arbitrary number of lines,
1597 each with an arbitrary number of characters (sometimes called stream-based
1600 This view does not apply to types of files that are specified as
1601 having a particular number of characters on every single line (sometimes
1602 referred to as record-based files).
1604 Because a ``line in a program unit is a sequence of 72 characters'',
1605 to quote X3.9-1978, the GNU Fortran language specifies that a
1606 stream-based text file is translated to GNU Fortran lines as follows:
1610 A newline in the file is the character that represents the end of
1611 a line of text to the underlying system.
1612 For example, on ASCII-based systems, a newline is the @key{NL}
1613 character, which has ASCII value 10 (decimal).
1616 Each newline in the file serves to end the line of text that precedes
1617 it (and that does not contain a newline).
1620 The end-of-file marker (@code{EOF}) also serves to end the line
1621 of text that precedes it (and that does not contain a newline).
1627 Any line of text that is shorter than 72 characters is padded to that length
1628 with spaces (called ``blanks'' in the standard).
1631 Any line of text that is longer than 72 characters is truncated to that
1632 length, but the truncated remainder must consist entirely of spaces.
1635 Characters other than newline and the GNU Fortran character set
1639 For the purposes of the remainder of this description of the GNU
1640 Fortran language, the translation described above has already
1641 taken place, unless otherwise specified.
1643 The result of the above translation is that the source file appears,
1644 in terms of the remainder of this description of the GNU Fortran language,
1645 as if it had an arbitrary
1646 number of 72-character lines, each character being among the GNU Fortran
1649 For example, if the source file itself has two newlines in a row,
1650 the second newline becomes, after the above translation, a single
1651 line containing 72 spaces.
1653 @node Continuation Line
1654 @subsection Continuation Line
1655 @cindex continuation line, number of
1656 @cindex lines, continuation
1657 @cindex number of continuation lines
1658 @cindex limits, continuation lines
1660 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
1662 A continuation line is any line that both
1666 Contains a continuation character, and
1669 Contains only spaces in columns 1 through 5
1672 A continuation character is any character of the GNU Fortran character set
1673 other than space (@key{SPC}) or zero (@samp{0})
1674 in column 6, or a digit (@samp{0} through @samp{9}) in column
1675 7 through 72 of a line that has only spaces to the left of that
1678 The continuation character is ignored as far as the content of
1679 the statement is concerned.
1681 The GNU Fortran language places no limit on the number of
1682 continuation lines in a statement.
1683 In practice, the limit depends on a variety of factors, such as
1684 available memory, statement content, and so on, but no
1685 GNU Fortran system may impose an arbitrary limit.
1688 @subsection Statements
1690 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
1692 Statements may be written using an arbitrary number of continuation
1695 Statements may be separated using the semicolon (@samp{;}), except
1696 that the logical @code{IF} and non-construct @code{WHERE} statements
1697 may not be separated from subsequent statements using only a semicolon
1698 as statement separator.
1700 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
1701 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
1703 These alternatives may be written as normal statements---they are not
1704 subject to the restrictions of the @code{END} statement.
1706 However, no statement other than @code{END} may have an initial line
1707 that appears to be an @code{END} statement---even @code{END PROGRAM},
1708 for example, must not be written as:
1715 @node Statement Labels
1716 @subsection Statement Labels
1718 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
1720 A statement separated from its predecessor via a semicolon may be
1725 The semicolon is followed by the label for the statement,
1726 which in turn follows the label.
1729 The label must be no more than five digits in length.
1732 The first digit of the label for the statement is not
1733 the first non-space character on a line.
1734 Otherwise, that character is treated as a continuation
1738 A statement may have only one label defined for it.
1741 @subsection Order of Statements and Lines
1743 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
1745 Generally, @code{DATA} statements may precede executable statements.
1746 However, specification statements pertaining to any entities
1747 initialized by a @code{DATA} statement must precede that @code{DATA}
1750 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
1751 @samp{INTEGER J} is permitted.
1753 The last line of a program unit may be an @code{END} statement,
1758 An @code{END PROGRAM} statement, if the program unit is a main program.
1761 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
1764 An @code{END FUNCTION} statement, if the program unit is a function.
1767 An @code{END BLOCK DATA} statement, if the program unit is a block data.
1771 @subsection Including Source Text
1772 @cindex INCLUDE directive
1774 Additional source text may be included in the processing of
1775 the source file via the @code{INCLUDE} directive:
1778 INCLUDE @var{filename}
1782 The source text to be included is identified by @var{filename},
1783 which is a literal GNU Fortran character constant.
1784 The meaning and interpretation of @var{filename} depends on the
1785 implementation, but typically is a filename.
1787 (@command{g77} treats it as a filename that it searches for
1788 in the current directory and/or directories specified
1789 via the @option{-I} command-line option.)
1791 The effect of the @code{INCLUDE} directive is as if the
1792 included text directly replaced the directive in the source
1793 file prior to interpretation of the program.
1794 Included text may itself use @code{INCLUDE}.
1795 The depth of nested @code{INCLUDE} references depends on
1796 the implementation, but typically is a positive integer.
1798 This virtual replacement treats the statements and @code{INCLUDE}
1799 directives in the included text as syntactically distinct from
1800 those in the including text.
1802 Therefore, the first non-comment line of the included text
1803 must not be a continuation line.
1804 The included text must therefore have, after the non-comment
1805 lines, either an initial line (statement), an @code{INCLUDE}
1806 directive, or nothing (the end of the included text).
1808 Similarly, the including text may end the @code{INCLUDE}
1809 directive with a semicolon or the end of the line, but it
1810 cannot follow an @code{INCLUDE} directive at the end of its
1811 line with a continuation line.
1812 Thus, the last statement in an included text may not be
1815 Any statements between two @code{INCLUDE} directives on the
1816 same line are treated as if they appeared in between the
1817 respective included texts.
1821 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
1825 If the text included by @samp{INCLUDE 'A'} constitutes
1826 a @samp{PRINT *, 'A'} statement and the text included by
1827 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
1828 then the output of the above sample program would be
1837 (with suitable allowances for how an implementation defines
1838 its handling of output).
1840 Included text must not include itself directly or indirectly,
1841 regardless of whether the @var{filename} used to reference
1842 the text is the same.
1844 Note that @code{INCLUDE} is @emph{not} a statement.
1845 As such, it is neither a non-executable or executable
1847 However, if the text it includes constitutes one or more
1848 executable statements, then the placement of @code{INCLUDE}
1849 is subject to effectively the same restrictions as those
1850 on executable statements.
1852 An @code{INCLUDE} directive may be continued across multiple
1853 lines as if it were a statement.
1854 This permits long names to be used for @var{filename}.
1856 @node Cpp-style directives
1857 @subsection Cpp-style directives
1859 @cindex preprocessor
1861 @code{cpp} output-style @code{#} directives
1862 (@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
1863 are recognized by the compiler even
1864 when the preprocessor isn't run on the input (as it is when compiling
1865 @samp{.F} files). (Note the distinction between these @command{cpp}
1866 @code{#} @emph{output} directives and @code{#line} @emph{input}
1869 @node Data Types and Constants
1870 @section Data Types and Constants
1872 (The following information augments or overrides the information in
1873 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1875 Chapter 4 of that document otherwise serves as the basis
1876 for the relevant aspects of GNU Fortran.)
1878 To more concisely express the appropriate types for
1879 entities, this document uses the more concise
1880 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
1881 instead of the more traditional, but less portably concise,
1882 byte-size-based nomenclature such as @code{INTEGER*4},
1883 wherever reasonable.
1885 When referring to generic types---in contexts where the
1886 specific precision and range of a type are not important---this
1887 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
1888 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
1890 In some cases, the context requires specification of a
1892 This document uses the @samp{KIND=} notation to accomplish
1893 this throughout, sometimes supplying the more traditional
1894 notation for clarification, though the traditional notation
1895 might not work the same way on all GNU Fortran implementations.
1897 Use of @samp{KIND=} makes this document more concise because
1898 @command{g77} is able to define values for @samp{KIND=} that
1899 have the same meanings on all systems, due to the way the
1900 Fortran 90 standard specifies these values are to be used.
1902 (In particular, that standard permits an implementation to
1903 arbitrarily assign nonnegative values.
1904 There are four distinct sets of assignments: one to the @code{CHARACTER}
1905 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
1906 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
1907 Implementations are free to assign these values in any order,
1908 leave gaps in the ordering of assignments, and assign more than
1909 one value to a representation.)
1911 This makes @samp{KIND=} values superior to the values used
1912 in non-standard statements such as @samp{INTEGER*4}, because
1913 the meanings of the values in those statements vary from machine
1914 to machine, compiler to compiler, even operating system to
1917 However, use of @samp{KIND=} is @emph{not} generally recommended
1918 when writing portable code (unless, for example, the code is
1919 going to be compiled only via @command{g77}, which is a widely
1921 GNU Fortran does not yet have adequate language constructs to
1922 permit use of @samp{KIND=} in a fashion that would make the
1923 code portable to Fortran 90 implementations; and, this construct
1924 is known to @emph{not} be accepted by many popular FORTRAN 77
1925 implementations, so it cannot be used in code that is to be ported
1928 The distinction here is that this document is able to use
1929 specific values for @samp{KIND=} to concisely document the
1930 types of various operations and operands.
1932 A Fortran program should use the FORTRAN 77 designations for the
1933 appropriate GNU Fortran types---such as @code{INTEGER} for
1934 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
1935 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
1936 where no such designations exist, make use of appropriate
1937 techniques (preprocessor macros, parameters, and so on)
1938 to specify the types in a fashion that may be easily adjusted
1939 to suit each particular implementation to which the program
1941 (These types generally won't need to be adjusted for ports of
1944 Further details regarding GNU Fortran data types and constants
1955 @subsection Data Types
1957 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
1959 GNU Fortran supports these types:
1963 Integer (generic type @code{INTEGER})
1966 Real (generic type @code{REAL})
1972 Complex (generic type @code{COMPLEX})
1975 Logical (generic type @code{LOGICAL})
1978 Character (generic type @code{CHARACTER})
1984 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
1986 The generic types shown above are referred to in this document
1987 using only their generic type names.
1988 Such references usually indicate that any specific type (kind)
1989 of that generic type is valid.
1991 For example, a context described in this document as accepting
1992 the @code{COMPLEX} type also is likely to accept the
1993 @code{DOUBLE COMPLEX} type.
1995 The GNU Fortran language supports three ways to specify
1996 a specific kind of a generic type.
1999 * Double Notation:: As in @code{DOUBLE COMPLEX}.
2000 * Star Notation:: As in @code{INTEGER*4}.
2001 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
2004 @node Double Notation
2005 @subsubsection Double Notation
2007 The GNU Fortran language supports two uses of the keyword
2008 @code{DOUBLE} to specify a specific kind of type:
2012 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
2015 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
2018 Use one of the above forms where a type name is valid.
2020 While use of this notation is popular, it doesn't scale
2021 well in a language or dialect rich in intrinsic types,
2022 as is the case for the GNU Fortran language (especially
2023 planned future versions of it).
2025 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
2026 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
2027 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
2028 often are substituted for these, respectively, even though they
2029 do not always have the same meanings on all systems.
2030 (And, the fact that @samp{DOUBLE REAL} does not exist as such
2031 is an inconsistency.)
2033 Therefore, this document uses ``double notation'' only on occasion
2034 for the benefit of those readers who are accustomed to it.
2037 @subsubsection Star Notation
2038 @cindex *@var{n} notation
2040 The following notation specifies the storage size for a type:
2043 @var{generic-type}*@var{n}
2047 @var{generic-type} must be a generic type---one of
2048 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
2049 or @code{CHARACTER}.
2050 @var{n} must be one or more digits comprising a decimal
2051 integer number greater than zero.
2053 Use the above form where a type name is valid.
2055 The @samp{*@var{n}} notation specifies that the amount of storage
2056 occupied by variables and array elements of that type is @var{n}
2057 times the storage occupied by a @code{CHARACTER*1} variable.
2059 This notation might indicate a different degree of precision and/or
2060 range for such variables and array elements, and the functions that
2061 return values of types using this notation.
2062 It does not limit the precision or range of values of that type
2063 in any particular way---use explicit code to do that.
2065 Further, the GNU Fortran language requires no particular values
2066 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
2068 @command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
2069 on all systems, for example,
2070 but not all implementations are required to do so, and @command{g77}
2071 is known to not support @code{REAL*1} on most (or all) systems.
2073 As a result, except for @var{generic-type} of @code{CHARACTER},
2074 uses of this notation should be limited to isolated
2075 portions of a program that are intended to handle system-specific
2076 tasks and are expected to be non-portable.
2078 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
2079 only @code{CHARACTER}, where it signifies not only the amount
2080 of storage occupied, but the number of characters in entities
2082 However, almost all Fortran compilers have supported this
2083 notation for generic types, though with a variety of meanings
2086 Specifications of types using the @samp{*@var{n}} notation
2087 always are interpreted as specifications of the appropriate
2088 types described in this document using the @samp{KIND=@var{n}}
2089 notation, described below.
2091 While use of this notation is popular, it doesn't serve well
2092 in the context of a widely portable dialect of Fortran, such as
2093 the GNU Fortran language.
2095 For example, even on one particular machine, two or more popular
2096 Fortran compilers might well disagree on the size of a type
2097 declared @code{INTEGER*2} or @code{REAL*16}.
2099 is known to be disagreement over such things among Fortran
2100 compilers on @emph{different} systems.
2102 Further, this notation offers no elegant way to specify sizes
2103 that are not even multiples of the ``byte size'' typically
2104 designated by @code{INTEGER*1}.
2105 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
2106 certainly be possible, but would perhaps be stretching the original
2107 intent of this notation beyond the breaking point in terms
2108 of widespread readability of documentation and code making use
2111 Therefore, this document uses ``star notation'' only on occasion
2112 for the benefit of those readers who are accustomed to it.
2115 @subsubsection Kind Notation
2116 @cindex KIND= notation
2118 The following notation specifies the kind-type selector of a type:
2121 @var{generic-type}(KIND=@var{n})
2125 Use the above form where a type name is valid.
2127 @var{generic-type} must be a generic type---one of
2128 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
2129 or @code{CHARACTER}.
2130 @var{n} must be an integer initialization expression that
2131 is a positive, nonzero value.
2133 Programmers are discouraged from writing these values directly
2135 Future versions of the GNU Fortran language will offer
2136 facilities that will make the writing of code portable
2137 to @command{g77} @emph{and} Fortran 90 implementations simpler.
2139 However, writing code that ports to existing FORTRAN 77
2140 implementations depends on avoiding the @samp{KIND=} construct.
2142 The @samp{KIND=} construct is thus useful in the context
2143 of GNU Fortran for two reasons:
2147 It provides a means to specify a type in a fashion that
2148 is portable across all GNU Fortran implementations (though
2149 not other FORTRAN 77 and Fortran 90 implementations).
2152 It provides a sort of Rosetta stone for this document to use
2153 to concisely describe the types of various operations and
2157 The values of @var{n} in the GNU Fortran language are
2158 assigned using a scheme that:
2162 Attempts to maximize the ability of readers
2163 of this document to quickly familiarize themselves
2164 with assignments for popular types
2167 Provides a unique value for each specific desired
2171 Provides a means to automatically assign new values so
2172 they have a ``natural'' relationship to existing values,
2173 if appropriate, or, if no such relationship exists, will
2174 not interfere with future values assigned on the basis
2175 of such relationships
2178 Avoids using values that are similar to values used
2179 in the existing, popular @samp{*@var{n}} notation,
2180 to prevent readers from expecting that these implied
2181 correspondences work on all GNU Fortran implementations
2184 The assignment system accomplishes this by assigning
2185 to each ``fundamental meaning'' of a specific type a
2186 unique prime number.
2187 Combinations of fundamental meanings---for example, a type
2188 that is two times the size of some other type---are assigned
2189 values of @var{n} that are the products of the values for
2190 those fundamental meanings.
2192 A prime value of @var{n} is never given more than one fundamental
2193 meaning, to avoid situations where some code or system
2194 cannot reasonably provide those meanings in the form of a
2197 The values of @var{n} assigned so far are:
2201 This value is reserved for future use.
2203 The planned future use is for this value to designate,
2204 explicitly, context-sensitive kind-type selection.
2205 For example, the expression @samp{1D0 * 0.1_0} would
2206 be equivalent to @samp{1D0 * 0.1D0}.
2209 This corresponds to the default types for
2210 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
2211 and @code{CHARACTER}, as appropriate.
2213 These are the ``default'' types described in the Fortran 90 standard,
2214 though that standard does not assign any particular @samp{KIND=}
2215 value to these types.
2217 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
2218 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
2221 This corresponds to types that occupy twice as much
2222 storage as the default types.
2223 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
2224 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
2226 These are the ``double precision'' types described in the Fortran 90
2228 though that standard does not assign any particular @samp{KIND=}
2229 value to these types.
2231 @var{n} of 4 thus corresponds to types that occupy four times
2232 as much storage as the default types, @var{n} of 8 to types that
2233 occupy eight times as much storage, and so on.
2235 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
2236 are not necessarily supported by every GNU Fortran implementation.
2239 This corresponds to types that occupy as much
2240 storage as the default @code{CHARACTER} type,
2241 which is the same effective type as @code{CHARACTER(KIND=1)}
2242 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
2244 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
2246 @var{n} of 6 thus corresponds to types that occupy twice as
2247 much storage as the @var{n}=3 types, @var{n} of 12 to types
2248 that occupy four times as much storage, and so on.
2250 These are not necessarily supported by every GNU Fortran
2254 This corresponds to types that occupy half the
2255 storage as the default (@var{n}=1) types.
2257 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
2259 @var{n} of 25 thus corresponds to types that occupy one-quarter
2260 as much storage as the default types.
2262 These are not necessarily supported by every GNU Fortran
2267 This is valid only as @code{INTEGER(KIND=7)} and
2268 denotes the @code{INTEGER} type that has the smallest
2269 storage size that holds a pointer on the system.
2271 A pointer representable by this type is capable of uniquely
2272 addressing a @code{CHARACTER*1} variable, array, array element,
2275 (Typically this is equivalent to @code{INTEGER*4} or,
2276 on 64-bit systems, @code{INTEGER*8}.
2277 In a compatible C implementation, it typically would
2278 be the same size and semantics of the C type @code{void *}.)
2281 Note that these are @emph{proposed} correspondences and might change
2282 in future versions of @command{g77}---avoid writing code depending
2283 on them while @command{g77}, and therefore the GNU Fortran language
2284 it defines, is in beta testing.
2286 Values not specified in the above list are reserved to
2287 future versions of the GNU Fortran language.
2289 Implementation-dependent meanings will be assigned new,
2290 unique prime numbers so as to not interfere with other
2291 implementation-dependent meanings, and offer the possibility
2292 of increasing the portability of code depending on such
2293 types by offering support for them in other GNU Fortran
2296 Other meanings that might be given unique values are:
2300 Types that make use of only half their storage size for
2301 representing precision and range.
2303 For example, some compilers offer options that cause
2304 @code{INTEGER} types to occupy the amount of storage
2305 that would be needed for @code{INTEGER(KIND=2)} types, but the
2306 range remains that of @code{INTEGER(KIND=1)}.
2309 The IEEE single floating-point type.
2312 Types with a specific bit pattern (endianness), such as the
2313 little-endian form of @code{INTEGER(KIND=1)}.
2314 These could permit, conceptually, use of portable code and
2315 implementations on data files written by existing systems.
2318 Future @emph{prime} numbers should be given meanings in as incremental
2319 a fashion as possible, to allow for flexibility and
2320 expressiveness in combining types.
2322 For example, instead of defining a prime number for little-endian
2323 IEEE doubles, one prime number might be assigned the meaning
2324 ``little-endian'', another the meaning ``IEEE double'', and the
2325 value of @var{n} for a little-endian IEEE double would thus
2326 naturally be the product of those two respective assigned values.
2327 (It could even be reasonable to have IEEE values result from the
2328 products of prime values denoting exponent and fraction sizes
2329 and meanings, hidden bit usage, availability and representations
2330 of special values such as subnormals, infinities, and Not-A-Numbers
2333 This assignment mechanism, while not inherently required for
2334 future versions of the GNU Fortran language, is worth using
2335 because it could ease management of the ``space'' of supported
2336 types much easier in the long run.
2338 The above approach suggests a mechanism for specifying inheritance
2339 of intrinsic (built-in) types for an entire, widely portable
2341 It is certainly reasonable that, unlike programmers of other languages
2342 offering inheritance mechanisms that employ verbose names for classes
2343 and subclasses, along with graphical browsers to elucidate the
2344 relationships, Fortran programmers would employ
2345 a mechanism that works by multiplying prime numbers together
2346 and finding the prime factors of such products.
2348 Most of the advantages for the above scheme have been explained
2350 One disadvantage is that it could lead to the defining,
2351 by the GNU Fortran language, of some fairly large prime numbers.
2352 This could lead to the GNU Fortran language being declared
2353 ``munitions'' by the United States Department of Defense.
2356 @subsection Constants
2358 @cindex types, constants
2360 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
2362 A @dfn{typeless constant} has one of the following forms:
2365 '@var{binary-digits}'B
2366 '@var{octal-digits}'O
2367 '@var{hexadecimal-digits}'Z
2368 '@var{hexadecimal-digits}'X
2372 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
2373 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
2374 and @samp{0123456789ABCDEFabcdef}, respectively.
2375 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
2378 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
2379 treated as typeless. @xref{Fortran Dialect Options,, Options
2380 Controlling Fortran Dialect}, for information on the
2381 @option{-ftypeless-boz} option.
2383 Typeless constants have values that depend on the context in which
2386 All other constants, called @dfn{typed constants}, are interpreted---converted
2387 to internal form---according to their inherent type.
2388 Thus, context is @emph{never} a determining factor for the type, and hence
2389 the interpretation, of a typed constant.
2390 (All constants in the ANSI FORTRAN 77 language are typed constants.)
2392 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
2393 Fortran (called default INTEGER in Fortran 90),
2394 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
2395 additional precision specified is lost, and even when used in a
2396 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
2397 and @samp{1D0} is always type @code{REAL(KIND=2)}.
2400 @subsection Integer Type
2402 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
2404 An integer constant also may have one of the following forms:
2407 B'@var{binary-digits}'
2408 O'@var{octal-digits}'
2409 Z'@var{hexadecimal-digits}'
2410 X'@var{hexadecimal-digits}'
2414 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
2415 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
2416 and @samp{0123456789ABCDEFabcdef}, respectively.
2417 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
2420 @node Character Type
2421 @subsection Character Type
2423 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
2425 @cindex double quoted character constants
2426 A character constant may be delimited by a pair of double quotes
2427 (@samp{"}) instead of apostrophes.
2428 In this case, an apostrophe within the constant represents
2429 a single apostrophe, while a double quote is represented in
2430 the source text of the constant by two consecutive double
2431 quotes with no intervening spaces.
2433 @cindex zero-length CHARACTER
2434 @cindex null CHARACTER strings
2435 @cindex empty CHARACTER strings
2436 @cindex strings, empty
2437 @cindex CHARACTER, null
2438 A character constant may be empty (have a length of zero).
2440 A character constant may include a substring specification,
2441 The value of such a constant is the value of the substring---for
2442 example, the value of @samp{'hello'(3:5)} is the same
2443 as the value of @samp{'llo'}.
2446 @section Expressions
2448 (The following information augments or overrides the information in
2449 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2451 Chapter 6 of that document otherwise serves as the basis
2452 for the relevant aspects of GNU Fortran.)
2459 @subsection The @code{%LOC()} Construct
2460 @cindex %LOC() construct
2466 The @code{%LOC()} construct is an expression
2467 that yields the value of the location of its argument,
2468 @var{arg}, in memory.
2469 The size of the type of the expression depends on the system---typically,
2470 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
2471 though it is actually type @code{INTEGER(KIND=7)}.
2473 The argument to @code{%LOC()} must be suitable as the
2474 left-hand side of an assignment statement.
2475 That is, it may not be a general expression involving
2476 operators such as addition, subtraction, and so on,
2477 nor may it be a constant.
2479 Use of @code{%LOC()} is recommended only for code that
2480 is accessing facilities outside of GNU Fortran, such as
2481 operating system or windowing facilities.
2482 It is best to constrain such uses to isolated portions of
2483 a program---portions that deal specifically and exclusively
2484 with low-level, system-dependent facilities.
2485 Such portions might well provide a portable interface for
2486 use by the program as a whole, but are themselves not
2487 portable, and should be thoroughly tested each time they
2488 are rebuilt using a new compiler or version of a compiler.
2490 Do not depend on @code{%LOC()} returning a pointer that
2491 can be safely used to @emph{define} (change) the argument.
2492 While this might work in some circumstances, it is hard
2493 to predict whether it will continue to work when a program
2494 (that works using this unsafe behavior)
2495 is recompiled using different command-line options or
2496 a different version of @command{g77}.
2498 Generally, @code{%LOC()} is safe when used as an argument
2499 to a procedure that makes use of the value of the corresponding
2500 dummy argument only during its activation, and only when
2501 such use is restricted to referencing (reading) the value
2502 of the argument to @code{%LOC()}.
2504 @emph{Implementation Note:} Currently, @command{g77} passes
2505 arguments (those not passed using a construct such as @code{%VAL()})
2506 by reference or descriptor, depending on the type of
2507 the actual argument.
2508 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
2509 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
2510 in fact might compile to identical code.
2512 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
2513 ``pass, by value, the address of @samp{I} in memory''.
2514 While @samp{CALL FOO(I)} might use that same approach in a
2515 particular version of @command{g77}, another version or compiler
2516 might choose a different implementation, such as copy-in/copy-out,
2517 to effect the desired behavior---and which will therefore not
2518 necessarily compile to the same code as would
2519 @samp{CALL FOO(%VAL(%LOC(I)))}
2520 using the same version or compiler.
2522 @xref{Debugging and Interfacing}, for detailed information on
2523 how this particular version of @command{g77} implements various
2526 @node Specification Statements
2527 @section Specification Statements
2529 (The following information augments or overrides the information in
2530 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2532 Chapter 8 of that document otherwise serves as the basis
2533 for the relevant aspects of GNU Fortran.)
2541 @subsection @code{NAMELIST} Statement
2542 @cindex NAMELIST statement
2543 @cindex statements, NAMELIST
2545 The @code{NAMELIST} statement, and related I/O constructs, are
2546 supported by the GNU Fortran language in essentially the same
2547 way as they are by @command{f2c}.
2549 This follows Fortran 90 with the restriction that on @code{NAMELIST}
2550 input, subscripts must have the form
2552 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
2556 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
2558 is allowed, but not, say,
2560 &xx x(:3,8::2)=1,2,3,4,5,6/
2563 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
2564 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
2566 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
2568 could be used instead of the example above.
2570 @node DOUBLE COMPLEX
2571 @subsection @code{DOUBLE COMPLEX} Statement
2572 @cindex DOUBLE COMPLEX
2574 @code{DOUBLE COMPLEX} is a type-statement (and type) that
2575 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
2577 @node Control Statements
2578 @section Control Statements
2580 (The following information augments or overrides the information in
2581 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2583 Chapter 11 of that document otherwise serves as the basis
2584 for the relevant aspects of GNU Fortran.)
2594 @subsection DO WHILE
2597 @cindex MIL-STD 1753
2599 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
2600 Fortran 90 standards, is provided by the GNU Fortran language.
2601 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
2607 @cindex MIL-STD 1753
2609 The @code{END DO} statement is provided by the GNU Fortran language.
2611 This statement is used in one of two ways:
2615 The Fortran 90 meaning, in which it specifies the termination
2616 point of a single @code{DO} loop started with a @code{DO} statement
2617 that specifies no termination label.
2620 The MIL-STD 1753 meaning, in which it specifies the termination
2621 point of one or more @code{DO} loops, all of which start with a
2622 @code{DO} statement that specify the label defined for the
2623 @code{END DO} statement.
2625 This kind of @code{END DO} statement is merely a synonym for
2626 @code{CONTINUE}, except it is permitted only when the statement
2627 is labeled and a target of one or more labeled @code{DO} loops.
2629 It is expected that this use of @code{END DO} will be removed from
2630 the GNU Fortran language in the future, though it is likely that
2631 it will long be supported by @command{g77} as a dialect form.
2634 @node Construct Names
2635 @subsection Construct Names
2636 @cindex construct names
2638 The GNU Fortran language supports construct names as defined
2639 by the Fortran 90 standard.
2640 These names are local to the program unit and are defined
2644 @var{construct-name}: @var{block-statement}
2648 Here, @var{construct-name} is the construct name itself;
2649 its definition is connoted by the single colon (@samp{:}); and
2650 @var{block-statement} is an @code{IF}, @code{DO},
2651 or @code{SELECT CASE} statement that begins a block.
2653 A block that is given a construct name must also specify the
2654 same construct name in its termination statement:
2657 END @var{block} @var{construct-name}
2661 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
2664 @node CYCLE and EXIT
2665 @subsection The @code{CYCLE} and @code{EXIT} Statements
2667 @cindex CYCLE statement
2668 @cindex EXIT statement
2669 @cindex statements, CYCLE
2670 @cindex statements, EXIT
2671 The @code{CYCLE} and @code{EXIT} statements specify that
2672 the remaining statements in the current iteration of a
2673 particular active (enclosing) @code{DO} loop are to be skipped.
2675 @code{CYCLE} specifies that these statements are skipped,
2676 but the @code{END DO} statement that marks the end of the
2677 @code{DO} loop be executed---that is, the next iteration,
2678 if any, is to be started.
2679 If the statement marking the end of the @code{DO} loop is
2680 not @code{END DO}---in other words, if the loop is not
2681 a block @code{DO}---the @code{CYCLE} statement does not
2682 execute that statement, but does start the next iteration (if any).
2684 @code{EXIT} specifies that the loop specified by the
2685 @code{DO} construct is terminated.
2687 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
2688 is the innermost enclosing @code{DO} loop when the following
2696 Otherwise, the following forms specify the construct name
2697 of the pertinent @code{DO} loop:
2700 CYCLE @var{construct-name}
2701 EXIT @var{construct-name}
2704 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
2706 However, they cannot be easily thought of as @code{GO TO} statements
2707 in obscure cases involving FORTRAN 77 loops.
2716 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2721 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
2722 above are equivalent to a @code{GO TO} statement to either label
2723 @samp{10} or @samp{20}.
2725 To understand the effect of @code{CYCLE} and @code{EXIT} in the
2726 above fragment, it is helpful to first translate it to its equivalent
2727 using only block @code{DO} loops:
2735 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2742 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
2743 to @code{GO TO} so they may be more easily understood by programmers
2744 accustomed to FORTRAN coding:
2749 IF (J .EQ. 5) GOTO 18
2751 IF (K .EQ. 3) GO TO 12
2752 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2760 Thus, the @code{CYCLE} statement in the innermost loop skips over
2761 the @code{PRINT} statement as it begins the next iteration of the
2762 loop, while the @code{EXIT} statement in the middle loop ends that
2763 loop but @emph{not} the outermost loop.
2765 @node Functions and Subroutines
2766 @section Functions and Subroutines
2768 (The following information augments or overrides the information in
2769 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2771 Chapter 15 of that document otherwise serves as the basis
2772 for the relevant aspects of GNU Fortran.)
2778 * Generics and Specifics::
2779 * REAL() and AIMAG() of Complex::
2780 * CMPLX() of DOUBLE PRECISION::
2782 * f77/f2c Intrinsics::
2783 * Table of Intrinsic Functions::
2787 @subsection The @code{%VAL()} Construct
2788 @cindex %VAL() construct
2794 The @code{%VAL()} construct specifies that an argument,
2795 @var{arg}, is to be passed by value, instead of by reference
2798 @code{%VAL()} is restricted to actual arguments in
2799 invocations of external procedures.
2801 Use of @code{%VAL()} is recommended only for code that
2802 is accessing facilities outside of GNU Fortran, such as
2803 operating system or windowing facilities.
2804 It is best to constrain such uses to isolated portions of
2805 a program---portions the deal specifically and exclusively
2806 with low-level, system-dependent facilities.
2807 Such portions might well provide a portable interface for
2808 use by the program as a whole, but are themselves not
2809 portable, and should be thoroughly tested each time they
2810 are rebuilt using a new compiler or version of a compiler.
2812 @emph{Implementation Note:} Currently, @command{g77} passes
2813 all arguments either by reference or by descriptor.
2815 Thus, use of @code{%VAL()} tends to be restricted to cases
2816 where the called procedure is written in a language other
2817 than Fortran that supports call-by-value semantics.
2818 (C is an example of such a language.)
2820 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
2821 for detailed information on
2822 how this particular version of @command{g77} passes arguments
2826 @subsection The @code{%REF()} Construct
2827 @cindex %REF() construct
2833 The @code{%REF()} construct specifies that an argument,
2834 @var{arg}, is to be passed by reference, instead of by
2835 value or descriptor.
2837 @code{%REF()} is restricted to actual arguments in
2838 invocations of external procedures.
2840 Use of @code{%REF()} is recommended only for code that
2841 is accessing facilities outside of GNU Fortran, such as
2842 operating system or windowing facilities.
2843 It is best to constrain such uses to isolated portions of
2844 a program---portions the deal specifically and exclusively
2845 with low-level, system-dependent facilities.
2846 Such portions might well provide a portable interface for
2847 use by the program as a whole, but are themselves not
2848 portable, and should be thoroughly tested each time they
2849 are rebuilt using a new compiler or version of a compiler.
2851 Do not depend on @code{%REF()} supplying a pointer to the
2852 procedure being invoked.
2853 While that is a likely implementation choice, other
2854 implementation choices are available that preserve Fortran
2855 pass-by-reference semantics without passing a pointer to
2856 the argument, @var{arg}.
2857 (For example, a copy-in/copy-out implementation.)
2859 @emph{Implementation Note:} Currently, @command{g77} passes
2861 (other than variables and arrays of type @code{CHARACTER})
2863 Future versions of, or dialects supported by, @command{g77} might
2864 not pass @code{CHARACTER} functions by reference.
2866 Thus, use of @code{%REF()} tends to be restricted to cases
2867 where @var{arg} is type @code{CHARACTER} but the called
2868 procedure accesses it via a means other than the method
2869 used for Fortran @code{CHARACTER} arguments.
2871 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
2872 how this particular version of @command{g77} passes arguments
2876 @subsection The @code{%DESCR()} Construct
2877 @cindex %DESCR() construct
2883 The @code{%DESCR()} construct specifies that an argument,
2884 @var{arg}, is to be passed by descriptor, instead of by
2887 @code{%DESCR()} is restricted to actual arguments in
2888 invocations of external procedures.
2890 Use of @code{%DESCR()} is recommended only for code that
2891 is accessing facilities outside of GNU Fortran, such as
2892 operating system or windowing facilities.
2893 It is best to constrain such uses to isolated portions of
2894 a program---portions the deal specifically and exclusively
2895 with low-level, system-dependent facilities.
2896 Such portions might well provide a portable interface for
2897 use by the program as a whole, but are themselves not
2898 portable, and should be thoroughly tested each time they
2899 are rebuilt using a new compiler or version of a compiler.
2901 Do not depend on @code{%DESCR()} supplying a pointer
2902 and/or a length passed by value
2903 to the procedure being invoked.
2904 While that is a likely implementation choice, other
2905 implementation choices are available that preserve the
2906 pass-by-reference semantics without passing a pointer to
2907 the argument, @var{arg}.
2908 (For example, a copy-in/copy-out implementation.)
2909 And, future versions of @command{g77} might change the
2910 way descriptors are implemented, such as passing a
2911 single argument pointing to a record containing the
2912 pointer/length information instead of passing that same
2913 information via two arguments as it currently does.
2915 @emph{Implementation Note:} Currently, @command{g77} passes
2916 all variables and arrays of type @code{CHARACTER}
2918 Future versions of, or dialects supported by, @command{g77} might
2919 pass @code{CHARACTER} functions by descriptor as well.
2921 Thus, use of @code{%DESCR()} tends to be restricted to cases
2922 where @var{arg} is not type @code{CHARACTER} but the called
2923 procedure accesses it via a means similar to the method
2924 used for Fortran @code{CHARACTER} arguments.
2926 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
2927 how this particular version of @command{g77} passes arguments
2930 @node Generics and Specifics
2931 @subsection Generics and Specifics
2932 @cindex generic intrinsics
2933 @cindex intrinsics, generic
2935 The ANSI FORTRAN 77 language defines generic and specific
2937 In short, the distinctions are:
2941 @emph{Specific} intrinsics have
2942 specific types for their arguments and a specific return
2946 @emph{Generic} intrinsics are treated,
2947 on a case-by-case basis in the program's source code,
2948 as one of several possible specific intrinsics.
2950 Typically, a generic intrinsic has a return type that
2951 is determined by the type of one or more of its arguments.
2954 The GNU Fortran language generalizes these concepts somewhat,
2955 especially by providing intrinsic subroutines and generic
2956 intrinsics that are treated as either a specific intrinsic subroutine
2957 or a specific intrinsic function (e.g. @code{SECOND}).
2959 However, GNU Fortran avoids generalizing this concept to
2960 the point where existing code would be accepted as meaning
2961 something possibly different than what was intended.
2963 For example, @code{ABS} is a generic intrinsic, so all working
2964 code written using @code{ABS} of an @code{INTEGER} argument
2965 expects an @code{INTEGER} return value.
2966 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
2967 argument returns an @code{INTEGER*2} return value.
2969 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
2970 an @code{INTEGER(KIND=1)} argument.
2971 Code that passes something other than an @code{INTEGER(KIND=1)}
2972 argument to @code{IABS} is not valid GNU Fortran code, because
2973 it is not clear what the author intended.
2975 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
2976 is not defined by the GNU Fortran language, because the programmer
2977 might have used that construct to mean any of the following, subtly
2982 Convert @samp{J} to @code{INTEGER(KIND=1)} first
2983 (as if @samp{IABS(INT(J))} had been written).
2986 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
2987 (as if @samp{INT(ABS(J))} had been written).
2990 No conversion (as if @samp{ABS(J)} had been written).
2993 The distinctions matter especially when types and values wider than
2994 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
2995 operations performing more ``arithmetic'' than absolute-value, are involved.
2997 The following sample program is not a valid GNU Fortran program, but
2998 might be accepted by other compilers.
2999 If so, the output is likely to be revealing in terms of how a given
3000 compiler treats intrinsics (that normally are specific) when they
3001 are given arguments that do not conform to their stated requirements:
3003 @cindex JCB002 program
3007 C Modified 1999-02-15 (Burley) to delete my email address.
3008 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
3009 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
3012 C Written by James Craig Burley 1997-02-20.
3015 C Determine how compilers handle non-standard IDIM
3016 C on INTEGER*2 operands, which presumably can be
3017 C extrapolated into understanding how the compiler
3018 C generally treats specific intrinsics that are passed
3019 C arguments not of the correct types.
3021 C If your compiler implements INTEGER*2 and INTEGER
3022 C as the same type, change all INTEGER*2 below to
3027 INTEGER*2 ISMALL, ILARGE
3028 INTEGER*2 ITOOLG, ITWO
3032 C Find smallest INTEGER*2 number.
3036 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
3041 C Find largest INTEGER*2 number.
3045 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
3050 C Multiplying by two adds stress to the situation.
3054 C Need a number that, added to -2, is too wide to fit in I*2.
3058 C Use IDIM the straightforward way.
3060 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
3062 C Calculate result for first interpretation.
3064 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
3066 C Calculate result for second interpretation.
3068 ITMP = ILARGE - ISMALL
3069 I3 = (INT (ITMP)) * ITWO + ITOOLG
3071 C Calculate result for third interpretation.
3073 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
3077 PRINT *, 'ILARGE=', ILARGE
3078 PRINT *, 'ITWO=', ITWO
3079 PRINT *, 'ITOOLG=', ITOOLG
3080 PRINT *, 'ISMALL=', ISMALL
3089 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
3090 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
3093 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
3094 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
3097 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
3098 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
3101 PRINT *, 'Results need careful analysis.'
3105 No future version of the GNU Fortran language
3106 will likely permit specific intrinsic invocations with wrong-typed
3107 arguments (such as @code{IDIM} in the above example), since
3108 it has been determined that disagreements exist among
3109 many production compilers on the interpretation of
3111 These disagreements strongly suggest that Fortran programmers,
3112 and certainly existing Fortran programs, disagree about the
3113 meaning of such invocations.
3115 The first version of @code{JCB002} didn't accommodate some compilers'
3116 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
3118 In such a case, these compilers apparently convert both
3119 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
3120 instead of doing an @code{INTEGER*2} subtraction on the
3121 original values in @samp{I1} and @samp{I2}.
3123 However, the results of the careful analyses done on the outputs
3124 of programs compiled by these various compilers show that they
3125 all implement either @samp{Interp 1} or @samp{Interp 2} above.
3127 Specifically, it is believed that the new version of @code{JCB002}
3128 above will confirm that:
3132 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
3133 @command{f77} compilers all implement @samp{Interp 1}.
3136 IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}.
3139 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
3140 and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}.
3143 If you get different results than the above for the stated
3144 compilers, or have results for other compilers that might be
3145 worth adding to the above list, please let us know the details
3146 (compiler product, version, machine, results, and so on).
3148 @node REAL() and AIMAG() of Complex
3149 @subsection @code{REAL()} and @code{AIMAG()} of Complex
3150 @cindex @code{Real} intrinsic
3151 @cindex intrinsics, @code{Real}
3152 @cindex @code{AImag} intrinsic
3153 @cindex intrinsics, @code{AImag}
3155 The GNU Fortran language disallows @code{REAL(@var{expr})}
3156 and @code{AIMAG(@var{expr})},
3157 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
3158 except when they are used in the following way:
3161 REAL(REAL(@var{expr}))
3162 REAL(AIMAG(@var{expr}))
3166 The above forms explicitly specify that the desired effect
3167 is to convert the real or imaginary part of @var{expr}, which might
3168 be some @code{REAL} type other than @code{REAL(KIND=1)},
3169 to type @code{REAL(KIND=1)},
3170 and have that serve as the value of the expression.
3172 The GNU Fortran language offers clearly named intrinsics to extract the
3173 real and imaginary parts of a complex entity without any
3177 REALPART(@var{expr})
3178 IMAGPART(@var{expr})
3181 To express the above using typical extended FORTRAN 77,
3182 use the following constructs
3183 (when @var{expr} is @code{COMPLEX(KIND=2)}):
3190 The FORTRAN 77 language offers no way
3191 to explicitly specify the real and imaginary parts of a complex expression of
3192 arbitrary type, apparently as a result of requiring support for
3193 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
3194 The concepts of converting an expression to type @code{REAL(KIND=1)} and
3195 of extracting the real part of a complex expression were
3196 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
3197 they happened to have the exact same effect in that language
3198 (due to having only one @code{COMPLEX} type).
3200 @emph{Note:} When @option{-ff90} is in effect,
3201 @command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
3202 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
3203 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
3204 treated as @samp{REAL(REALPART(@var{expr}))}.
3206 @xref{Ugly Complex Part Extraction}, for more information.
3208 @node CMPLX() of DOUBLE PRECISION
3209 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
3210 @cindex @code{Cmplx} intrinsic
3211 @cindex intrinsics, @code{Cmplx}
3213 In accordance with Fortran 90 and at least some (perhaps all)
3214 other compilers, the GNU Fortran language defines @code{CMPLX()}
3215 as always returning a result that is type @code{COMPLEX(KIND=1)}.
3217 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
3218 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
3221 CMPLX(SNGL(D1), SNGL(D2))
3224 (It was necessary for Fortran 90 to specify this behavior
3225 for @code{DOUBLE PRECISION} arguments, since that is
3226 the behavior mandated by FORTRAN 77.)
3228 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
3229 which is provided by some FORTRAN 77 compilers to construct
3230 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
3232 However, this solution does not scale well when more @code{COMPLEX} types
3233 (having various precisions and ranges) are offered by Fortran implementations.
3235 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
3236 an extra argument used to specify the desired kind of complex
3238 However, this solution is somewhat awkward to use, and
3239 @command{g77} currently does not support it.
3241 The GNU Fortran language provides a simple way to build a complex
3242 value out of two numbers, with the precise type of the value
3243 determined by the types of the two numbers (via the usual
3244 type-promotion mechanism):
3247 COMPLEX(@var{real}, @var{imag})
3250 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
3251 performs no conversion other than to put them together to form a
3252 complex result of the same (complex version of real) type.
3254 @xref{Complex Intrinsic}, for more information.
3257 @subsection MIL-STD 1753 Support
3258 @cindex MIL-STD 1753
3260 The GNU Fortran language includes the MIL-STD 1753 intrinsics
3261 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
3262 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
3263 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
3265 @node f77/f2c Intrinsics
3266 @subsection @command{f77}/@command{f2c} Intrinsics
3268 The bit-manipulation intrinsics supported by traditional
3269 @command{f77} and by @command{f2c} are available in the GNU Fortran language.
3270 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
3273 Also supported are the intrinsics @code{CDABS},
3274 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
3275 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
3276 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
3277 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
3280 @node Table of Intrinsic Functions
3281 @subsection Table of Intrinsic Functions
3282 @cindex intrinsics, table of
3283 @cindex table of intrinsics
3285 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
3287 The GNU Fortran language adds various functions, subroutines, types,
3288 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
3289 The complete set of intrinsics supported by the GNU Fortran language
3292 Note that a name is not treated as that of an intrinsic if it is
3293 specified in an @code{EXTERNAL} statement in the same program unit;
3294 if a command-line option is used to disable the groups to which
3295 the intrinsic belongs; or if the intrinsic is not named in an
3296 @code{INTRINSIC} statement and a command-line option is used to
3297 hide the groups to which the intrinsic belongs.
3299 So, it is recommended that any reference in a program unit to
3300 an intrinsic procedure that is not a standard FORTRAN 77
3301 intrinsic be accompanied by an appropriate @code{INTRINSIC}
3302 statement in that program unit.
3303 This sort of defensive programming makes it more
3304 likely that an implementation will issue a diagnostic rather
3305 than generate incorrect code for such a reference.
3307 The terminology used below is based on that of the Fortran 90
3308 standard, so that the text may be more concise and accurate:
3312 @code{OPTIONAL} means the argument may be omitted.
3315 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
3316 (generally named @samp{A}) may be specified.
3319 @samp{scalar} means the argument must not be an array (must
3320 be a variable or array element, or perhaps a constant if expressions
3324 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
3327 @code{INTENT(IN)} means the argument must be an expression
3328 (such as a constant or a variable that is defined upon invocation
3332 @code{INTENT(OUT)} means the argument must be definable by the
3333 invocation of the intrinsic (that is, must not be a constant nor
3334 an expression involving operators other than array reference and
3335 substring reference).
3338 @code{INTENT(INOUT)} means the argument must be defined prior to,
3339 and definable by, invocation of the intrinsic (a combination of
3340 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
3343 @xref{Kind Notation}, for an explanation of @code{KIND}.
3347 (Note that the empty lines appearing in the menu below
3348 are not intentional---they result from a bug in the
3349 GNU @command{makeinfo} program@dots{}a program that, if it
3350 did not exist, would leave this document in far worse shape!)
3353 @c The actual documentation for intrinsics comes from
3354 @c intdoc.texi, which in turn is automatically generated
3355 @c from the internal g77 tables in intrin.def _and_ the
3356 @c largely hand-written text in intdoc.h. So, if you want
3357 @c to change or add to existing documentation on intrinsics,
3358 @c you probably want to edit intdoc.h.
3370 @include intdoc.texi
3372 @node Scope and Classes of Names
3373 @section Scope and Classes of Symbolic Names
3374 @cindex symbol names, scope and classes
3377 (The following information augments or overrides the information in
3378 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3380 Chapter 18 of that document otherwise serves as the basis
3381 for the relevant aspects of GNU Fortran.)
3384 * Underscores in Symbol Names::
3387 @node Underscores in Symbol Names
3388 @subsection Underscores in Symbol Names
3391 Underscores (@samp{_}) are accepted in symbol names after the first
3392 character (which must be a letter).
3398 A dollar sign at the end of an output format specification suppresses
3399 the newline at the end of the output.
3401 @cindex <> edit descriptor
3402 @cindex edit descriptor, <>
3403 Edit descriptors in @code{FORMAT} statements may contain compile-time
3404 @code{INTEGER} constant expressions in angle brackets, such as
3406 10 FORMAT (I<WIDTH>)
3409 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
3411 These Fortran 90 features are supported:
3414 @cindex FORMAT descriptors
3415 @cindex Z edit descriptor
3416 @cindex edit descriptor, Z
3417 @cindex O edit descriptor
3418 @cindex edit descriptor, O
3419 The @code{O} and @code{Z} edit descriptors are supported for I/O of
3420 integers in octal and hexadecimal formats, respectively.
3422 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
3423 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
3424 specifier is supported.
3427 @node Fortran 90 Features
3428 @section Fortran 90 Features
3430 @cindex extensions, from Fortran 90
3432 For convenience this section collects a list (probably incomplete) of
3433 the Fortran 90 features supported by the GNU Fortran language, even if
3434 they are documented elsewhere.
3435 @xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
3436 for information on additional fixed source form lexical issues.
3437 @cindex @option{-ffree-form}
3438 Further, the free source form is supported through the
3439 @option{-ffree-form} option.
3440 @cindex @option{-ff90}
3441 Other Fortran 90 features can be turned on by the @option{-ff90} option;
3442 see @ref{Fortran 90}.
3443 For information on the Fortran 90 intrinsics available,
3444 see @ref{Table of Intrinsic Functions}.
3447 @item Automatic arrays in procedures
3448 @item Character assignments
3449 @cindex character assignments
3450 In character assignments, the variable being assigned may occur on the
3451 right hand side of the assignment.
3452 @item Character strings
3453 @cindex double quoted character constants
3454 Strings may have zero length and substrings of character constants are
3455 permitted. Character constants may be enclosed in double quotes
3456 (@code{"}) as well as single quotes. @xref{Character Type}.
3457 @item Construct names
3458 (Symbolic tags on blocks.) @xref{Construct Names}.
3459 @item @code{CYCLE} and @code{EXIT}
3460 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
3461 @item @code{DOUBLE COMPLEX}
3462 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
3463 @item @code{DO WHILE}
3465 @item @code{END} decoration
3470 @item @code{IMPLICIT NONE}
3471 @item @code{INCLUDE} statements
3473 @item List-directed and namelist I/O on internal files
3474 @item Binary, octal and hexadecimal constants
3475 These are supported more generally than required by Fortran 90.
3476 @xref{Integer Type}.
3477 @item @samp{O} and @samp{Z} edit descriptors
3478 @item @code{NAMELIST}
3480 @item @code{OPEN} specifiers
3481 @code{STATUS='REPLACE'} is supported.
3482 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
3483 @code{STATUS='SCRATCH'} is supplied.
3484 @item @code{FORMAT} edit descriptors
3485 @cindex FORMAT descriptors
3486 @cindex Z edit descriptor
3487 @cindex edit descriptor, Z
3488 The @code{Z} edit descriptor is supported.
3489 @item Relational operators
3490 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
3491 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
3492 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
3493 @item @code{SELECT CASE}
3494 Not fully implemented.
3495 @xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
3496 @item Specification statements
3497 A limited subset of the Fortran 90 syntax and semantics for variable
3498 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
3499 (@code{KIND} is of limited usefulness in the absence of the
3500 @code{KIND}-related intrinsics, since these intrinsics permit writing
3501 more widely portable code.) An example of supported @code{KIND} usage
3504 INTEGER (KIND=1) :: FOO=1, BAR=2
3505 CHARACTER (LEN=3) FOO
3507 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
3510 @node Other Dialects
3511 @chapter Other Dialects
3513 GNU Fortran supports a variety of features that are not
3514 considered part of the GNU Fortran language itself, but
3515 are representative of various dialects of Fortran that
3516 @command{g77} supports in whole or in part.
3518 Any of the features listed below might be disallowed by
3519 @command{g77} unless some command-line option is specified.
3520 Currently, some of the features are accepted using the
3521 default invocation of @command{g77}, but that might change
3524 @emph{Note: This portion of the documentation definitely needs a lot
3528 * Source Form:: Details of fixed-form and free-form source.
3529 * Trailing Comment:: Use of @samp{/*} to start a comment.
3530 * Debug Line:: Use of @samp{D} in column 1.
3531 * Dollar Signs:: Use of @samp{$} in symbolic names.
3532 * Case Sensitivity:: Uppercase and lowercase in source files.
3533 * VXT Fortran:: @dots{}versus the GNU Fortran language.
3534 * Fortran 90:: @dots{}versus the GNU Fortran language.
3535 * Pedantic Compilation:: Enforcing the standard.
3536 * Distensions:: Misfeatures supported by GNU Fortran.
3540 @section Source Form
3541 @cindex source file format
3542 @cindex source format
3543 @cindex file, source
3545 @cindex code, source
3549 GNU Fortran accepts programs written in either fixed form or
3553 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
3554 allowing tabs) and Fortran 90's fixed form.
3556 Free form corresponds to
3557 Fortran 90's free form (though possibly not entirely up-to-date, and
3558 without complaining about some things that for which Fortran 90 requires
3559 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
3561 The way a Fortran compiler views source files depends entirely on the
3562 implementation choices made for the compiler, since those choices
3563 are explicitly left to the implementation by the published Fortran
3565 GNU Fortran currently tries to be somewhat like a few popular compilers
3566 (@command{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
3567 definition along with more
3568 flexibility offered by command-line options is likely to be offered
3571 This section describes how @command{g77} interprets source lines.
3574 * Carriage Returns:: Carriage returns ignored.
3575 * Tabs:: Tabs converted to spaces.
3576 * Short Lines:: Short lines padded with spaces (fixed-form only).
3577 * Long Lines:: Long lines truncated.
3578 * Ampersands:: Special Continuation Lines.
3581 @node Carriage Returns
3582 @subsection Carriage Returns
3583 @cindex carriage returns
3585 Carriage returns (@samp{\r}) in source lines are ignored.
3586 This is somewhat different from @command{f2c}, which seems to treat them as
3587 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
3588 inside such constants.
3592 @cindex tab character
3593 @cindex horizontal tab
3595 A source line with a @key{TAB} character anywhere in it is treated as
3596 entirely significant---however long it is---instead of ending in
3597 column 72 (for fixed-form source) or 132 (for free-form source).
3598 This also is different from @command{f2c}, which encodes tabs as
3599 @samp{\t} (the ASCII @key{TAB} character) inside character
3600 and Hollerith constants, but nevertheless seems to treat the column
3601 position as if it had been affected by the canonical tab positioning.
3603 @command{g77} effectively
3604 translates tabs to the appropriate number of spaces (a la the default
3605 for the UNIX @command{expand} command) before doing any other processing, other
3606 than (currently) noting whether a tab was found on a line and using this
3607 information to decide how to interpret the length of the line and continued
3610 Note that this default behavior probably will change for version 0.6,
3611 when it will presumably be available via a command-line option.
3612 The default as of version 0.6 is planned to be a ``pure visual''
3613 model, where tabs are immediately
3614 converted to spaces and otherwise have no effect, so the way a typical
3615 user sees source lines produces a consistent result no matter how the
3616 spacing in those source lines is actually implemented via tabs, spaces,
3617 and trailing tabs/spaces before newline.
3618 Command-line options are likely to be added to specify whether all or
3619 just-tabbed lines are to be extended to 132 or full input-line length,
3620 and perhaps even an option will be added to specify the truncated-line
3621 behavior to which some Digital compilers default (and which affects
3622 the way continued character/Hollerith constants are interpreted).
3625 @subsection Short Lines
3626 @cindex short source lines
3627 @cindex space, padding with
3628 @cindex source lines, short
3629 @cindex lines, short
3631 Source lines shorter than the applicable fixed-form length are treated as
3632 if they were padded with spaces to that length.
3633 (None of this is relevant to source files written in free form.)
3636 continued character and Hollerith constants, and is a different
3637 interpretation than provided by some other popular compilers
3638 (although a bit more consistent with the traditional punched-card
3639 basis of Fortran and the way the Fortran standard expressed fixed
3642 @command{g77} might someday offer an option to warn about cases where differences
3643 might be seen as a result of this treatment, and perhaps an option to
3644 specify the alternate behavior as well.
3646 Note that this padding cannot apply to lines that are effectively of
3647 infinite length---such lines are specified using command-line options
3648 like @option{-ffixed-line-length-none}, for example.
3651 @subsection Long Lines
3652 @cindex long source lines
3653 @cindex truncation, of long lines
3655 @cindex source lines, long
3657 Source lines longer than the applicable length are truncated to that
3659 Currently, @command{g77} does not warn if the truncated characters are
3660 not spaces, to accommodate existing code written for systems that
3661 treated truncated text as commentary (especially in columns 73 through 80).
3663 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
3664 for information on the @option{-ffixed-line-length-@var{n}} option,
3665 which can be used to set the line length applicable to fixed-form
3669 @subsection Ampersand Continuation Line
3670 @cindex ampersand continuation line
3671 @cindex continuation line, ampersand
3673 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
3674 continuation line, imitating the behavior of @command{f2c}.
3676 @node Trailing Comment
3677 @section Trailing Comment
3679 @cindex trailing comment
3681 @cindex characters, comment
3684 @cindex exclamation point
3685 @command{g77} supports use of @samp{/*} to start a trailing
3687 In the GNU Fortran language, @samp{!} is used for this purpose.
3689 @samp{/*} is not in the GNU Fortran language
3690 because the use of @samp{/*} in a program might
3691 suggest to some readers that a block, not trailing, comment is
3692 started (and thus ended by @samp{*/}, not end of line),
3693 since that is the meaning of @samp{/*} in C.
3695 Also, such readers might think they can use @samp{//} to start
3696 a trailing comment as an alternative to @samp{/*}, but
3697 @samp{//} already denotes concatenation, and such a ``comment''
3698 might actually result in a program that compiles without
3699 error (though it would likely behave incorrectly).
3704 @cindex comment line, debug
3706 Use of @samp{D} or @samp{d} as the first character (column 1) of
3707 a source line denotes a debug line.
3709 In turn, a debug line is treated as either a comment line
3710 or a normal line, depending on whether debug lines are enabled.
3712 When treated as a comment line, a line beginning with @samp{D} or
3713 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
3714 When treated as a normal line, such a line is treated as if
3715 the first character was @key{SPC} (space).
3717 (Currently, @command{g77} provides no means for treating debug
3718 lines as normal lines.)
3721 @section Dollar Signs in Symbol Names
3725 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
3726 when the @option{-fdollar-ok} option is specified.
3728 @node Case Sensitivity
3729 @section Case Sensitivity
3730 @cindex case sensitivity
3731 @cindex source file format
3732 @cindex code, source
3734 @cindex uppercase letters
3735 @cindex lowercase letters
3736 @cindex letters, uppercase
3737 @cindex letters, lowercase
3739 GNU Fortran offers the programmer way too much flexibility in deciding
3740 how source files are to be treated vis-a-vis uppercase and lowercase
3742 There are 66 useful settings that affect case sensitivity, plus 10
3743 settings that are nearly useless, with the remaining 116 settings
3744 being either redundant or useless.
3746 None of these settings have any effect on the contents of comments
3747 (the text after a @samp{c} or @samp{C} in Column 1, for example)
3748 or of character or Hollerith constants.
3749 Note that things like the @samp{E} in the statement
3750 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
3751 are considered built-in keywords, and so are affected by
3754 Low-level switches are identified in this section as follows:
3758 Source Case Conversion:
3762 Preserve (see Note 1)
3764 Convert to Upper Case
3766 Convert to Lower Case
3770 Built-in Keyword Matching:
3774 Match Any Case (per-character basis)
3776 Match Upper Case Only
3778 Match Lower Case Only
3780 Match InitialCaps Only (see tables for spellings)
3784 Built-in Intrinsic Matching:
3788 Match Any Case (per-character basis)
3790 Match Upper Case Only
3792 Match Lower Case Only
3794 Match InitialCaps Only (see tables for spellings)
3798 User-defined Symbol Possibilities (warnings only):
3802 Allow Any Case (per-character basis)
3804 Allow Upper Case Only
3806 Allow Lower Case Only
3808 Allow InitialCaps Only (see Note 2)
3812 Note 1: @command{g77} eventually will support @code{NAMELIST} in a manner that is
3813 consistent with these source switches---in the sense that input will be
3814 expected to meet the same requirements as source code in terms
3815 of matching symbol names and keywords (for the exponent letters).
3817 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
3818 which uppercases @code{NAMELIST} input and symbol names for matching.
3819 This means not only that @code{NAMELIST} output currently shows symbol
3820 (and keyword) names in uppercase even if lower-case source
3821 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
3822 adequately supported when source case preservation (option A0)
3825 If A0 is selected, a warning message will be
3826 output for each @code{NAMELIST} statement to this effect.
3828 of the program is undefined at run time if two or more symbol names
3829 appear in a given @code{NAMELIST} such that the names are identical
3830 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
3831 For complete and total elegance, perhaps there should be a warning
3832 when option A2 is selected, since the output of NAMELIST is currently
3833 in uppercase but will someday be lowercase (when a @code{libg77} is written),
3834 but that seems to be overkill for a product in beta test.
3836 Note 2: Rules for InitialCaps names are:
3840 Must be a single uppercase letter, @strong{or}
3842 Must start with an uppercase letter and contain at least one
3846 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
3847 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
3849 Note that most, but not all, built-in names meet these
3850 requirements---the exceptions are some of the two-letter format
3851 specifiers, such as @code{BN} and @code{BZ}.
3853 Here are the names of the corresponding command-line options:
3856 A0: -fsource-case-preserve
3857 A1: -fsource-case-upper
3858 A2: -fsource-case-lower
3860 B0: -fmatch-case-any
3861 B1: -fmatch-case-upper
3862 B2: -fmatch-case-lower
3863 B3: -fmatch-case-initcap
3865 C0: -fintrin-case-any
3866 C1: -fintrin-case-upper
3867 C2: -fintrin-case-lower
3868 C3: -fintrin-case-initcap
3870 D0: -fsymbol-case-any
3871 D1: -fsymbol-case-upper
3872 D2: -fsymbol-case-lower
3873 D3: -fsymbol-case-initcap
3876 Useful combinations of the above settings, along with abbreviated
3877 option names that set some of these combinations all at once:
3880 1: A0-- B0--- C0--- D0--- -fcase-preserve
3881 2: A0-- B0--- C0--- D-1--
3882 3: A0-- B0--- C0--- D--2-
3883 4: A0-- B0--- C0--- D---3
3884 5: A0-- B0--- C-1-- D0---
3885 6: A0-- B0--- C-1-- D-1--
3886 7: A0-- B0--- C-1-- D--2-
3887 8: A0-- B0--- C-1-- D---3
3888 9: A0-- B0--- C--2- D0---
3889 10: A0-- B0--- C--2- D-1--
3890 11: A0-- B0--- C--2- D--2-
3891 12: A0-- B0--- C--2- D---3
3892 13: A0-- B0--- C---3 D0---
3893 14: A0-- B0--- C---3 D-1--
3894 15: A0-- B0--- C---3 D--2-
3895 16: A0-- B0--- C---3 D---3
3896 17: A0-- B-1-- C0--- D0---
3897 18: A0-- B-1-- C0--- D-1--
3898 19: A0-- B-1-- C0--- D--2-
3899 20: A0-- B-1-- C0--- D---3
3900 21: A0-- B-1-- C-1-- D0---
3901 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
3902 23: A0-- B-1-- C-1-- D--2-
3903 24: A0-- B-1-- C-1-- D---3
3904 25: A0-- B-1-- C--2- D0---
3905 26: A0-- B-1-- C--2- D-1--
3906 27: A0-- B-1-- C--2- D--2-
3907 28: A0-- B-1-- C--2- D---3
3908 29: A0-- B-1-- C---3 D0---
3909 30: A0-- B-1-- C---3 D-1--
3910 31: A0-- B-1-- C---3 D--2-
3911 32: A0-- B-1-- C---3 D---3
3912 33: A0-- B--2- C0--- D0---
3913 34: A0-- B--2- C0--- D-1--
3914 35: A0-- B--2- C0--- D--2-
3915 36: A0-- B--2- C0--- D---3
3916 37: A0-- B--2- C-1-- D0---
3917 38: A0-- B--2- C-1-- D-1--
3918 39: A0-- B--2- C-1-- D--2-
3919 40: A0-- B--2- C-1-- D---3
3920 41: A0-- B--2- C--2- D0---
3921 42: A0-- B--2- C--2- D-1--
3922 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
3923 44: A0-- B--2- C--2- D---3
3924 45: A0-- B--2- C---3 D0---
3925 46: A0-- B--2- C---3 D-1--
3926 47: A0-- B--2- C---3 D--2-
3927 48: A0-- B--2- C---3 D---3
3928 49: A0-- B---3 C0--- D0---
3929 50: A0-- B---3 C0--- D-1--
3930 51: A0-- B---3 C0--- D--2-
3931 52: A0-- B---3 C0--- D---3
3932 53: A0-- B---3 C-1-- D0---
3933 54: A0-- B---3 C-1-- D-1--
3934 55: A0-- B---3 C-1-- D--2-
3935 56: A0-- B---3 C-1-- D---3
3936 57: A0-- B---3 C--2- D0---
3937 58: A0-- B---3 C--2- D-1--
3938 59: A0-- B---3 C--2- D--2-
3939 60: A0-- B---3 C--2- D---3
3940 61: A0-- B---3 C---3 D0---
3941 62: A0-- B---3 C---3 D-1--
3942 63: A0-- B---3 C---3 D--2-
3943 64: A0-- B---3 C---3 D---3 -fcase-initcap
3944 65: A-1- B01-- C01-- D01-- -fcase-upper
3945 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
3948 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
3949 (except comments, character constants, and Hollerith strings) must
3950 be entered in uppercase.
3951 Use @option{-fcase-strict-upper} to specify this
3954 Number 43 is like Number 22 except all input must be lowercase. Use
3955 @option{-fcase-strict-lower} to specify this combination.
3957 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
3958 non-UNIX machines whereby all the source is translated to uppercase.
3959 Use @option{-fcase-upper} to specify this combination.
3961 Number 66 is the ``canonical'' UNIX model whereby all the source is
3962 translated to lowercase.
3963 Use @option{-fcase-lower} to specify this combination.
3965 There are a few nearly useless combinations:
3968 67: A-1- B01-- C01-- D--2-
3969 68: A-1- B01-- C01-- D---3
3970 69: A-1- B01-- C--23 D01--
3971 70: A-1- B01-- C--23 D--2-
3972 71: A-1- B01-- C--23 D---3
3973 72: A--2 B01-- C0-2- D-1--
3974 73: A--2 B01-- C0-2- D---3
3975 74: A--2 B01-- C-1-3 D0-2-
3976 75: A--2 B01-- C-1-3 D-1--
3977 76: A--2 B01-- C-1-3 D---3
3980 The above allow some programs to be compiled but with restrictions that
3981 make most useful programs impossible: Numbers 67 and 72 warn about
3982 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
3984 68 and 73 warn about any user-defined symbol names longer than one
3985 character that don't have at least one non-alphabetic character after
3987 Numbers 69 and 74 disallow any references to intrinsics;
3988 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
3989 67+69, 68+69, 72+74, and 73+74, respectively.
3991 All redundant combinations are shown in the above tables anyplace
3992 where more than one setting is shown for a low-level switch.
3993 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
3994 The ``proper'' setting in such a case is the one that copies the setting
3995 of switch A---any other setting might slightly reduce the speed of
3996 the compiler, though possibly to an unmeasurable extent.
3998 All remaining combinations are useless in that they prevent successful
3999 compilation of non-null source files (source files with something other
4003 @section VXT Fortran
4005 @cindex VXT extensions
4006 @cindex extensions, VXT
4007 @command{g77} supports certain constructs that
4008 have different meanings in VXT Fortran than they
4009 do in the GNU Fortran language.
4011 Generally, this manual uses the invented term VXT Fortran to refer
4012 VAX FORTRAN (circa v4).
4013 That compiler offered many popular features, though not necessarily
4014 those that are specific to the VAX processor architecture,
4015 the VMS operating system,
4016 or Digital Equipment Corporation's Fortran product line.
4017 (VAX and VMS probably are trademarks of Digital Equipment
4020 An extension offered by a Digital Fortran product that also is
4021 offered by several other Fortran products for different kinds of
4022 systems is probably going to be considered for inclusion in @command{g77}
4023 someday, and is considered a VXT Fortran feature.
4025 The @option{-fvxt} option generally specifies that, where
4026 the meaning of a construct is ambiguous (means one thing
4027 in GNU Fortran and another in VXT Fortran), the VXT Fortran
4028 meaning is to be assumed.
4031 * Double Quote Meaning:: @samp{"2000} as octal constant.
4032 * Exclamation Point:: @samp{!} in column 6.
4035 @node Double Quote Meaning
4036 @subsection Meaning of Double Quote
4037 @cindex double quotes
4038 @cindex character constants
4039 @cindex constants, character
4040 @cindex octal constants
4041 @cindex constants, octal
4043 @command{g77} treats double-quote (@samp{"})
4044 as beginning an octal constant of @code{INTEGER(KIND=1)} type
4045 when the @option{-fvxt} option is specified.
4046 The form of this octal constant is
4053 where @var{octal-digits} is a nonempty string of characters in
4054 the set @samp{01234567}.
4056 For example, the @option{-fvxt} option permits this:
4064 The above program would print the value @samp{16}.
4066 @xref{Integer Type}, for information on the preferred construct
4067 for integer constants specified using GNU Fortran's octal notation.
4069 (In the GNU Fortran language, the double-quote character (@samp{"})
4070 delimits a character constant just as does apostrophe (@samp{'}).
4071 There is no way to allow
4072 both constructs in the general case, since statements like
4073 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
4075 @node Exclamation Point
4076 @subsection Meaning of Exclamation Point in Column 6
4078 @cindex exclamation point
4079 @cindex continuation character
4080 @cindex characters, continuation
4081 @cindex comment character
4082 @cindex characters, comment
4084 @command{g77} treats an exclamation point (@samp{!}) in column 6 of
4085 a fixed-form source file
4086 as a continuation character rather than
4087 as the beginning of a comment
4088 (as it does in any other column)
4089 when the @option{-fvxt} option is specified.
4091 The following program, when run, prints a message indicating
4092 whether it is interpreted according to GNU Fortran (and Fortran 90)
4093 rules or VXT Fortran rules:
4096 C234567 (This line begins in column 1.)
4099 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
4100 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
4101 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
4105 (In the GNU Fortran and Fortran 90 languages, exclamation point is
4106 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
4107 marks a line as a continuation line when it appears in column 6.)
4111 @cindex compatibility, Fortran 90
4112 @cindex Fortran 90, compatibility
4114 The GNU Fortran language includes a number of features that are
4115 part of Fortran 90, even when the @option{-ff90} option is not specified.
4116 The features enabled by @option{-ff90} are intended to be those that,
4117 when @option{-ff90} is not specified, would have another
4118 meaning to @command{g77}---usually meaning something invalid in the
4119 GNU Fortran language.
4121 So, the purpose of @option{-ff90} is not to specify whether @command{g77} is
4122 to gratuitously reject Fortran 90 constructs.
4123 The @option{-pedantic} option specified with @option{-fno-f90} is intended
4124 to do that, although its implementation is certainly incomplete at
4127 When @option{-ff90} is specified:
4131 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
4132 where @var{expr} is @code{COMPLEX} type,
4133 is the same type as the real part of @var{expr}.
4135 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
4136 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
4137 not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified.
4140 @node Pedantic Compilation
4141 @section Pedantic Compilation
4142 @cindex pedantic compilation
4143 @cindex compilation, pedantic
4145 The @option{-fpedantic} command-line option specifies that @command{g77}
4146 is to warn about code that is not standard-conforming.
4147 This is useful for finding
4148 some extensions @command{g77} accepts that other compilers might not accept.
4149 (Note that the @option{-pedantic} and @option{-pedantic-errors} options
4150 always imply @option{-fpedantic}.)
4152 With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
4153 for conforming code.
4154 With @option{-ff90} in force, Fortran 90 is used.
4156 The constructs for which @command{g77} issues diagnostics when @option{-fpedantic}
4157 and @option{-fno-f90} are in force are:
4161 Automatic arrays, as in
4170 where @samp{A} is not listed in any @code{ENTRY} statement,
4171 and thus is not a dummy argument.
4174 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
4176 These commas are disallowed by FORTRAN 77, but, while strictly
4177 superfluous, are syntactically elegant,
4178 especially given that commas are required in statements such
4179 as @samp{READ 99, I} and @samp{PRINT *, J}.
4180 Many compilers permit the superfluous commas for this reason.
4183 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
4185 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
4186 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
4188 An example of an implicit use is the expression @samp{C*D},
4189 where @samp{C} is @code{COMPLEX(KIND=1)}
4190 and @samp{D} is @code{DOUBLE PRECISION}.
4191 This expression is prohibited by ANSI FORTRAN 77
4192 because the rules of promotion would suggest that it
4193 produce a @code{DOUBLE COMPLEX} result---a type not
4194 provided for by that standard.
4197 Automatic conversion of numeric
4198 expressions to @code{INTEGER(KIND=1)} in contexts such as:
4202 Array-reference indexes.
4204 Alternate-return values.
4206 Computed @code{GOTO}.
4208 @code{FORMAT} run-time expressions (not yet supported).
4210 Dimension lists in specification statements.
4212 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
4214 Sizes of @code{CHARACTER} entities in specification statements.
4216 Kind types in specification entities (a Fortran 90 feature).
4218 Initial, terminal, and incrementation parameters for implied-@code{DO}
4219 constructs in @code{DATA} statements.
4223 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
4224 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
4225 expressions are disallowed anyway).
4228 Zero-size array dimensions, as in:
4231 INTEGER I(10,20,4:2)
4235 Zero-length @code{CHARACTER} entities, as in:
4242 Substring operators applied to character constants and named
4246 PRINT *, 'hello'(3:5)
4250 Null arguments passed to statement function, as in:
4257 Disagreement among program units regarding whether a given @code{COMMON}
4258 area is @code{SAVE}d (for targets where program units in a single source
4259 file are ``glued'' together as they typically are for UNIX development
4263 Disagreement among program units regarding the size of a
4264 named @code{COMMON} block.
4267 Specification statements following first @code{DATA} statement.
4269 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
4270 but not @samp{INTEGER I}.
4271 The @option{-fpedantic} option disallows both of these.)
4274 Semicolon as statement separator, as in:
4281 @c Comma before list of I/O items in @code{WRITE}
4282 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
4283 @c statements, as with @code{READ} (as explained above).
4286 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
4289 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
4293 Expressions having two arithmetic operators in a row, such
4297 If @option{-fpedantic} is specified along with @option{-ff90}, the
4298 following constructs result in diagnostics:
4302 Use of semicolon as a statement separator on a line
4303 that has an @code{INCLUDE} directive.
4307 @section Distensions
4309 @cindex ugly features
4310 @cindex features, ugly
4312 The @option{-fugly-*} command-line options determine whether certain
4313 features supported by VAX FORTRAN and other such compilers, but considered
4314 too ugly to be in code that can be changed to use safer and/or more
4315 portable constructs, are accepted.
4316 These are humorously referred to as ``distensions'',
4317 extensions that just plain look ugly in the harsh light of day.
4320 * Ugly Implicit Argument Conversion:: Disabled via @option{-fno-ugly-args}.
4321 * Ugly Assumed-Size Arrays:: Enabled via @option{-fugly-assumed}.
4322 * Ugly Null Arguments:: Enabled via @option{-fugly-comma}.
4323 * Ugly Complex Part Extraction:: Enabled via @option{-fugly-complex}.
4324 * Ugly Conversion of Initializers:: Disabled via @option{-fno-ugly-init}.
4325 * Ugly Integer Conversions:: Enabled via @option{-fugly-logint}.
4326 * Ugly Assigned Labels:: Enabled via @option{-fugly-assign}.
4329 @node Ugly Implicit Argument Conversion
4330 @subsection Implicit Argument Conversion
4331 @cindex Hollerith constants
4332 @cindex constants, Hollerith
4334 The @option{-fno-ugly-args} option disables
4335 passing typeless and Hollerith constants as actual arguments
4336 in procedure invocations.
4345 These constructs can be too easily used to create non-portable
4346 code, but are not considered as ``ugly'' as others.
4347 Further, they are widely used in existing Fortran source code
4348 in ways that often are quite portable.
4349 Therefore, they are enabled by default.
4351 @node Ugly Assumed-Size Arrays
4352 @subsection Ugly Assumed-Size Arrays
4353 @cindex arrays, assumed-size
4354 @cindex assumed-size arrays
4355 @cindex DIMENSION X(1)
4357 The @option{-fugly-assumed} option enables
4358 the treatment of any array with a final dimension specified as @samp{1}
4359 as an assumed-size array, as if @samp{*} had been specified
4362 For example, @samp{DIMENSION X(1)} is treated as if it
4363 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
4364 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
4365 or @code{ENTRY} statement in the same program unit.
4367 Use an explicit lower bound to avoid this interpretation.
4368 For example, @samp{DIMENSION X(1:1)} is never treated as if
4369 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
4370 Nor is @samp{DIMENSION X(2-1)} affected by this option,
4371 since that kind of expression is unlikely to have been
4372 intended to designate an assumed-size array.
4374 This option is used to prevent warnings being issued about apparent
4375 out-of-bounds reference such as @samp{X(2) = 99}.
4377 It also prevents the array from being used in contexts that
4378 disallow assumed-size arrays, such as @samp{PRINT *,X}.
4379 In such cases, a diagnostic is generated and the source file is
4382 The construct affected by this option is used only in old code
4383 that pre-exists the widespread acceptance of adjustable and assumed-size
4384 arrays in the Fortran community.
4386 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
4387 treated if @samp{X} is listed as a dummy argument only
4388 @emph{after} the @code{DIMENSION} statement (presumably in
4389 an @code{ENTRY} statement).
4390 For example, @option{-fugly-assumed} has no effect on the
4391 following program unit:
4402 @node Ugly Complex Part Extraction
4403 @subsection Ugly Complex Part Extraction
4404 @cindex complex values
4406 @cindex imaginary part
4408 The @option{-fugly-complex} option enables
4409 use of the @code{REAL()} and @code{AIMAG()}
4410 intrinsics with arguments that are
4411 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
4413 With @option{-ff90} in effect, these intrinsics return
4414 the unconverted real and imaginary parts (respectively)
4417 With @option{-fno-f90} in effect, these intrinsics convert
4418 the real and imaginary parts to @code{REAL(KIND=1)}, and return
4419 the result of that conversion.
4421 Due to this ambiguity, the GNU Fortran language defines
4422 these constructs as invalid, except in the specific
4423 case where they are entirely and solely passed as an
4424 argument to an invocation of the @code{REAL()} intrinsic.
4432 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
4433 and @option{-fno-ugly-complex} is in effect, because the
4436 @command{g77} enforces this restriction, unless @option{-fugly-complex}
4437 is specified, in which case the appropriate interpretation is
4438 chosen and no diagnostic is issued.
4440 @xref{CMPAMBIG}, for information on how to cope with existing
4441 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
4442 with @code{COMPLEX(KIND=2)} arguments.
4444 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
4445 intrinsic, used to extract the real part of a complex expression
4447 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
4448 intrinsic, used to extract the imaginary part of a complex expression
4451 @node Ugly Null Arguments
4452 @subsection Ugly Null Arguments
4453 @cindex trailing comma
4454 @cindex comma, trailing
4455 @cindex characters, comma
4456 @cindex null arguments
4457 @cindex arguments, null
4459 The @option{-fugly-comma} option enables use of a single trailing comma
4460 to mean ``pass an extra trailing null argument''
4461 in a list of actual arguments to an external procedure,
4462 and use of an empty list of arguments to such a procedure
4463 to mean ``pass a single null argument''.
4465 @cindex omitting arguments
4466 @cindex arguments, omitting
4467 (Null arguments often are used in some procedure-calling
4468 schemes to indicate omitted arguments.)
4470 For example, @samp{CALL FOO(,)} means ``pass
4471 two null arguments'', rather than ``pass one null argument''.
4472 Also, @samp{CALL BAR()} means ``pass one null argument''.
4474 This construct is considered ``ugly'' because it does not
4475 provide an elegant way to pass a single null argument
4476 that is syntactically distinct from passing no arguments.
4477 That is, this construct changes the meaning of code that
4478 makes no use of the construct.
4480 So, with @option{-fugly-comma} in force, @samp{CALL FOO()}
4481 and @samp{I = JFUNC()} pass a single null argument, instead
4482 of passing no arguments as required by the Fortran 77 and
4485 @emph{Note:} Many systems gracefully allow the case
4486 where a procedure call passes one extra argument that the
4487 called procedure does not expect.
4489 So, in practice, there might be no difference in
4490 the behavior of a program that does @samp{CALL FOO()}
4491 or @samp{I = JFUNC()} and is compiled with @option{-fugly-comma}
4492 in force as compared to its behavior when compiled
4493 with the default, @option{-fno-ugly-comma}, in force,
4494 assuming @samp{FOO} and @samp{JFUNC} do not expect any
4495 arguments to be passed.
4497 @node Ugly Conversion of Initializers
4498 @subsection Ugly Conversion of Initializers
4500 The constructs disabled by @option{-fno-ugly-init} are:
4503 @cindex Hollerith constants
4504 @cindex constants, Hollerith
4506 Use of Hollerith and typeless constants in contexts where they set
4507 initial (compile-time) values for variables, arrays, and named
4508 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
4509 type-declaration statements specifying initial values.
4511 Here are some sample initializations that are disabled by the
4512 @option{-fno-ugly-init} option:
4515 PARAMETER (VAL='9A304FFE'X)
4516 REAL*8 STRING/8HOUTPUT00/
4520 @cindex character constants
4521 @cindex constants, character
4523 In the same contexts as above, use of character constants to initialize
4524 numeric items and vice versa (one constant per item).
4526 Here are more sample initializations that are disabled by the
4527 @option{-fno-ugly-init} option:
4532 PARAMETER (IA = 'A')
4533 PARAMETER (BELL = 7)
4537 Use of Hollerith and typeless constants on the right-hand side
4538 of assignment statements to numeric types, and in other
4539 contexts (such as passing arguments in invocations of
4540 intrinsic procedures and statement functions) that
4541 are treated as assignments to known types (the dummy
4542 arguments, in these cases).
4544 Here are sample statements that are disabled by the
4545 @option{-fno-ugly-init} option:
4549 PRINT *, IMAX0(2HAB, 2HBA)
4553 The above constructs, when used,
4554 can tend to result in non-portable code.
4555 But, they are widely used in existing Fortran code in ways
4556 that often are quite portable.
4557 Therefore, they are enabled by default.
4559 @node Ugly Integer Conversions
4560 @subsection Ugly Integer Conversions
4562 The constructs enabled via @option{-fugly-logint} are:
4566 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
4568 context (typically implies nonportable dependencies on how a
4569 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
4572 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
4576 The above constructs are disabled by default because use
4577 of them tends to lead to non-portable code.
4578 Even existing Fortran code that uses that often turns out
4579 to be non-portable, if not outright buggy.
4581 Some of this is due to differences among implementations as
4582 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
4583 @code{INTEGER} values---Fortran code that assumes a particular
4584 coding is likely to use one of the above constructs, and is
4585 also likely to not work correctly on implementations using
4586 different encodings.
4588 @xref{Equivalence Versus Equality}, for more information.
4590 @node Ugly Assigned Labels
4591 @subsection Ugly Assigned Labels
4592 @cindex ASSIGN statement
4593 @cindex statements, ASSIGN
4594 @cindex assigned labels
4597 The @option{-fugly-assign} option forces @command{g77} to use the
4598 same storage for assigned labels as it would for a normal
4599 assignment to the same variable.
4601 For example, consider the following code fragment:
4609 Normally, for portability and improved diagnostics, @command{g77}
4610 reserves distinct storage for a ``sibling'' of @samp{I}, used
4611 only for @code{ASSIGN} statements to that variable (along with
4612 the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
4613 statements that reference the variable).
4615 However, some code (that violates the ANSI FORTRAN 77 standard)
4616 attempts to copy assigned labels among variables involved with
4617 @code{ASSIGN} statements, as in:
4628 Such code doesn't work under @command{g77} unless @option{-fugly-assign}
4629 is specified on the command-line, ensuring that the value of @code{I}
4630 referenced in the second line is whatever value @command{g77} uses
4631 to designate statement label @samp{10}, so the value may be
4632 copied into the @samp{ISTATE} array, later retrieved into a
4633 variable of the appropriate type (@samp{J}), and used as the target of
4634 an assigned-@code{GOTO} statement.
4636 @emph{Note:} To avoid subtle program bugs,
4637 when @option{-fugly-assign} is specified,
4638 @command{g77} requires the type of variables
4639 specified in assigned-label contexts
4640 @emph{must} be the same type returned by @code{%LOC()}.
4641 On many systems, this type is effectively the same
4642 as @code{INTEGER(KIND=1)}, while, on others, it is
4643 effectively the same as @code{INTEGER(KIND=2)}.
4645 Do @emph{not} depend on @command{g77} actually writing valid pointers
4646 to these variables, however.
4647 While @command{g77} currently chooses that implementation, it might
4648 be changed in the future.
4650 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
4651 for implementation details on assigned-statement labels.
4654 @chapter The GNU Fortran Compiler
4656 The GNU Fortran compiler, @command{g77}, supports programs written
4657 in the GNU Fortran language and in some other dialects of Fortran.
4659 Some aspects of how @command{g77} works are universal regardless
4660 of dialect, and yet are not properly part of the GNU Fortran
4662 These are described below.
4664 @emph{Note: This portion of the documentation definitely needs a lot
4669 * Run-time Environment Limits::
4671 * Compiler Constants::
4672 * Compiler Intrinsics::
4675 @node Compiler Limits
4676 @section Compiler Limits
4677 @cindex limits, compiler
4678 @cindex compiler limits
4680 @command{g77}, as with GNU tools in general, imposes few arbitrary restrictions
4681 on lengths of identifiers, number of continuation lines, number of external
4682 symbols in a program, and so on.
4684 @cindex options, -Nl
4686 @cindex options, -Nx
4688 @cindex limits, continuation lines
4689 @cindex limits, lengths of names
4690 For example, some other Fortran compiler have an option
4691 (such as @option{-Nl@var{x}}) to increase the limit on the
4692 number of continuation lines.
4693 Also, some Fortran compilation systems have an option
4694 (such as @option{-Nx@var{x}}) to increase the limit on the
4695 number of external symbols.
4697 @command{g77}, @command{gcc}, and GNU @command{ld} (the GNU linker) have
4698 no equivalent options, since they do not impose arbitrary
4699 limits in these areas.
4701 @cindex rank, maximum
4702 @cindex maximum rank
4703 @cindex number of dimensions, maximum
4704 @cindex maximum number of dimensions
4705 @cindex limits, rank
4706 @cindex limits, array dimensions
4707 @command{g77} does currently limit the number of dimensions in an array
4708 to the same degree as do the Fortran standards---seven (7).
4709 This restriction might be lifted in a future version.
4711 @node Run-time Environment Limits
4712 @section Run-time Environment Limits
4713 @cindex limits, run-time library
4716 As a portable Fortran implementation,
4717 @command{g77} offers its users direct access to,
4718 and otherwise depends upon,
4719 the underlying facilities of the system
4720 used to build @command{g77},
4721 the system on which @command{g77} itself is used to compile programs,
4722 and the system on which the @command{g77}-compiled program is actually run.
4723 (For most users, the three systems are of the same
4724 type---combination of operating environment and hardware---often
4725 the same physical system.)
4727 The run-time environment for a particular system
4728 inevitably imposes some limits on a program's use
4729 of various system facilities.
4730 These limits vary from system to system.
4732 Even when such limits might be well beyond the
4733 possibility of being encountered on a particular system,
4734 the @command{g77} run-time environment
4735 has certain built-in limits,
4736 usually, but not always, stemming from intrinsics
4737 with inherently limited interfaces.
4739 Currently, the @command{g77} run-time environment
4740 does not generally offer a less-limiting environment
4741 by augmenting the underlying system's own environment.
4743 Therefore, code written in the GNU Fortran language,
4744 while syntactically and semantically portable,
4745 might nevertheless make non-portable assumptions
4746 about the run-time environment---assumptions that
4747 prove to be false for some particular environments.
4749 The GNU Fortran language,
4750 the @command{g77} compiler and run-time environment,
4751 and the @command{g77} documentation
4752 do not yet offer comprehensive portable work-arounds for such limits,
4753 though programmers should be able to
4754 find their own in specific instances.
4756 Not all of the limitations are described in this document.
4757 Some of the known limitations include:
4760 * Timer Wraparounds::
4761 * Year 2000 (Y2K) Problems::
4763 * Character-variable Length::
4764 * Year 10000 (Y10K) Problems::
4767 @node Timer Wraparounds
4768 @subsection Timer Wraparounds
4770 Intrinsics that return values computed from system timers,
4771 whether elapsed (wall-clock) timers,
4773 or other kinds of timers,
4774 are prone to experiencing wrap-around errors
4775 (or returning wrapped-around values from successive calls)
4776 due to insufficient ranges
4777 offered by the underlying system's timers.
4779 @cindex negative time
4782 Some of the symptoms of such behaviors include
4783 apparently negative time being computed for a duration,
4784 an extremely short amount of time being computed for a long duration,
4785 and an extremely long amount of time being computed for a short duration.
4787 See the following for intrinsics
4788 known to have potential problems in these areas
4789 on at least some systems:
4790 @ref{CPU_Time Intrinsic},
4791 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
4792 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
4793 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
4794 @ref{Secnds Intrinsic},
4795 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
4796 @ref{System_Clock Intrinsic},
4797 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
4798 @ref{Time8 Intrinsic}.
4800 @node Year 2000 (Y2K) Problems
4801 @subsection Year 2000 (Y2K) Problems
4802 @cindex Y2K compliance
4803 @cindex Year 2000 compliance
4805 While the @command{g77} compiler itself is believed to
4806 be Year-2000 (Y2K) compliant,
4807 some intrinsics are not,
4808 and, potentially, some underlying systems are not,
4809 perhaps rendering some Y2K-compliant intrinsics
4810 non-compliant when used on those particular systems.
4812 Fortran code that uses non-Y2K-compliant intrinsics
4814 is, itself, almost certainly not compliant,
4815 and should be modified to use Y2K-compliant intrinsics instead.
4817 Fortran code that uses no non-Y2K-compliant intrinsics,
4818 but which currently is running on a non-Y2K-compliant system,
4819 can be made more Y2K compliant by compiling and
4820 linking it for use on a new Y2K-compliant system,
4821 such as a new version of an old, non-Y2K-compliant, system.
4823 Currently, information on Y2K and related issues
4824 is being maintained at
4825 @uref{http://www.gnu.org/software/year2000-list.html}.
4827 See the following for intrinsics
4828 known to have potential problems in these areas
4829 on at least some systems:
4830 @ref{Date Intrinsic},
4831 @ref{IDate Intrinsic (VXT)}.
4834 @cindex date_y2kbuggy_0
4835 @cindex vxtidate_y2kbuggy_0
4836 @cindex G77_date_y2kbuggy_0
4837 @cindex G77_vxtidate_y2kbuggy_0
4838 The @code{libg2c} library
4839 shipped with any @command{g77} that warns
4840 about invocation of a non-Y2K-compliant intrinsic
4841 has renamed the @code{EXTERNAL} procedure names
4842 of those intrinsics.
4843 This is done so that
4844 the @code{libg2c} implementations of these intrinsics
4845 cannot be directly linked to
4846 as @code{EXTERNAL} names
4847 (which normally would avoid the non-Y2K-intrinsic warning).
4849 The renamed forms of the @code{EXTERNAL} names
4850 of these renamed procedures
4852 by appending the string @samp{_y2kbug}
4853 to the name of the procedure
4860 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
4861 CALL DATE_Y2KBUG (STR)
4862 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
4865 (Note that the @code{EXTERNAL} statement
4866 is not actually required,
4867 since the modified names are not recognized as intrinsics
4868 by the current version of @command{g77}.
4869 But it is shown in this specific case,
4870 for purposes of illustration.)
4872 The renaming of @code{EXTERNAL} procedure names of these intrinsics
4873 causes unresolved references at link time.
4874 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
4875 is normally compiled by @command{g77}
4876 as, in C, @samp{date_(&str, 20);}.
4877 This, in turn, links to the @code{date_} procedure
4878 in the @code{libE77} portion of @code{libg2c},
4879 which purposely calls a nonexistent procedure
4880 named @code{G77_date_y2kbuggy_0}.
4881 The resulting link-time error is designed, via this name,
4882 to encourage the programmer to look up the
4883 index entries to this portion of the @command{g77} documentation.
4885 Generally, we recommend that the @code{EXTERNAL} method
4886 of invoking procedures in @code{libg2c}
4888 When used, some of the correctness checking
4889 normally performed by @command{g77}
4892 In particular, it is probably better to use the
4893 @code{INTRINSIC} method of invoking
4894 non-Y2K-compliant procedures,
4895 so anyone compiling the code
4896 can quickly notice the potential Y2K problems
4897 (via the warnings printing by @command{g77})
4898 without having to even look at the code itself.
4900 If there are problems linking @code{libg2c}
4901 to code compiled by @command{g77}
4902 that involve the string @samp{y2kbug},
4903 and these are not explained above,
4904 that probably indicates
4905 that a version of @code{libg2c}
4906 older than @command{g77}
4908 or that the new library is being linked
4909 to code compiled by an older version of @command{g77}.
4911 That's because, as of the version that warns about
4912 non-Y2K-compliant intrinsic invocation,
4913 @command{g77} references the @code{libg2c} implementations
4915 using new names, containing the string @samp{y2kbug}.
4917 So, linking newly-compiled code
4918 (invoking one of the intrinsics in question)
4920 might yield an unresolved reference
4921 to @code{G77_date_y2kbug_0}.
4922 (The old library calls it @code{G77_date_0}.)
4924 Similarly, linking previously-compiled code
4926 might yield an unresolved reference
4927 to @code{G77_vxtidate_0}.
4928 (The new library calls it @code{G77_vxtidate_y2kbug_0}.)
4930 The proper fix for the above problems
4931 is to obtain the latest release of @command{g77}
4932 and related products
4933 (including @code{libg2c})
4934 and install them on all systems,
4935 then recompile, relink, and install
4937 all existing Fortran programs.
4939 (Normally, this sort of renaming is steadfastly avoided.
4940 In this case, however, it seems more important to highlight
4941 potential Y2K problems
4942 than to ease the transition
4943 of potentially non-Y2K-compliant code
4944 to new versions of @command{g77} and @code{libg2c}.)
4947 @subsection Array Size
4948 @cindex limits, array size
4951 Currently, @command{g77} uses the default @code{INTEGER} type
4953 which limits the sizes of single-dimension arrays
4954 on systems offering a larger address space
4955 than can be addressed by that type.
4956 (That @command{g77} puts all arrays in memory
4957 could be considered another limitation---it
4958 could use large temporary files---but that decision
4959 is left to the programmer as an implementation choice
4960 by most Fortran implementations.)
4962 @c ??? Investigate this, to offer a more clear statement
4963 @c than the following paragraphs do. -- burley 1999-02-17
4964 It is not yet clear whether this limitation
4965 never, sometimes, or always applies to the
4966 sizes of multiple-dimension arrays as a whole.
4968 For example, on a system with 64-bit addresses
4969 and 32-bit default @code{INTEGER},
4970 an array with a size greater than can be addressed
4972 can be declared using multiple dimensions.
4973 Such an array is therefore larger
4974 than a single-dimension array can be,
4977 @cindex limits, multi-dimension arrays
4978 @cindex multi-dimension arrays
4979 @cindex arrays, dimensioning
4980 Whether large multiple-dimension arrays are reliably supported
4981 depends mostly on the @command{gcc} back end (code generator)
4982 used by @command{g77}, and has not yet been fully investigated.
4984 @node Character-variable Length
4985 @subsection Character-variable Length
4986 @cindex limits, on character-variable length
4987 @cindex character-variable length
4989 Currently, @command{g77} uses the default @code{INTEGER} type
4990 for the lengths of @code{CHARACTER} variables
4993 This means that, for example,
4994 a system with a 64-bit address space
4995 and a 32-bit default @code{INTEGER} type
4996 does not, under @command{g77},
4997 support a @code{CHARACTER*@var{n}} declaration
4998 where @var{n} is greater than 2147483647.
5000 @node Year 10000 (Y10K) Problems
5001 @subsection Year 10000 (Y10K) Problems
5002 @cindex Y10K compliance
5003 @cindex Year 10000 compliance
5005 Most intrinsics returning, or computing values based on,
5006 date information are prone to Year-10000 (Y10K) problems,
5007 due to supporting only 4 digits for the year.
5009 See the following for examples:
5010 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
5011 @ref{IDate Intrinsic (UNIX)},
5012 @ref{Time Intrinsic (VXT)},
5013 @ref{Date_and_Time Intrinsic}.
5015 @node Compiler Types
5016 @section Compiler Types
5017 @cindex types, of data
5020 Fortran implementations have a fair amount of freedom given them by the
5021 standard as far as how much storage space is used and how much precision
5022 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
5023 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
5024 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
5025 Further, many compilers offer so-called @samp{*@var{n}} notation, but
5026 the interpretation of @var{n} varies across compilers and target architectures.
5028 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
5029 and @code{REAL(KIND=1)}
5030 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
5031 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
5032 Further, it requires that @code{COMPLEX(KIND=1)}
5033 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
5034 storage-associated (such as via @code{EQUIVALENCE})
5035 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
5036 corresponds to the real element and @samp{R(2)} to the imaginary
5037 element of the @code{COMPLEX(KIND=1)} variable.
5039 (Few requirements as to precision or ranges of any of these are
5040 placed on the implementation, nor is the relationship of storage sizes of
5041 these types to the @code{CHARACTER} type specified, by the standard.)
5043 @command{g77} follows the above requirements, warning when compiling
5044 a program requires placement of items in memory that contradict the
5045 requirements of the target architecture.
5046 (For example, a program can require placement of a @code{REAL(KIND=2)}
5047 on a boundary that is not an even multiple of its size, but still an
5048 even multiple of the size of a @code{REAL(KIND=1)} variable.
5049 On some target architectures, using the canonical
5050 mapping of Fortran types to underlying architectural types, such
5051 placement is prohibited by the machine definition or
5052 the Application Binary Interface (ABI) in force for
5053 the configuration defined for building @command{gcc} and @command{g77}.
5054 @command{g77} warns about such
5055 situations when it encounters them.)
5057 @command{g77} follows consistent rules for configuring the mapping between Fortran
5058 types, including the @samp{*@var{n}} notation, and the underlying architectural
5059 types as accessed by a similarly-configured applicable version of the
5060 @command{gcc} compiler.
5061 These rules offer a widely portable, consistent Fortran/C
5062 environment, although they might well conflict with the expectations of
5063 users of Fortran compilers designed and written for particular
5066 These rules are based on the configuration that is in force for the
5067 version of @command{gcc} built in the same release as @command{g77} (and
5068 which was therefore used to build both the @command{g77} compiler
5069 components and the @code{libg2c} run-time library):
5072 @cindex REAL(KIND=1) type
5073 @cindex types, REAL(KIND=1)
5075 Same as @code{float} type.
5077 @cindex REAL(KIND=2) type
5078 @cindex types, REAL(KIND=2)
5080 Same as whatever floating-point type that is twice the size
5081 of a @code{float}---usually, this is a @code{double}.
5083 @cindex INTEGER(KIND=1) type
5084 @cindex types, INTEGER(KIND=1)
5085 @item INTEGER(KIND=1)
5086 Same as an integral type that is occupies the same amount
5087 of memory storage as @code{float}---usually, this is either
5088 an @code{int} or a @code{long int}.
5090 @cindex LOGICAL(KIND=1) type
5091 @cindex types, LOGICAL(KIND=1)
5092 @item LOGICAL(KIND=1)
5093 Same @command{gcc} type as @code{INTEGER(KIND=1)}.
5095 @cindex INTEGER(KIND=2) type
5096 @cindex types, INTEGER(KIND=2)
5097 @item INTEGER(KIND=2)
5098 Twice the size, and usually nearly twice the range,
5099 as @code{INTEGER(KIND=1)}---usually, this is either
5100 a @code{long int} or a @code{long long int}.
5102 @cindex LOGICAL(KIND=2) type
5103 @cindex types, LOGICAL(KIND=2)
5104 @item LOGICAL(KIND=2)
5105 Same @command{gcc} type as @code{INTEGER(KIND=2)}.
5107 @cindex INTEGER(KIND=3) type
5108 @cindex types, INTEGER(KIND=3)
5109 @item INTEGER(KIND=3)
5110 Same @command{gcc} type as signed @code{char}.
5112 @cindex LOGICAL(KIND=3) type
5113 @cindex types, LOGICAL(KIND=3)
5114 @item LOGICAL(KIND=3)
5115 Same @command{gcc} type as @code{INTEGER(KIND=3)}.
5117 @cindex INTEGER(KIND=6) type
5118 @cindex types, INTEGER(KIND=6)
5119 @item INTEGER(KIND=6)
5120 Twice the size, and usually nearly twice the range,
5121 as @code{INTEGER(KIND=3)}---usually, this is
5124 @cindex LOGICAL(KIND=6) type
5125 @cindex types, LOGICAL(KIND=6)
5126 @item LOGICAL(KIND=6)
5127 Same @command{gcc} type as @code{INTEGER(KIND=6)}.
5129 @cindex COMPLEX(KIND=1) type
5130 @cindex types, COMPLEX(KIND=1)
5131 @item COMPLEX(KIND=1)
5132 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
5133 one for the imaginary part).
5135 @cindex COMPLEX(KIND=2) type
5136 @cindex types, COMPLEX(KIND=2)
5137 @item COMPLEX(KIND=2)
5138 Two @code{REAL(KIND=2)} scalars.
5140 @cindex *@var{n} notation
5141 @item @var{numeric-type}*@var{n}
5142 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
5143 Same as whatever @command{gcc} type occupies @var{n} times the storage
5144 space of a @command{gcc} @code{char} item.
5146 @cindex DOUBLE PRECISION type
5147 @cindex types, DOUBLE PRECISION
5148 @item DOUBLE PRECISION
5149 Same as @code{REAL(KIND=2)}.
5151 @cindex DOUBLE COMPLEX type
5152 @cindex types, DOUBLE COMPLEX
5153 @item DOUBLE COMPLEX
5154 Same as @code{COMPLEX(KIND=2)}.
5157 Note that the above are proposed correspondences and might change
5158 in future versions of @command{g77}---avoid writing code depending
5161 Other types supported by @command{g77}
5162 are derived from gcc types such as @code{char}, @code{short},
5163 @code{int}, @code{long int}, @code{long long int}, @code{long double},
5165 That is, whatever types @command{gcc} already supports, @command{g77} supports
5166 now or probably will support in a future version.
5167 The rules for the @samp{@var{numeric-type}*@var{n}} notation
5168 apply to these types,
5169 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
5170 assigned in a way that encourages clarity, consistency, and portability.
5172 @node Compiler Constants
5173 @section Compiler Constants
5175 @cindex types, constants
5177 @command{g77} strictly assigns types to @emph{all} constants not
5178 documented as ``typeless'' (typeless constants including @samp{'1'Z},
5180 Many other Fortran compilers attempt to assign types to typed constants
5181 based on their context.
5182 This results in hard-to-find bugs, nonportable
5183 code, and is not in the spirit (though it strictly follows the letter)
5184 of the 77 and 90 standards.
5186 @command{g77} might offer, in a future release, explicit constructs by
5187 which a wider variety of typeless constants may be specified, and/or
5188 user-requested warnings indicating places where @command{g77} might differ
5189 from how other compilers assign types to constants.
5191 @xref{Context-Sensitive Constants}, for more information on this issue.
5193 @node Compiler Intrinsics
5194 @section Compiler Intrinsics
5196 @command{g77} offers an ever-widening set of intrinsics.
5197 Currently these all are procedures (functions and subroutines).
5199 Some of these intrinsics are unimplemented, but their names reserved
5200 to reduce future problems with existing code as they are implemented.
5201 Others are implemented as part of the GNU Fortran language, while
5202 yet others are provided for compatibility with other dialects of
5203 Fortran but are not part of the GNU Fortran language.
5205 To manage these distinctions, @command{g77} provides intrinsic @emph{groups},
5206 a facility that is simply an extension of the intrinsic groups provided
5207 by the GNU Fortran language.
5210 * Intrinsic Groups:: How intrinsics are grouped for easy management.
5211 * Other Intrinsics:: Intrinsics other than those in the GNU
5215 @node Intrinsic Groups
5216 @subsection Intrinsic Groups
5217 @cindex groups of intrinsics
5218 @cindex intrinsics, groups
5220 A given specific intrinsic belongs in one or more groups.
5221 Each group is deleted, disabled, hidden, or enabled
5222 by default or a command-line option.
5223 The meaning of each term follows.
5226 @cindex deleted intrinsics
5227 @cindex intrinsics, deleted
5229 No intrinsics are recognized as belonging to that group.
5231 @cindex disabled intrinsics
5232 @cindex intrinsics, disabled
5234 Intrinsics are recognized as belonging to the group, but
5235 references to them (other than via the @code{INTRINSIC} statement)
5236 are disallowed through that group.
5238 @cindex hidden intrinsics
5239 @cindex intrinsics, hidden
5241 Intrinsics in that group are recognized and enabled (if implemented)
5242 @emph{only} if the first mention of the actual name of an intrinsic
5243 in a program unit is in an @code{INTRINSIC} statement.
5245 @cindex enabled intrinsics
5246 @cindex intrinsics, enabled
5248 Intrinsics in that group are recognized and enabled (if implemented).
5251 The distinction between deleting and disabling a group is illustrated
5252 by the following example.
5253 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
5254 If group @samp{FGR} is deleted, the following program unit will
5255 successfully compile, because @samp{FOO()} will be seen as a
5256 reference to an external function named @samp{FOO}:
5264 If group @samp{FGR} is disabled, compiling the above program will produce
5265 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
5266 or, if properly invoked, it is not enabled.
5267 To change the above program so it references an external function @samp{FOO}
5268 instead of the disabled @samp{FOO} intrinsic,
5269 add the following line to the top:
5276 So, deleting a group tells @command{g77} to pretend as though the intrinsics in
5277 that group do not exist at all, whereas disabling it tells @command{g77} to
5278 recognize them as (disabled) intrinsics in intrinsic-like contexts.
5280 Hiding a group is like enabling it, but the intrinsic must be first
5281 named in an @code{INTRINSIC} statement to be considered a reference to the
5282 intrinsic rather than to an external procedure.
5283 This might be the ``safest'' way to treat a new group of intrinsics
5285 code, because it allows the old code to be generally written as if
5286 those new intrinsics never existed, but to be changed to use them
5287 by inserting @code{INTRINSIC} statements in the appropriate places.
5288 However, it should be the goal of development to use @code{EXTERNAL}
5289 for all names of external procedures that might be intrinsic names.
5291 If an intrinsic is in more than one group, it is enabled if any of its
5292 containing groups are enabled; if not so enabled, it is hidden if
5293 any of its containing groups are hidden; if not so hidden, it is disabled
5294 if any of its containing groups are disabled; if not so disabled, it is
5296 This extra complication is necessary because some intrinsics,
5297 such as @code{IBITS}, belong to more than one group, and hence should be
5298 enabled if any of the groups to which they belong are enabled, and so
5303 @cindex intrinsics, groups of
5304 @cindex groups of intrinsics
5306 @cindex @code{badu77} intrinsics group
5308 UNIX intrinsics having inappropriate forms (usually functions that
5309 have intended side effects).
5311 @cindex @code{gnu} intrinsics group
5313 Intrinsics the GNU Fortran language supports that are extensions to
5314 the Fortran standards (77 and 90).
5316 @cindex @command{f2c} intrinsics group
5318 Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}.
5320 @cindex @code{f90} intrinsics group
5322 Fortran 90 intrinsics.
5324 @cindex @code{mil} intrinsics group
5326 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
5328 @cindex @code{mil} intrinsics group
5330 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
5332 @cindex @code{mil} intrinsics group
5334 VAX/VMS FORTRAN (current as of v4) intrinsics.
5337 @node Other Intrinsics
5338 @subsection Other Intrinsics
5339 @cindex intrinsics, others
5340 @cindex other intrinsics
5342 @command{g77} supports intrinsics other than those in the GNU Fortran
5344 This set of intrinsics is described below.
5347 (Note that the empty lines appearing in the menu below
5348 are not intentional---they result from a bug in the
5349 @code{makeinfo} program.)
5352 @c The actual documentation for intrinsics comes from
5353 @c intdoc.texi, which in turn is automatically generated
5354 @c from the internal g77 tables in intrin.def _and_ the
5355 @c largely hand-written text in intdoc.h. So, if you want
5356 @c to change or add to existing documentation on intrinsics,
5357 @c you probably want to edit intdoc.h.
5369 @include intdoc.texi
5371 @node Other Compilers
5372 @chapter Other Compilers
5374 An individual Fortran source file can be compiled to
5375 an object (@file{*.o}) file instead of to the final
5377 This allows several portions of a program to be compiled
5378 at different times and linked together whenever a new
5379 version of the program is needed.
5380 However, it introduces the issue of @dfn{object compatibility}
5381 across the various object files (and libraries, or @file{*.a}
5382 files) that are linked together to produce any particular
5385 Object compatibility is an issue when combining, in one
5386 program, Fortran code compiled by more than one compiler
5387 (or more than one configuration of a compiler).
5389 disagree on how to transform the names of procedures, there
5390 will normally be errors when linking such programs.
5391 Worse, if the compilers agree on naming, but disagree on issues
5392 like how to pass parameters, return arguments, and lay out
5393 @code{COMMON} areas, the earliest detected errors might be the
5394 incorrect results produced by the program (and that assumes
5395 these errors are detected, which is not always the case).
5397 Normally, @command{g77} generates code that is
5398 object-compatible with code generated by a version of
5399 @command{f2c} configured (with, for example, @file{f2c.h} definitions)
5400 to be generally compatible with @command{g77} as built by @command{gcc}.
5401 (Normally, @command{f2c} will, by default, conform to the appropriate
5402 configuration, but it is possible that older or perhaps even newer
5403 versions of @command{f2c}, or versions having certain configuration changes
5404 to @command{f2c} internals, will produce object files that are
5405 incompatible with @command{g77}.)
5407 For example, a Fortran string subroutine
5408 argument will become two arguments on the C side: a @code{char *}
5409 and an @code{int} length.
5411 Much of this compatibility results from the fact that
5412 @command{g77} uses the same run-time library,
5413 @code{libf2c}, used by @command{f2c},
5414 though @command{g77} gives its version the name @code{libg2c}
5415 so as to avoid conflicts when linking,
5416 installing them in the same directories,
5419 Other compilers might or might not generate code that
5420 is object-compatible with @code{libg2c} and current @command{g77},
5421 and some might offer such compatibility only when explicitly
5422 selected via a command-line option to the compiler.
5424 @emph{Note: This portion of the documentation definitely needs a lot
5428 * Dropping f2c Compatibility:: When speed is more important.
5429 * Compilers Other Than f2c:: Interoperation with code from other compilers.
5432 @node Dropping f2c Compatibility
5433 @section Dropping @command{f2c} Compatibility
5435 Specifying @option{-fno-f2c} allows @command{g77} to generate, in
5436 some cases, faster code, by not needing to allow to the possibility
5437 of linking with code compiled by @command{f2c}.
5439 For example, this affects how @code{REAL(KIND=1)},
5440 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
5441 With @option{-fno-f2c}, they are
5442 compiled as returning the appropriate @command{gcc} type
5443 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
5444 in many configurations).
5446 With @option{-ff2c} in force, they
5447 are compiled differently (with perhaps slower run-time performance)
5448 to accommodate the restrictions inherent in @command{f2c}'s use of K&R
5449 C as an intermediate language---@code{REAL(KIND=1)} functions
5450 return C's @code{double} type, while @code{COMPLEX} functions return
5451 @code{void} and use an extra argument pointing to a place for the functions to
5452 return their values.
5454 It is possible that, in some cases, leaving @option{-ff2c} in force
5455 might produce faster code than using @option{-fno-f2c}.
5456 Feel free to experiment, but remember to experiment with changing the way
5457 @emph{entire programs and their Fortran libraries are compiled} at
5458 a time, since this sort of experimentation affects the interface
5459 of code generated for a Fortran source file---that is, it affects
5460 object compatibility.
5462 Note that @command{f2c} compatibility is a fairly static target to achieve,
5463 though not necessarily perfectly so, since, like @command{g77}, it is
5464 still being improved.
5465 However, specifying @option{-fno-f2c} causes @command{g77}
5466 to generate code that will probably be incompatible with code
5467 generated by future versions of @command{g77} when the same option
5469 You should make sure you are always able to recompile complete
5470 programs from source code when upgrading to new versions of @command{g77}
5471 or @command{f2c}, especially when using options such as @option{-fno-f2c}.
5473 Therefore, if you are using @command{g77} to compile libraries and other
5474 object files for possible future use and you don't want to require
5475 recompilation for future use with subsequent versions of @command{g77},
5476 you might want to stick with @command{f2c} compatibility for now, and
5477 carefully watch for any announcements about changes to the
5478 @command{f2c}/@code{libf2c} interface that might affect existing programs
5479 (thus requiring recompilation).
5481 It is probable that a future version of @command{g77} will not,
5482 by default, generate object files compatible with @command{f2c},
5483 and that version probably would no longer use @code{libf2c}.
5484 If you expect to depend on this compatibility in the
5485 long term, use the options @samp{-ff2c -ff2c-library} when compiling
5486 all of the applicable code.
5487 This should cause future versions of @command{g77} either to produce
5488 compatible code (at the expense of the availability of some features and
5489 performance), or at the very least, to produce diagnostics.
5491 (The library @command{g77} produces will no longer be named @file{libg2c}
5492 when it is no longer generally compatible with @file{libf2c}.
5493 It will likely be referred to, and, if installed as a distinct
5494 library, named @code{libg77}, or some other as-yet-unused name.)
5496 @node Compilers Other Than f2c
5497 @section Compilers Other Than @command{f2c}
5499 On systems with Fortran compilers other than @command{f2c} and @command{g77},
5500 code compiled by @command{g77} is not expected to work
5501 well with code compiled by the native compiler.
5502 (This is true for @command{f2c}-compiled objects as well.)
5503 Libraries compiled with the native compiler probably will have
5504 to be recompiled with @command{g77} to be used with @command{g77}-compiled code.
5506 Reasons for such incompatibilities include:
5510 There might be differences in the way names of Fortran procedures
5511 are translated for use in the system's object-file format.
5512 For example, the statement @samp{CALL FOO} might be compiled
5513 by @command{g77} to call a procedure the linker @command{ld} sees
5514 given the name @samp{_foo_}, while the apparently corresponding
5515 statement @samp{SUBROUTINE FOO} might be compiled by the
5516 native compiler to define the linker-visible name @samp{_foo},
5517 or @samp{_FOO_}, and so on.
5520 There might be subtle type mismatches which cause subroutine arguments
5521 and function return values to get corrupted.
5523 This is why simply getting @command{g77} to
5524 transform procedure names the same way a native
5525 compiler does is not usually a good idea---unless
5526 some effort has been made to ensure that, aside
5527 from the way the two compilers transform procedure
5528 names, everything else about the way they generate
5529 code for procedure interfaces is identical.
5533 use libraries of private I/O routines which will not be available
5534 at link time unless you have the native compiler---and you would
5535 have to explicitly ask for them.
5537 For example, on the Sun you
5538 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
5542 @node Other Languages
5543 @chapter Other Languages
5545 @emph{Note: This portion of the documentation definitely needs a lot
5549 * Interoperating with C and C++::
5552 @node Interoperating with C and C++
5553 @section Tools and advice for interoperating with C and C++
5555 @cindex C, linking with
5556 @cindex C++, linking with
5557 @cindex linking with C
5558 The following discussion assumes that you are running @command{g77} in @command{f2c}
5559 compatibility mode, i.e.@: not using @option{-fno-f2c}.
5561 advice about quick and simple techniques for linking Fortran and C (or
5562 C++), the most common requirement.
5563 For the full story consult the
5564 description of code generation.
5565 @xref{Debugging and Interfacing}.
5567 When linking Fortran and C, it's usually best to use @command{g77} to do
5568 the linking so that the correct libraries are included (including the
5570 If you're linking with C++ you will want to add
5571 @option{-lstdc++}, @option{-lg++} or whatever.
5572 If you need to use another
5573 driver program (or @command{ld} directly),
5574 you can find out what linkage
5575 options @command{g77} passes by running @samp{g77 -v}.
5578 * C Interfacing Tools::
5579 * C Access to Type Information::
5580 * f2c Skeletons and Prototypes::
5581 * C++ Considerations::
5585 @node C Interfacing Tools
5586 @subsection C Interfacing Tools
5590 Even if you don't actually use it as a compiler, @command{f2c} from
5591 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
5592 interfacing (linking) Fortran and C@.
5593 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}.
5595 To use @command{f2c} for this purpose you only need retrieve and
5596 build the @file{src} directory from the distribution, consult the
5597 @file{README} instructions there for machine-specifics, and install the
5598 @command{f2c} program on your path.
5600 Something else that might be useful is @samp{cfortran.h} from
5601 @uref{ftp://zebra.desy.de/cfortran}.
5602 This is a fairly general tool which
5603 can be used to generate interfaces for calling in both directions
5604 between Fortran and C@.
5605 It can be used in @command{f2c} mode with
5606 @command{g77}---consult its documentation for details.
5608 @node C Access to Type Information
5609 @subsection Accessing Type Information in C
5611 @cindex types, Fortran/C
5612 Generally, C code written to link with
5613 @command{g77} code---calling and/or being
5614 called from Fortran---should @samp{#include <g2c.h>} to define the C
5615 versions of the Fortran types.
5616 Don't assume Fortran @code{INTEGER} types
5617 correspond to C @code{int}s, for instance; instead, declare them as
5618 @code{integer}, a type defined by @file{g2c.h}.
5619 @file{g2c.h} is installed where @command{gcc} will find it by
5620 default, assuming you use a copy of @command{gcc} compatible with
5621 @command{g77}, probably built at the same time as @command{g77}.
5623 @node f2c Skeletons and Prototypes
5624 @subsection Generating Skeletons and Prototypes with @command{f2c}
5627 @cindex -fno-second-underscore
5628 A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to
5629 interface with an existing library---is to write a file (named, for
5630 example, @file{fred.f}) of dummy Fortran
5631 skeletons comprising just the declaration of the routine(s) and dummy
5632 arguments plus @code{END} statements.
5633 Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c}
5634 into which you can edit
5635 useful code, confident the calling sequence is correct, at least.
5636 (There are some errors otherwise commonly made in generating C
5637 interfaces with @command{f2c} conventions,
5638 such as not using @code{doublereal}
5639 as the return type of a @code{REAL} @code{FUNCTION}.)
5642 @command{f2c} also can help with calling Fortran from C, using its
5643 @option{-P} option to generate C prototypes appropriate for calling the
5644 Fortran.@footnote{The files generated like this can also be used for
5645 inter-unit consistency checking of dummy and actual arguments, although
5646 the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
5647 or @uref{ftp://ftp.dsm.fordham.edu} is
5648 probably better for this purpose.}
5649 If the Fortran code containing any
5650 routines to be called from C is in file @file{joe.f}, use the command
5651 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
5652 prototype information.
5653 @code{#include} this in the C which has to call
5654 the Fortran routines to make sure you get it right.
5656 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
5657 between the way Fortran (including compilers like @command{g77}) and
5660 @node C++ Considerations
5661 @subsection C++ Considerations
5664 @command{f2c} can be used to generate suitable code for compilation with a
5665 C++ system using the @option{-C++} option.
5666 The important thing about linking @command{g77}-compiled
5667 code with C++ is that the prototypes for the @command{g77}
5668 routines must specify C linkage to avoid name mangling.
5669 So, use an @samp{extern "C"} declaration.
5670 @command{f2c}'s @option{-C++} option will take care
5671 of this when generating skeletons or prototype files as above, and also
5672 avoid clashes with C++ reserved words in addition to those in C@.
5675 @subsection Startup Code
5677 @cindex startup code
5678 @cindex run-time, initialization
5679 @cindex initialization, run-time
5680 Unlike with some runtime systems,
5681 it shouldn't be necessary
5682 (unless there are bugs)
5683 to use a Fortran main program unit to ensure the
5684 runtime---specifically the I/O system---is initialized.
5686 However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC},
5687 either the @code{main} routine from the @file{libg2c} library must be used,
5688 or the @code{f_setarg} routine
5689 (new as of @command{egcs} version 1.1 and @command{g77} version 0.5.23)
5690 must be called with the appropriate @code{argc} and @code{argv} arguments
5691 prior to the program calling @code{GETARG} or @code{IARGC}.
5693 To provide more flexibility for mixed-language programming
5694 involving @command{g77} while allowing for shared libraries,
5695 as of @command{egcs} version 1.1 and @command{g77} version 0.5.23,
5696 @command{g77}'s @code{main} routine in @code{libg2c}
5697 does the following, in order:
5701 Calls @code{f_setarg}
5702 with the incoming @code{argc} and @code{argv} arguments,
5703 in the same order as for @code{main} itself.
5705 This sets up the command-line environment
5706 for @code{GETARG} and @code{IARGC}.
5709 Calls @code{f_setsig} (with no arguments).
5711 This sets up the signaling and exception environment.
5714 Calls @code{f_init} (with no arguments).
5716 This initializes the I/O environment,
5717 though that should not be necessary,
5718 as all I/O functions in @code{libf2c}
5719 are believed to call @code{f_init} automatically,
5722 (A future version of @command{g77} might skip this explicit step,
5723 to speed up normal exit of a program.)
5726 Arranges for @code{f_exit} to be called (with no arguments)
5727 when the program exits.
5729 This ensures that the I/O environment is properly shut down
5730 before the program exits normally.
5731 Otherwise, output buffers might not be fully flushed,
5732 scratch files might not be deleted, and so on.
5734 The simple way @code{main} does this is
5735 to call @code{f_exit} itself after calling
5736 @code{MAIN__} (in the next step).
5738 However, this does not catch the cases where the program
5739 might call @code{exit} directly,
5740 instead of using the @code{EXIT} intrinsic
5741 (implemented as @code{exit_} in @code{libf2c}).
5743 So, @code{main} attempts to use
5744 the operating environment's @code{onexit} or @code{atexit}
5745 facility, if available,
5746 to cause @code{f_exit} to be called automatically
5747 upon any invocation of @code{exit}.
5750 Calls @code{MAIN__} (with no arguments).
5752 This starts executing the Fortran main program unit for
5754 (Both @command{g77} and @command{f2c} currently compile a main
5755 program unit so that its global name is @code{MAIN__}.)
5758 If no @code{onexit} or @code{atexit} is provided by the system,
5759 calls @code{f_exit}.
5762 Calls @code{exit} with a zero argument,
5763 to signal a successful program termination.
5766 Returns a zero value to the caller,
5767 to signal a successful program termination,
5768 in case @code{exit} doesn't exit on the system.
5771 All of the above names are C @code{extern} names,
5774 When using the @code{main} procedure provided by @command{g77}
5775 without a Fortran main program unit,
5776 you need to provide @code{MAIN__}
5777 as the entry point for your C code.
5778 (Make sure you link the object file that defines that
5779 entry point with the rest of your program.)
5781 To provide your own @code{main} procedure
5782 in place of @command{g77}'s,
5783 make sure you specify the object file defining that procedure
5784 @emph{before} @option{-lg2c} on the @command{g77} command line.
5785 Since the @option{-lg2c} option is implicitly provided,
5786 this is usually straightforward.
5787 (Use the @option{--verbose} option to see how and where
5788 @command{g77} implicitly adds @option{-lg2c} in a command line
5789 that will link the program.
5790 Feel free to specify @option{-lg2c} explicitly,
5793 However, when providing your own @code{main},
5794 make sure you perform the appropriate tasks in the
5796 For example, if your @code{main} does not call @code{f_setarg},
5797 make sure the rest of your application does not call
5798 @code{GETARG} or @code{IARGC}.
5800 And, if your @code{main} fails to ensure that @code{f_exit}
5801 is called upon program exit,
5802 some files might end up incompletely written,
5803 some scratch files might be left lying around,
5804 and some existing files being written might be left
5805 with old data not properly truncated at the end.
5807 Note that, generally, the @command{g77} operating environment
5808 does not depend on a procedure named @code{MAIN__} actually
5809 being called prior to any other @command{g77}-compiled code.
5810 That is, @code{MAIN__} does not, itself,
5811 set up any important operating-environment characteristics
5812 upon which other code might depend.
5813 This might change in future versions of @command{g77},
5814 with appropriate notification in the release notes.
5816 For more information, consult the source code for the above routines.
5817 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
5818 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
5820 Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77}
5821 uses to open-code (inline) references to @code{IARGC}.
5823 @node Debugging and Interfacing
5824 @chapter Debugging and Interfacing
5827 @cindex calling C routines
5828 @cindex C routines calling Fortran
5829 @cindex f2c compatibility
5831 GNU Fortran currently generates code that is object-compatible with
5832 the @command{f2c} converter.
5833 Also, it avoids limitations in the current GBE, such as the
5834 inability to generate a procedure with
5835 multiple entry points, by generating code that is structured
5836 differently (in terms of procedure names, scopes, arguments, and
5837 so on) than might be expected.
5839 As a result, writing code in other languages that calls on, is
5840 called by, or shares in-memory data with @command{g77}-compiled code generally
5841 requires some understanding of the way @command{g77} compiles code for
5844 Similarly, using a debugger to debug @command{g77}-compiled
5845 code, even if that debugger supports native Fortran debugging, generally
5846 requires this sort of information.
5848 This section describes some of the basic information on how
5849 @command{g77} compiles code for constructs involving interfaces to other
5850 languages and to debuggers.
5852 @emph{Caution:} Much or all of this information pertains to only the current
5853 release of @command{g77}, sometimes even to using certain compiler options
5854 with @command{g77} (such as @option{-fno-f2c}).
5855 Do not write code that depends on this
5856 information without clearly marking said code as nonportable and
5857 subject to review for every new release of @command{g77}.
5859 is provided primarily to make debugging of code generated by this
5860 particular release of @command{g77} easier for the user, and partly to make
5861 writing (generally nonportable) interface code easier.
5863 activities require tracking changes in new version of @command{g77} as they
5864 are installed, because new versions can change the behaviors
5865 described in this section.
5868 * Main Program Unit:: How @command{g77} compiles a main program unit.
5869 * Procedures:: How @command{g77} constructs parameter lists
5871 * Functions:: Functions returning floating-point or character data.
5872 * Names:: Naming of user-defined variables, procedures, etc.
5873 * Common Blocks:: Accessing common variables while debugging.
5874 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
5875 * Complex Variables:: How @command{g77} performs complex arithmetic.
5876 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
5877 * Adjustable Arrays:: Special consideration for adjustable arrays.
5878 * Alternate Entry Points:: How @command{g77} implements alternate @code{ENTRY}.
5879 * Alternate Returns:: How @command{g77} handles alternate returns.
5880 * Assigned Statement Labels:: How @command{g77} handles @code{ASSIGN}.
5881 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
5884 @node Main Program Unit
5885 @section Main Program Unit (PROGRAM)
5886 @cindex PROGRAM statement
5887 @cindex statements, PROGRAM
5889 When @command{g77} compiles a main program unit, it gives it the public
5890 procedure name @code{MAIN__}.
5891 The @code{libg2c} library has the actual @code{main()} procedure
5892 as is typical of C-based environments, and
5893 it is this procedure that performs some initial start-up
5894 activity and then calls @code{MAIN__}.
5896 Generally, @command{g77} and @code{libg2c} are designed so that you need not
5897 include a main program unit written in Fortran in your program---it
5898 can be written in C or some other language.
5899 Especially for I/O handling, this is the case, although @command{g77} version 0.5.16
5900 includes a bug fix for @code{libg2c} that solved a problem with using the
5901 @code{OPEN} statement as the first Fortran I/O activity in a program
5902 without a Fortran main program unit.
5904 However, if you don't intend to use @command{g77} (or @command{f2c}) to compile
5905 your main program unit---that is, if you intend to compile a @code{main()}
5906 procedure using some other language---you should carefully
5907 examine the code for @code{main()} in @code{libg2c}, found in the source
5908 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
5909 might need to be done by your @code{main()} in order to provide the
5910 Fortran environment your Fortran code is expecting.
5912 @cindex @code{IArgC} intrinsic
5913 @cindex intrinsics, @code{IArgC}
5914 @cindex @code{GetArg} intrinsic
5915 @cindex intrinsics, @code{GetArg}
5916 For example, @code{libg2c}'s @code{main()} sets up the information used by
5917 the @code{IARGC} and @code{GETARG} intrinsics.
5918 Bypassing @code{libg2c}'s @code{main()}
5919 without providing a substitute for this activity would mean
5920 that invoking @code{IARGC} and @code{GETARG} would produce undefined
5924 @cindex main program unit, debugging
5928 When debugging, one implication of the fact that @code{main()}, which
5929 is the place where the debugged program ``starts'' from the
5930 debugger's point of view, is in @code{libg2c} is that you won't be
5931 starting your Fortran program at a point you recognize as your
5934 The standard way to get around this problem is to set a break
5935 point (a one-time, or temporary, break point will do) at
5936 the entrance to @code{MAIN__}, and then run the program.
5937 A convenient way to do so is to add the @command{gdb} command
5944 to the file @file{.gdbinit} in the directory in which you're debugging
5945 (using @command{gdb}).
5947 After doing this, the debugger will see the current execution
5948 point of the program as at the beginning of the main program
5949 unit of your program.
5951 Of course, if you really want to set a break point at some
5952 other place in your program and just start the program
5953 running, without first breaking at @code{MAIN__},
5954 that should work fine.
5957 @section Procedures (SUBROUTINE and FUNCTION)
5959 @cindex SUBROUTINE statement
5960 @cindex statements, SUBROUTINE
5961 @cindex FUNCTION statement
5962 @cindex statements, FUNCTION
5963 @cindex signature of procedures
5965 Currently, @command{g77} passes arguments via reference---specifically,
5966 by passing a pointer to the location in memory of a variable, array,
5967 array element, a temporary location that holds the result of evaluating an
5968 expression, or a temporary or permanent location that holds the value
5971 Procedures that accept @code{CHARACTER} arguments are implemented by
5972 @command{g77} so that each @code{CHARACTER} argument has two actual arguments.
5974 The first argument occupies the expected position in the
5975 argument list and has the user-specified name.
5977 is a pointer to an array of characters, passed by the caller.
5979 The second argument is appended to the end of the user-specified
5980 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
5981 is the user-specified name.
5982 This argument is of the C type @code{ftnlen}
5983 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
5984 is the number of characters the caller has allocated in the
5985 array pointed to by the first argument.
5987 A procedure will ignore the length argument if @samp{X} is not declared
5988 @code{CHARACTER*(*)}, because for other declarations, it knows the
5990 Not all callers necessarily ``know'' this, however, which
5991 is why they all pass the extra argument.
5993 The contents of the @code{CHARACTER} argument are specified by the
5994 address passed in the first argument (named after it).
5995 The procedure can read or write these contents as appropriate.
5997 When more than one @code{CHARACTER} argument is present in the argument
5998 list, the length arguments are appended in the order
5999 the original arguments appear.
6000 So @samp{CALL FOO('HI','THERE')} is implemented in
6001 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77}
6002 does not provide the trailing null bytes on the constant
6003 strings (@command{f2c} does provide them, but they are unnecessary in
6004 a Fortran environment, and you should not expect them to be
6007 Note that the above information applies to @code{CHARACTER} variables and
6008 arrays @strong{only}.
6009 It does @strong{not} apply to external @code{CHARACTER}
6010 functions or to intrinsic @code{CHARACTER} functions.
6011 That is, no second length argument is passed to @samp{FOO} in this case:
6020 Nor does @samp{FOO} expect such an argument in this case:
6028 Because of this implementation detail, if a program has a bug
6029 such that there is disagreement as to whether an argument is
6030 a procedure, and the type of the argument is @code{CHARACTER}, subtle
6031 symptoms might appear.
6034 @section Functions (FUNCTION and RETURN)
6036 @cindex FUNCTION statement
6037 @cindex statements, FUNCTION
6038 @cindex RETURN statement
6039 @cindex statements, RETURN
6040 @cindex return type of functions
6042 @command{g77} handles in a special way functions that return the following
6054 For @code{CHARACTER}, @command{g77} implements a subroutine (a C function
6055 returning @code{void})
6056 with two arguments prepended: @samp{__g77_result}, which the caller passes
6057 as a pointer to a @code{char} array expected to hold the return value,
6058 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
6059 specifying the length of the return value as declared in the calling
6061 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
6062 to determine the size of the array that @samp{__g77_result} points to;
6063 otherwise, it ignores that argument.
6065 For @code{COMPLEX}, when @option{-ff2c} is in
6066 force, @command{g77} implements
6067 a subroutine with one argument prepended: @samp{__g77_result}, which the
6068 caller passes as a pointer to a variable of the type of the function.
6069 The called function writes the return value into this variable instead
6070 of returning it as a function value.
6071 When @option{-fno-f2c} is in force,
6072 @command{g77} implements a @code{COMPLEX} function as @command{gcc}'s
6073 @samp{__complex__ float} or @samp{__complex__ double} function
6074 (or an emulation thereof, when @option{-femulate-complex} is in effect),
6075 returning the result of the function in the same way as @command{gcc} would.
6077 For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements
6078 a function that actually returns @code{REAL(KIND=2)} (typically
6079 C's @code{double} type).
6080 When @option{-fno-f2c} is in force, @code{REAL(KIND=1)}
6081 functions return @code{float}.
6085 @cindex symbol names
6086 @cindex transforming symbol names
6088 Fortran permits each implementation to decide how to represent
6089 names as far as how they're seen in other contexts, such as debuggers
6090 and when interfacing to other languages, and especially as far
6091 as how casing is handled.
6093 External names---names of entities that are public, or ``accessible'',
6094 to all modules in a program---normally have an underscore (@samp{_})
6095 appended by @command{g77},
6096 to generate code that is compatible with @command{f2c}.
6097 External names include names of Fortran things like common blocks,
6098 external procedures (subroutines and functions, but not including
6099 statement functions, which are internal procedures), and entry point
6102 However, use of the @option{-fno-underscoring} option
6103 disables this kind of transformation of external names (though inhibiting
6104 the transformation certainly improves the chances of colliding with
6105 incompatible externals written in other languages---but that
6106 might be intentional.
6108 @cindex -fno-underscoring option
6109 @cindex options, -fno-underscoring
6110 @cindex -fno-second-underscore option
6111 @cindex options, -fno-underscoring
6112 When @option{-funderscoring} is in force, any name (external or local)
6113 that already has at least one underscore in it is
6114 implemented by @command{g77} by appending two underscores.
6115 (This second underscore can be disabled via the
6116 @option{-fno-second-underscore} option.)
6117 External names are changed this way for @command{f2c} compatibility.
6118 Local names are changed this way to avoid collisions with external names
6119 that are different in the source code---@command{f2c} does the same thing, but
6120 there's no compatibility issue there except for user expectations while
6131 Here, a user would, in the debugger, refer to this variable using the
6132 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
6133 as described below).
6134 (We hope to improve @command{g77} in this regard in the future---don't
6135 write scripts depending on this behavior!
6136 Also, consider experimenting with the @option{-fno-underscoring}
6137 option to try out debugging without having to massage names by
6140 @command{g77} provides a number of command-line options that allow the user
6141 to control how case mapping is handled for source files.
6142 The default is the traditional UNIX model for Fortran compilers---names
6143 are mapped to lower case.
6144 Other command-line options can be specified to map names to upper
6145 case, or to leave them exactly as written in the source file.
6154 Here, it is normally the case that the variable assigned will be named
6156 This would be the name to enter when using a debugger to
6157 access the variable.
6159 However, depending on the command-line options specified, the
6160 name implemented by @command{g77} might instead be @samp{FOO} or even
6161 @samp{Foo}, thus affecting how debugging is done.
6170 This would normally call a procedure that, if it were in a separate C program,
6171 be defined starting with the line:
6178 However, @command{g77} command-line options could be used to change the casing
6179 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
6180 procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option
6181 could be used to inhibit the appending of the underscore to the name.
6184 @section Common Blocks (COMMON)
6185 @cindex common blocks
6186 @cindex @code{COMMON} statement
6187 @cindex statements, @code{COMMON}
6189 @command{g77} names and lays out @code{COMMON} areas
6190 the same way @command{f2c} does,
6191 for compatibility with @command{f2c}.
6193 @node Local Equivalence Areas
6194 @section Local Equivalence Areas (EQUIVALENCE)
6195 @cindex equivalence areas
6196 @cindex local equivalence areas
6197 @cindex EQUIVALENCE statement
6198 @cindex statements, EQUIVALENCE
6200 @command{g77} treats storage-associated areas involving a @code{COMMON}
6201 block as explained in the section on common blocks.
6203 A local @code{EQUIVALENCE} area is a collection of variables and arrays
6204 connected to each other in any way via @code{EQUIVALENCE}, none of which are
6205 listed in a @code{COMMON} statement.
6207 (@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name
6208 for @var{x} using a different method when more than one name was
6209 in the list of names of entities placed at the beginning of the
6211 Though the documentation specified that the first name listed in
6212 the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77}
6213 in fact chose the name using a method that was so complicated,
6214 it seemed easier to change it to an alphabetical sort than to describe the
6215 previous method in the documentation.)
6217 @node Complex Variables
6218 @section Complex Variables (COMPLEX)
6219 @cindex complex variables
6220 @cindex imaginary part
6221 @cindex COMPLEX statement
6222 @cindex statements, COMPLEX
6224 As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types
6225 (and related intrinsics, constants, functions, and so on)
6227 makes direct debugging involving these types in Fortran
6228 language mode difficult.
6230 Essentially, @command{g77} implements these types using an
6231 internal construct similar to C's @code{struct}, at least
6232 as seen by the @command{gcc} back end.
6234 Currently, the back end, when outputting debugging info with
6235 the compiled code for the assembler to digest, does not detect
6236 these @code{struct} types as being substitutes for Fortran
6238 As a result, the Fortran language modes of debuggers such as
6239 @command{gdb} see these types as C @code{struct} types, which
6240 they might or might not support.
6242 Until this is fixed, switch to C language mode to work with
6243 entities of @code{COMPLEX} type and then switch back to Fortran language
6245 (In @command{gdb}, this is accomplished via @samp{set lang c} and
6246 either @samp{set lang fortran} or @samp{set lang auto}.)
6249 @section Arrays (DIMENSION)
6250 @cindex DIMENSION statement
6251 @cindex statements, DIMENSION
6252 @cindex array ordering
6253 @cindex ordering, array
6254 @cindex column-major ordering
6255 @cindex row-major ordering
6258 Fortran uses ``column-major ordering'' in its arrays.
6259 This differs from other languages, such as C, which use ``row-major ordering''.
6260 The difference is that, with Fortran, array elements adjacent to
6261 each other in memory differ in the @emph{first} subscript instead of
6262 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
6263 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
6266 affects not only interfacing with and debugging Fortran code,
6267 it can greatly affect how code is designed and written, especially
6268 when code speed and size is a concern.
6270 Fortran also differs from C, a popular language for interfacing and
6271 to support directly in debuggers, in the way arrays are treated.
6272 In C, arrays are single-dimensional and have interesting relationships
6273 to pointers, neither of which is true for Fortran.
6274 As a result, dealing with Fortran arrays from within
6275 an environment limited to C concepts can be challenging.
6277 For example, accessing the array element @samp{A(5,10,20)} is easy enough
6278 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
6280 First, C would treat the A array as a single-dimension array.
6281 Second, C does not understand low bounds for arrays as does Fortran.
6282 Third, C assumes a low bound of zero (0), while Fortran defaults to a
6283 low bound of one (1) and can supports an arbitrary low bound.
6284 Therefore, calculations must be done
6285 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
6286 calculations require knowing the dimensions of @samp{A}.
6288 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
6289 @samp{A(5,10,20)} would be:
6294 + (20-0)*(11-2+1)*(21-1+1)
6299 So the C equivalent in this case would be @samp{a[4293]}.
6301 When using a debugger directly on Fortran code, the C equivalent
6302 might not work, because some debuggers cannot understand the notion
6303 of low bounds other than zero. However, unlike @command{f2c}, @command{g77}
6304 does inform the GBE that a multi-dimensional array (like @samp{A}
6305 in the above example) is really multi-dimensional, rather than a
6306 single-dimensional array, so at least the dimensionality of the array
6309 Debuggers that understand Fortran should have no trouble with
6310 non-zero low bounds, but for non-Fortran debuggers, especially
6311 C debuggers, the above example might have a C equivalent of
6313 This calculation is arrived at by eliminating the subtraction
6314 of the lower bound in the first parenthesized expression on each
6315 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
6316 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
6317 Actually, the implication of
6318 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
6319 but that @samp{a[20][10][5]} produces the equivalent of
6320 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
6322 Come to think of it, perhaps
6323 the behavior is due to the debugger internally compensating for
6324 the lower bounds by offsetting the base address of @samp{a}, leaving
6325 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
6326 its first element as identified by subscripts equal to the
6327 corresponding lower bounds).
6329 You know, maybe nobody really needs to use arrays.
6331 @node Adjustable Arrays
6332 @section Adjustable Arrays (DIMENSION)
6333 @cindex arrays, adjustable
6334 @cindex adjustable arrays
6335 @cindex arrays, automatic
6336 @cindex automatic arrays
6337 @cindex DIMENSION statement
6338 @cindex statements, DIMENSION
6339 @cindex dimensioning arrays
6340 @cindex arrays, dimensioning
6342 Adjustable and automatic arrays in Fortran require the implementation
6344 case, the @command{g77} compiler) to ``memorize'' the expressions that
6345 dimension the arrays each time the procedure is invoked.
6346 This is so that subsequent changes to variables used in those
6347 expressions, made during execution of the procedure, do not
6348 have any effect on the dimensions of those arrays.
6365 Here, the implementation should, when running the program, print something
6373 Note that this shows that while the value of @samp{N} was successfully
6374 changed, the size of the @samp{A} array remained at 5 elements.
6376 To support this, @command{g77} generates code that executes before any user
6377 code (and before the internally generated computed @code{GOTO} to handle
6378 alternate entry points, as described below) that evaluates each
6379 (nonconstant) expression in the list of subscripts for an
6380 array, and saves the result of each such evaluation to be used when
6381 determining the size of the array (instead of re-evaluating the
6384 So, in the above example, when @samp{X} is first invoked, code is
6385 executed that copies the value of @samp{N} to a temporary.
6386 And that same temporary serves as the actual high bound for the single
6387 dimension of the @samp{A} array (the low bound being the constant 1).
6388 Since the user program cannot (legitimately) change the value
6389 of the temporary during execution of the procedure, the size
6390 of the array remains constant during each invocation.
6392 For alternate entry points, the code @command{g77} generates takes into
6393 account the possibility that a dummy adjustable array is not actually
6394 passed to the actual entry point being invoked at that time.
6395 In that case, the public procedure implementing the entry point
6396 passes to the master private procedure implementing all the
6397 code for the entry points a @code{NULL} pointer where a pointer to that
6398 adjustable array would be expected.
6399 The @command{g77}-generated code
6400 doesn't attempt to evaluate any of the expressions in the subscripts
6401 for an array if the pointer to that array is @code{NULL} at run time in
6403 (Don't depend on this particular implementation
6404 by writing code that purposely passes @code{NULL} pointers where the
6405 callee expects adjustable arrays, even if you know the callee
6406 won't reference the arrays---nor should you pass @code{NULL} pointers
6407 for any dummy arguments used in calculating the bounds of such
6408 arrays or leave undefined any values used for that purpose in
6409 COMMON---because the way @command{g77} implements these things might
6410 change in the future!)
6412 @node Alternate Entry Points
6413 @section Alternate Entry Points (ENTRY)
6414 @cindex alternate entry points
6415 @cindex entry points
6416 @cindex ENTRY statement
6417 @cindex statements, ENTRY
6419 The GBE does not understand the general concept of
6420 alternate entry points as Fortran provides via the ENTRY statement.
6421 @command{g77} gets around this by using an approach to compiling procedures
6422 having at least one @code{ENTRY} statement that is almost identical to the
6423 approach used by @command{f2c}.
6424 (An alternate approach could be used that
6425 would probably generate faster, but larger, code that would also
6426 be a bit easier to debug.)
6428 Information on how @command{g77} implements @code{ENTRY} is provided for those
6429 trying to debug such code.
6430 The choice of implementation seems
6431 unlikely to affect code (compiled in other languages) that interfaces
6434 @command{g77} compiles exactly one public procedure for the primary entry
6435 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
6436 That is, in terms of the public interface, there is no difference
6455 The difference between the above two cases lies in the code compiled
6456 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
6457 for the second case, an extra internal procedure is compiled.
6459 For every Fortran procedure with at least one @code{ENTRY}
6460 statement, @command{g77} compiles an extra procedure
6461 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
6462 the name of the primary entry point (which, in the above case,
6463 using the standard compiler options, would be @samp{x_} in C).
6465 This extra procedure is compiled as a private procedure---that is,
6466 a procedure not accessible by name to separately compiled modules.
6467 It contains all the code in the program unit, including the code
6468 for the primary entry point plus for every entry point.
6469 (The code for each public procedure is quite short, and explained later.)
6471 The extra procedure has some other interesting characteristics.
6473 The argument list for this procedure is invented by @command{g77}.
6475 a single integer argument named @samp{__g77_which_entrypoint},
6476 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
6477 entry point index---0 for the primary entry point, 1 for the
6478 first entry point (the first @code{ENTRY} statement encountered), 2 for
6479 the second entry point, and so on.
6481 It also contains, for functions returning @code{CHARACTER} and
6482 (when @option{-ff2c} is in effect) @code{COMPLEX} functions,
6483 and for functions returning different types among the
6484 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
6485 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
6486 is expected at run time to contain a pointer to where to store
6487 the result of the entry point.
6488 For @code{CHARACTER} functions, this
6489 storage area is an array of the appropriate number of characters;
6490 for @code{COMPLEX} functions, it is the appropriate area for the return
6491 type; for multiple-return-type functions, it is a union of all the supported return
6492 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
6493 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
6494 is not supported by @command{g77}).
6496 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
6497 by yet another argument named @samp{__g77_length} that, at run time,
6498 specifies the caller's expected length of the returned value.
6499 Note that only @code{CHARACTER*(*)} functions and entry points actually
6500 make use of this argument, even though it is always passed by
6501 all callers of public @code{CHARACTER} functions (since the caller does not
6502 generally know whether such a function is @code{CHARACTER*(*)} or whether
6503 there are any other callers that don't have that information).
6505 The rest of the argument list is the union of all the arguments
6506 specified for all the entry points (in their usual forms, e.g.
6507 @code{CHARACTER} arguments have extra length arguments, all appended at
6508 the end of this list).
6509 This is considered the ``master list'' of
6512 The code for this procedure has, before the code for the first
6513 executable statement, code much like that for the following Fortran
6517 GOTO (100000,100001,100002), __g77_which_entrypoint
6518 100000 @dots{}code for primary entry point@dots{}
6519 100001 @dots{}code immediately following first ENTRY statement@dots{}
6520 100002 @dots{}code immediately following second ENTRY statement@dots{}
6524 (Note that invalid Fortran statement labels and variable names
6525 are used in the above example to highlight the fact that it
6526 represents code generated by the @command{g77} internals, not code to be
6527 written by the user.)
6529 It is this code that, when the procedure is called, picks which
6530 entry point to start executing.
6532 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
6533 example), those procedures are fairly simple.
6535 are just like they would be if they were self-contained procedures
6536 (without @code{ENTRY}), of course, since that is what the callers
6538 Their code consists of simply calling the private
6539 procedure, described above, with the appropriate extra arguments
6540 (the entry point index, and perhaps a pointer to a multiple-type-
6541 return variable, local to the public procedure, that contains
6542 all the supported returnable non-character types).
6544 that are not listed for a given entry point that are listed for
6545 other entry points, and therefore that are in the ``master list''
6546 for the private procedure, null pointers (in C, the @code{NULL} macro)
6548 Also, for entry points that are part of a multiple-type-
6549 returning function, code is compiled after the call of the private
6550 procedure to extract from the multi-type union the appropriate result,
6551 depending on the type of the entry point in question, returning
6552 that result to the original caller.
6554 When debugging a procedure containing alternate entry points, you
6555 can either set a break point on the public procedure itself (e.g.
6556 a break point on @samp{X} or @samp{Y}) or on the private procedure that
6557 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
6558 If you do the former, you should use the debugger's command to
6559 ``step into'' the called procedure to get to the actual code; with
6560 the latter approach, the break point leaves you right at the
6561 actual code, skipping over the public entry point and its call
6562 to the private procedure (unless you have set a break point there
6563 as well, of course).
6565 Further, the list of dummy arguments that is visible when the
6566 private procedure is active is going to be the expanded version
6567 of the list for whichever particular entry point is active,
6568 as explained above, and the way in which return values are
6569 handled might well be different from how they would be handled
6570 for an equivalent single-entry function.
6572 @node Alternate Returns
6573 @section Alternate Returns (SUBROUTINE and RETURN)
6575 @cindex alternate returns
6576 @cindex SUBROUTINE statement
6577 @cindex statements, SUBROUTINE
6578 @cindex RETURN statement
6579 @cindex statements, RETURN
6581 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
6582 @samp{CALL X(*50)}) are implemented by @command{g77} as functions returning
6583 the C @code{int} type.
6584 The actual alternate-return arguments are omitted from the calling sequence.
6585 Instead, the caller uses
6586 the return value to do a rough equivalent of the Fortran
6587 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
6588 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
6589 function), and the callee just returns whatever integer
6590 is specified in the @code{RETURN} statement for the subroutine
6591 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
6593 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
6595 @node Assigned Statement Labels
6596 @section Assigned Statement Labels (ASSIGN and GOTO)
6597 @cindex assigned statement labels
6598 @cindex statement labels, assigned
6599 @cindex ASSIGN statement
6600 @cindex statements, ASSIGN
6601 @cindex GOTO statement
6602 @cindex statements, GOTO
6604 For portability to machines where a pointer (such as to a label,
6605 which is how @command{g77} implements @code{ASSIGN} and its relatives,
6606 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
6607 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77}
6608 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
6609 than it does the numerical value in that variable, unless the
6610 variable is wide enough (can hold enough bits).
6612 In particular, while @command{g77} implements
6619 as, in C notation, @samp{i = 10;}, it implements
6626 as, in GNU's extended C notation (for the label syntax),
6627 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
6628 of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't
6629 actually generate the name @samp{L10} or any other name like that,
6630 since debuggers cannot access labels anyway).
6632 While this currently means that an @code{ASSIGN} statement does not
6633 overwrite the numeric contents of its target variable, @emph{do not}
6634 write any code depending on this feature.
6635 @command{g77} has already changed this implementation across
6636 versions and might do so in the future.
6637 This information is provided only to make debugging Fortran programs
6638 compiled with the current version of @command{g77} somewhat easier.
6639 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
6640 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
6641 means @command{g77} has decided it can store the pointer to the label directly
6642 into @samp{I} itself.
6644 @xref{Ugly Assigned Labels}, for information on a command-line option
6645 to force @command{g77} to use the same storage for both normal and
6646 assigned-label uses of a variable.
6648 @node Run-time Library Errors
6649 @section Run-time Library Errors
6651 @cindex error values
6652 @cindex error messages
6653 @cindex messages, run-time
6656 The @code{libg2c} library currently has the following table to relate
6657 error code numbers, returned in @code{IOSTAT=} variables, to messages.
6658 This information should, in future versions of this document, be
6659 expanded upon to include detailed descriptions of each message.
6661 In line with good coding practices, any of the numbers in the
6662 list below should @emph{not} be directly written into Fortran
6664 Instead, make a separate @code{INCLUDE} file that defines
6665 @code{PARAMETER} names for them, and use those in your code,
6666 so you can more easily change the actual numbers in the future.
6668 The information below is culled from the definition
6669 of @code{F_err} in @file{f/runtime/libI77/err.c} in the
6670 @command{g77} source tree.
6673 100: "error in format"
6674 101: "illegal unit number"
6675 102: "formatted io not allowed"
6676 103: "unformatted io not allowed"
6677 104: "direct io not allowed"
6678 105: "sequential io not allowed"
6679 106: "can't backspace file"
6680 107: "null file name"
6681 108: "can't stat file"
6682 109: "unit not connected"
6683 110: "off end of record"
6684 111: "truncation failed in endfile"
6685 112: "incomprehensible list input"
6686 113: "out of free space"
6687 114: "unit not connected"
6688 115: "read unexpected character"
6689 116: "bad logical input field"
6690 117: "bad variable type"
6691 118: "bad namelist name"
6692 119: "variable not in namelist"
6693 120: "no end record"
6694 121: "variable count incorrect"
6695 122: "subscript for scalar variable"
6696 123: "invalid array section"
6697 124: "substring out of bounds"
6698 125: "subscript out of bounds"
6699 126: "can't read file"
6700 127: "can't write file"
6701 128: "'new' file exists"
6702 129: "can't append to file"
6703 130: "non-positive record number"
6704 131: "I/O started while already doing I/O"
6707 @node Collected Fortran Wisdom
6708 @chapter Collected Fortran Wisdom
6711 @cindex code, legacy
6712 @cindex writing code
6713 @cindex code, writing
6715 Most users of @command{g77} can be divided into two camps:
6719 Those writing new Fortran code to be compiled by @command{g77}.
6722 Those using @command{g77} to compile existing, ``legacy'' code.
6725 Users writing new code generally understand most of the necessary
6726 aspects of Fortran to write ``mainstream'' code, but often need
6727 help deciding how to handle problems, such as the construction
6728 of libraries containing @code{BLOCK DATA}.
6730 Users dealing with ``legacy'' code sometimes don't have much
6731 experience with Fortran, but believe that the code they're compiling
6732 already works when compiled by other compilers (and might
6733 not understand why, as is sometimes the case, it doesn't work
6734 when compiled by @command{g77}).
6736 The following information is designed to help users do a better job
6737 coping with existing, ``legacy'' Fortran code, and with writing
6741 * Advantages Over f2c:: If @command{f2c} is so great, why @command{g77}?
6742 * Block Data and Libraries:: How @command{g77} solves a common problem.
6743 * Loops:: Fortran @code{DO} loops surprise many people.
6744 * Working Programs:: Getting programs to work should be done first.
6745 * Overly Convenient Options:: Temptations to avoid, habits to not form.
6746 * Faster Programs:: Everybody wants these, but at what cost?
6749 @node Advantages Over f2c
6750 @section Advantages Over f2c
6752 Without @command{f2c}, @command{g77} would have taken much longer to
6753 do and probably not been as good for quite a while.
6754 Sometimes people who notice how much @command{g77} depends on, and
6755 documents encouragement to use, @command{f2c} ask why @command{g77}
6756 was created if @command{f2c} already existed.
6758 This section gives some basic answers to these questions, though it
6759 is not intended to be comprehensive.
6762 * Language Extensions:: Features used by Fortran code.
6763 * Diagnostic Abilities:: Abilities to spot problems early.
6764 * Compiler Options:: Features helpful to accommodate legacy code, etc.
6765 * Compiler Speed:: Speed of the compilation process.
6766 * Program Speed:: Speed of the generated, optimized code.
6767 * Ease of Debugging:: Debugging ease-of-use at the source level.
6768 * Character and Hollerith Constants:: A byte saved is a byte earned.
6771 @node Language Extensions
6772 @subsection Language Extensions
6774 @command{g77} offers several extensions to FORTRAN 77 language that @command{f2c}
6782 @code{CYCLE} and @code{EXIT}
6791 @code{KIND=} and @code{LEN=} notation
6794 Semicolon as statement separator
6797 Constant expressions in @code{FORMAT} statements
6798 (such as @samp{FORMAT(I<J>)},
6799 where @samp{J} is a @code{PARAMETER} named constant)
6802 @code{MvBits} intrinsic
6805 @code{libU77} (Unix-compatibility) library,
6806 with routines known to compiler as intrinsics
6807 (so they work even when compiler options are used
6808 to change the interfaces used by Fortran routines)
6811 @command{g77} also implements iterative @code{DO} loops
6812 so that they work even in the presence of certain ``extreme'' inputs,
6813 unlike @command{f2c}.
6816 However, @command{f2c} offers a few that @command{g77} doesn't, such as:
6820 Intrinsics in @code{PARAMETER} statements
6823 Array bounds expressions (such as @samp{REAL M(N(2))})
6826 @code{AUTOMATIC} statement
6829 It is expected that @command{g77} will offer some or all of these missing
6830 features at some time in the future.
6832 @node Diagnostic Abilities
6833 @subsection Diagnostic Abilities
6835 @command{g77} offers better diagnosis of problems in @code{FORMAT} statements.
6836 @command{f2c} doesn't, for example, emit any diagnostic for
6837 @samp{FORMAT(XZFAJG10324)},
6838 leaving that to be diagnosed, at run time, by
6839 the @code{libf2c} run-time library.
6841 @node Compiler Options
6842 @subsection Compiler Options
6844 @command{g77} offers compiler options that @command{f2c} doesn't,
6845 most of which are designed to more easily accommodate
6850 Two that control the automatic appending of extra
6851 underscores to external names
6854 One that allows dollar signs (@samp{$}) in symbol names
6857 A variety that control acceptance of various
6861 Several that specify acceptable use of upper and lower case
6865 Many that enable, disable, delete, or hide
6866 groups of intrinsics
6869 One to specify the length of fixed-form source lines
6873 One to specify the the source code is written in
6874 Fortran-90-style free-form
6877 However, @command{f2c} offers a few that @command{g77} doesn't,
6878 like an option to have @code{REAL} default to @code{REAL*8}.
6879 It is expected that @command{g77} will offer all of the
6880 missing options pertinent to being a Fortran compiler
6881 at some time in the future.
6883 @node Compiler Speed
6884 @subsection Compiler Speed
6886 Saving the steps of writing and then rereading C code is a big reason
6887 why @command{g77} should be able to compile code much faster than using
6888 @command{f2c} in conjunction with the equivalent invocation of @command{gcc}.
6890 However, due to @command{g77}'s youth, lots of self-checking is still being
6892 As a result, this improvement is as yet unrealized
6893 (though the potential seems to be there for quite a big speedup
6895 It is possible that, as of version 0.5.18, @command{g77}
6896 is noticeably faster compiling many Fortran source files than using
6897 @command{f2c} in conjunction with @command{gcc}.
6900 @subsection Program Speed
6902 @command{g77} has the potential to better optimize code than @command{f2c},
6903 even when @command{gcc} is used to compile the output of @command{f2c},
6904 because @command{f2c} must necessarily
6905 translate Fortran into a somewhat lower-level language (C) that cannot
6906 preserve all the information that is potentially useful for optimization,
6907 while @command{g77} can gather, preserve, and transmit that information directly
6910 For example, @command{g77} implements @code{ASSIGN} and assigned
6911 @code{GOTO} using direct assignment of pointers to labels and direct
6912 jumps to labels, whereas @command{f2c} maps the assigned labels to
6913 integer values and then uses a C @code{switch} statement to encode
6914 the assigned @code{GOTO} statements.
6916 However, as is typical, theory and reality don't quite match, at least
6917 not in all cases, so it is still the case that @command{f2c} plus @command{gcc}
6918 can generate code that is faster than @command{g77}.
6920 Version 0.5.18 of @command{g77} offered default
6921 settings and options, via patches to the @command{gcc}
6922 back end, that allow for better program speed, though
6923 some of these improvements also affected the performance
6924 of programs translated by @command{f2c} and then compiled
6925 by @command{g77}'s version of @command{gcc}.
6927 Version 0.5.20 of @command{g77} offers further performance
6928 improvements, at least one of which (alias analysis) is
6929 not generally applicable to @command{f2c} (though @command{f2c}
6930 could presumably be changed to also take advantage of
6931 this new capability of the @command{gcc} back end, assuming
6932 this is made available in an upcoming release of @command{gcc}).
6934 @node Ease of Debugging
6935 @subsection Ease of Debugging
6937 Because @command{g77} compiles directly to assembler code like @command{gcc},
6938 instead of translating to an intermediate language (C) as does @command{f2c},
6939 support for debugging can be better for @command{g77} than @command{f2c}.
6941 However, although @command{g77} might be somewhat more ``native'' in terms of
6942 debugging support than @command{f2c} plus @command{gcc}, there still are a lot
6943 of things ``not quite right''.
6944 Many of the important ones should be resolved in the near future.
6946 For example, @command{g77} doesn't have to worry about reserved names
6947 like @command{f2c} does.
6948 Given @samp{FOR = WHILE}, @command{f2c} must necessarily
6949 translate this to something @emph{other} than
6950 @samp{for = while;}, because C reserves those words.
6952 However, @command{g77} does still uses things like an extra level of indirection
6953 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
6954 yet support multiple entry points.
6956 Another example is that, given
6964 the @command{g77} user should be able to access the variables directly, by name,
6965 without having to traverse C-like structures and unions, while @command{f2c}
6966 is unlikely to ever offer this ability (due to limitations in the
6969 However, due to apparent bugs in the back end, @command{g77} currently doesn't
6970 take advantage of this facility at all---it doesn't emit any debugging
6971 information for @code{COMMON} and @code{EQUIVALENCE} areas,
6972 other than information
6973 on the array of @code{char} it creates (and, in the case
6974 of local @code{EQUIVALENCE}, names) for each such area.
6976 Yet another example is arrays.
6977 @command{g77} represents them to the debugger
6978 using the same ``dimensionality'' as in the source code, while @command{f2c}
6979 must necessarily convert them all to one-dimensional arrays to fit
6980 into the confines of the C language.
6981 However, the level of support
6982 offered by debuggers for interactive Fortran-style access to arrays
6983 as compiled by @command{g77} can vary widely.
6984 In some cases, it can actually
6985 be an advantage that @command{f2c} converts everything to widely supported
6988 In fairness, @command{g77} could do many of the things @command{f2c} does
6989 to get things working at least as well as @command{f2c}---for now,
6990 the developers prefer making @command{g77} work the
6991 way they think it is supposed to, and finding help improving the
6992 other products (the back end of @command{gcc}; @command{gdb}; and so on)
6993 to get things working properly.
6995 @node Character and Hollerith Constants
6996 @subsection Character and Hollerith Constants
6997 @cindex character constants
6998 @cindex constants, character
6999 @cindex Hollerith constants
7000 @cindex constants, Hollerith
7001 @cindex trailing null byte
7002 @cindex null byte, trailing
7003 @cindex zero byte, trailing
7005 To avoid the extensive hassle that would be needed to avoid this,
7006 @command{f2c} uses C character constants to encode character and Hollerith
7008 That means a constant like @samp{'HELLO'} is translated to
7009 @samp{"hello"} in C, which further means that an extra null byte is
7010 present at the end of the constant.
7011 This null byte is superfluous.
7013 @command{g77} does not generate such null bytes.
7014 This represents significant
7015 savings of resources, such as on systems where @file{/dev/null} or
7016 @file{/dev/zero} represent bottlenecks in the systems' performance,
7017 because @command{g77} simply asks for fewer zeros from the operating
7018 system than @command{f2c}.
7019 (Avoiding spurious use of zero bytes, each byte typically have
7020 eight zero bits, also reduces the liabilities in case
7021 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
7023 @node Block Data and Libraries
7024 @section Block Data and Libraries
7025 @cindex block data and libraries
7026 @cindex BLOCK DATA statement
7027 @cindex statements, BLOCK DATA
7028 @cindex libraries, containing BLOCK DATA
7029 @cindex f2c compatibility
7030 @cindex compatibility, f2c
7032 To ensure that block data program units are linked, especially a concern
7033 when they are put into libraries, give each one a name (as in
7034 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
7035 statement in every program unit that uses any common block
7036 initialized by the corresponding @code{BLOCK DATA}.
7037 @command{g77} currently compiles a @code{BLOCK DATA} as if it were a
7039 that is, it generates an actual procedure having the appropriate name.
7040 The procedure does nothing but return immediately if it happens to be
7042 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
7043 same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO}
7044 in the program and ensures that by generating a
7045 reference to it so the linker will make sure it is present.
7046 (Specifically, @command{g77} outputs in the data section a static pointer to the
7047 external name @samp{FOO}.)
7049 The implementation @command{g77} currently uses to make this work is
7050 one of the few things not compatible with @command{f2c} as currently
7052 @command{f2c} currently does nothing with @samp{EXTERNAL FOO} except
7053 issue a warning that @samp{FOO} is not otherwise referenced,
7054 and, for @samp{BLOCK DATA FOO},
7055 @command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
7056 The upshot is that you shouldn't mix @command{f2c} and @command{g77} in
7057 this particular case.
7058 If you use @command{f2c} to compile @samp{BLOCK DATA FOO},
7059 then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO}
7060 will result in an unresolved reference when linked.
7062 opposite, then @samp{FOO} might not be linked in under various
7063 circumstances (such as when @samp{FOO} is in a library, or you're
7064 using a ``clever'' linker---so clever, it produces a broken program
7065 with little or no warning by omitting initializations of global data
7066 because they are contained in unreferenced procedures).
7068 The changes you make to your code to make @command{g77} handle this situation,
7069 however, appear to be a widely portable way to handle it.
7070 That is, many systems permit it (as they should, since the
7071 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
7072 is a block data program unit), and of the ones
7073 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
7074 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
7077 Here is the recommended approach to modifying a program containing
7078 a program unit such as the following:
7082 COMMON /VARS/ X, Y, Z
7083 DATA X, Y, Z / 3., 4., 5. /
7088 If the above program unit might be placed in a library module, then
7089 ensure that every program unit in every program that references that
7090 particular @code{COMMON} area uses the @code{EXTERNAL} statement
7091 to force the area to be initialized.
7093 For example, change a program unit that starts with
7096 INTEGER FUNCTION CURX()
7097 COMMON /VARS/ X, Y, Z
7103 so that it uses the @code{EXTERNAL} statement, as in:
7106 INTEGER FUNCTION CURX()
7107 COMMON /VARS/ X, Y, Z
7114 That way, @samp{CURX} is compiled by @command{g77} (and many other
7115 compilers) so that the linker knows it must include @samp{FOO},
7116 the @code{BLOCK DATA} program unit that sets the initial values
7117 for the variables in @samp{VAR}, in the executable program.
7121 @cindex DO statement
7122 @cindex statements, DO
7123 @cindex trips, number of
7124 @cindex number of trips
7126 The meaning of a @code{DO} loop in Fortran is precisely specified
7127 in the Fortran standard@dots{}and is quite different from what
7128 many programmers might expect.
7130 In particular, Fortran iterative @code{DO} loops are implemented as if
7131 the number of trips through the loop is calculated @emph{before}
7132 the loop is entered.
7134 The number of trips for a loop is calculated from the @var{start},
7135 @var{end}, and @var{increment} values specified in a statement such as:
7138 DO @var{iter} = @var{start}, @var{end}, @var{increment}
7142 The trip count is evaluated using a fairly simple formula
7143 based on the three values following the @samp{=} in the
7144 statement, and it is that trip count that is effectively
7145 decremented during each iteration of the loop.
7146 If, at the beginning of an iteration of the loop, the
7147 trip count is zero or negative, the loop terminates.
7148 The per-loop-iteration modifications to @var{iter} are not
7149 related to determining whether to terminate the loop.
7151 There are two important things to remember about the trip
7156 It can be @emph{negative}, in which case it is
7157 treated as if it was zero---meaning the loop is
7158 not executed at all.
7161 The type used to @emph{calculate} the trip count
7162 is the same type as @var{iter}, but the final
7163 calculation, and thus the type of the trip
7164 count itself, always is @code{INTEGER(KIND=1)}.
7167 These two items mean that there are loops that cannot
7168 be written in straightforward fashion using the Fortran @code{DO}.
7170 For example, on a system with the canonical 32-bit two's-complement
7171 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
7174 DO I = -2000000000, 2000000000
7178 Although the @var{start} and @var{end} values are well within
7179 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
7180 The expected trip count is 40000000001, which is outside
7181 the range of @code{INTEGER(KIND=1)} on many systems.
7183 Instead, the above loop should be constructed this way:
7188 IF (I .GT. 2000000000) EXIT
7195 The simple @code{DO} construct and the @code{EXIT} statement
7196 (used to leave the innermost loop)
7197 are F90 features that @command{g77} supports.
7199 Some Fortran compilers have buggy implementations of @code{DO},
7200 in that they don't follow the standard.
7201 They implement @code{DO} as a straightforward translation
7202 to what, in C, would be a @code{for} statement.
7203 Instead of creating a temporary variable to hold the trip count
7204 as calculated at run time, these compilers
7205 use the iteration variable @var{iter} to control
7206 whether the loop continues at each iteration.
7208 The bug in such an implementation shows up when the
7209 trip count is within the range of the type of @var{iter},
7210 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
7211 exceeds that range. For example:
7214 DO I = 2147483600, 2147483647
7218 A loop started by the above statement will work as implemented
7219 by @command{g77}, but the use, by some compilers, of a
7220 more C-like implementation akin to
7223 for (i = 2147483600; i <= 2147483647; ++i)
7227 produces a loop that does not terminate, because @samp{i}
7228 can never be greater than 2147483647, since incrementing it
7229 beyond that value overflows @samp{i}, setting it to -2147483648.
7230 This is a large, negative number that still is less than 2147483647.
7232 Another example of unexpected behavior of @code{DO} involves
7233 using a nonintegral iteration variable @var{iter}, that is,
7234 a @code{REAL} variable.
7235 Consider the following program:
7238 DATA BEGIN, END, STEP /.1, .31, .007/
7239 DO 10 R = BEGIN, END, STEP
7240 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
7244 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
7249 A C-like view of @code{DO} would hold that the two ``exclamatory''
7250 @code{PRINT} statements are never executed.
7251 However, this is the output of running the above program
7252 as compiled by @command{g77} on a GNU/Linux ix86 system:
7264 .310000002 .LE. .310000002!!
7267 Note that one of the two checks in the program turned up
7268 an apparent violation of the programmer's expectation---yet,
7269 the loop is correctly implemented by @command{g77}, in that
7270 it has 30 iterations.
7271 This trip count of 30 is correct when evaluated using
7272 the floating-point representations for the @var{begin},
7273 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
7275 On other systems, an apparently more accurate trip count
7276 of 31 might result, but, nevertheless, @command{g77} is
7277 faithfully following the Fortran standard, and the result
7278 is not what the author of the sample program above
7279 apparently expected.
7280 (Such other systems might, for different values in the @code{DATA}
7281 statement, violate the other programmer's expectation,
7284 Due to this combination of imprecise representation
7285 of floating-point values and the often-misunderstood
7286 interpretation of @code{DO} by standard-conforming
7287 compilers such as @command{g77}, use of @code{DO} loops
7288 with @code{REAL} iteration
7289 variables is not recommended.
7290 Such use can be caught by specifying @option{-Wsurprising}.
7291 @xref{Warning Options}, for more information on this
7294 @node Working Programs
7295 @section Working Programs
7297 Getting Fortran programs to work in the first place can be
7298 quite a challenge---even when the programs already work on
7299 other systems, or when using other compilers.
7301 @command{g77} offers some facilities that might be useful for
7302 tracking down bugs in such programs.
7306 * Variables Assumed To Be Zero::
7307 * Variables Assumed To Be Saved::
7308 * Unwanted Variables::
7309 * Unused Arguments::
7310 * Surprising Interpretations of Code::
7311 * Aliasing Assumed To Work::
7312 * Output Assumed To Flush::
7313 * Large File Unit Numbers::
7314 * Floating-point precision::
7315 * Inconsistent Calling Sequences::
7319 @subsection Not My Type
7320 @cindex mistyped variables
7321 @cindex variables, mistyped
7322 @cindex mistyped functions
7323 @cindex functions, mistyped
7324 @cindex implicit typing
7326 A fruitful source of bugs in Fortran source code is use, or
7327 mis-use, of Fortran's implicit-typing feature, whereby the
7328 type of a variable, array, or function is determined by the
7329 first character of its name.
7331 Simple cases of this include statements like @samp{LOGX=9.227},
7332 without a statement such as @samp{REAL LOGX}.
7333 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
7334 type, with the result of the assignment being that it is given
7337 More involved cases include a function that is defined starting
7338 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
7339 Any caller of this function that does not also declare @samp{IPS}
7340 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
7341 is likely to assume it returns
7342 @code{INTEGER}, or some other type, leading to invalid results
7343 or even program crashes.
7345 The @option{-Wimplicit} option might catch failures to
7346 properly specify the types of
7347 variables, arrays, and functions in the code.
7349 However, in code that makes heavy use of Fortran's
7350 implicit-typing facility, this option might produce so
7351 many warnings about cases that are working, it would be
7352 hard to find the one or two that represent bugs.
7353 This is why so many experienced Fortran programmers strongly
7354 recommend widespread use of the @code{IMPLICIT NONE} statement,
7355 despite it not being standard FORTRAN 77, to completely turn
7356 off implicit typing.
7357 (@command{g77} supports @code{IMPLICIT NONE}, as do almost all
7358 FORTRAN 77 compilers.)
7360 Note that @option{-Wimplicit} catches only implicit typing of
7362 It does not catch implicit typing of expressions such
7364 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
7365 is equivalent to @samp{X**0}, due to the way Fortran expressions
7366 are given types and then evaluated.
7367 (In this particular case, the programmer probably wanted
7370 @node Variables Assumed To Be Zero
7371 @subsection Variables Assumed To Be Zero
7372 @cindex zero-initialized variables
7373 @cindex variables, assumed to be zero
7374 @cindex uninitialized variables
7376 Many Fortran programs were developed on systems that provided
7377 automatic initialization of all, or some, variables and arrays
7379 As a result, many of these programs depend, sometimes
7380 inadvertently, on this behavior, though to do so violates
7381 the Fortran standards.
7383 You can ask @command{g77} for this behavior by specifying the
7384 @option{-finit-local-zero} option when compiling Fortran code.
7385 (You might want to specify @option{-fno-automatic} as well,
7386 to avoid code-size inflation for non-optimized compilations.)
7388 Note that a program that works better when compiled with the
7389 @option{-finit-local-zero} option
7390 is almost certainly depending on a particular system's,
7391 or compiler's, tendency to initialize some variables to zero.
7392 It might be worthwhile finding such cases and fixing them,
7393 using techniques such as compiling with the @option{-O -Wuninitialized}
7394 options using @command{g77}.
7396 @node Variables Assumed To Be Saved
7397 @subsection Variables Assumed To Be Saved
7398 @cindex variables, retaining values across calls
7399 @cindex saved variables
7400 @cindex static variables
7402 Many Fortran programs were developed on systems that
7403 saved the values of all, or some, variables and arrays
7404 across procedure calls.
7405 As a result, many of these programs depend, sometimes
7406 inadvertently, on being able to assign a value to a
7407 variable, perform a @code{RETURN} to a calling procedure,
7408 and, upon subsequent invocation, reference the previously
7409 assigned variable to obtain the value.
7411 They expect this despite not using the @code{SAVE} statement
7412 to specify that the value in a variable is expected to survive
7413 procedure returns and calls.
7414 Depending on variables and arrays to retain values across
7415 procedure calls without using @code{SAVE} to require it violates
7416 the Fortran standards.
7418 You can ask @command{g77} to assume @code{SAVE} is specified for all
7419 relevant (local) variables and arrays by using the
7420 @option{-fno-automatic} option.
7422 Note that a program that works better when compiled with the
7423 @option{-fno-automatic} option
7424 is almost certainly depending on not having to use
7425 the @code{SAVE} statement as required by the Fortran standard.
7426 It might be worthwhile finding such cases and fixing them,
7427 using techniques such as compiling with the @samp{-O -Wuninitialized}
7428 options using @command{g77}.
7430 @node Unwanted Variables
7431 @subsection Unwanted Variables
7433 The @option{-Wunused} option can find bugs involving
7434 implicit typing, sometimes
7435 more easily than using @option{-Wimplicit} in code that makes
7436 heavy use of implicit typing.
7437 An unused variable or array might indicate that the
7438 spelling for its declaration is different from that of
7441 Other than cases involving typos, unused variables rarely
7442 indicate actual bugs in a program.
7443 However, investigating such cases thoroughly has, on occasion,
7444 led to the discovery of code that had not been completely
7445 written---where the programmer wrote declarations as needed
7446 for the whole algorithm, wrote some or even most of the code
7447 for that algorithm, then got distracted and forgot that the
7448 job was not complete.
7450 @node Unused Arguments
7451 @subsection Unused Arguments
7452 @cindex unused arguments
7453 @cindex arguments, unused
7455 As with unused variables, It is possible that unused arguments
7456 to a procedure might indicate a bug.
7457 Compile with @samp{-W -Wunused} option to catch cases of
7460 Note that @option{-W} also enables warnings regarding overflow
7461 of floating-point constants under certain circumstances.
7463 @node Surprising Interpretations of Code
7464 @subsection Surprising Interpretations of Code
7466 The @option{-Wsurprising} option can help find bugs involving
7467 expression evaluation or in
7468 the way @code{DO} loops with non-integral iteration variables
7470 Cases found by this option might indicate a difference of
7471 interpretation between the author of the code involved, and
7472 a standard-conforming compiler such as @command{g77}.
7473 Such a difference might produce actual bugs.
7475 In any case, changing the code to explicitly do what the
7476 programmer might have expected it to do, so @command{g77} and
7477 other compilers are more likely to follow the programmer's
7478 expectations, might be worthwhile, especially if such changes
7479 make the program work better.
7481 @node Aliasing Assumed To Work
7482 @subsection Aliasing Assumed To Work
7483 @cindex -falias-check option
7484 @cindex options, -falias-check
7485 @cindex -fargument-alias option
7486 @cindex options, -fargument-alias
7487 @cindex -fargument-noalias option
7488 @cindex options, -fargument-noalias
7489 @cindex -fno-argument-noalias-global option
7490 @cindex options, -fno-argument-noalias-global
7492 @cindex anti-aliasing
7493 @cindex overlapping arguments
7495 @cindex association, storage
7496 @cindex storage association
7497 @cindex scheduling of reads and writes
7498 @cindex reads and writes, scheduling
7500 The @option{-falias-check}, @option{-fargument-alias},
7501 @option{-fargument-noalias},
7502 and @option{-fno-argument-noalias-global} options,
7503 introduced in version 0.5.20 and
7504 @command{g77}'s version 2.7.2.2.f.2 of @command{gcc},
7505 were withdrawn as of @command{g77} version 0.5.23
7506 due to their not being supported by @command{gcc} version 2.8.
7508 These options control the assumptions regarding aliasing
7509 (overlapping) of writes and reads to main memory (core) made
7510 by the @command{gcc} back end.
7512 The information below still is useful, but applies to
7513 only those versions of @command{g77} that support the
7514 alias analysis implied by support for these options.
7516 These options are effective only when compiling with @option{-O}
7517 (specifying any level other than @option{-O0})
7518 or with @option{-falias-check}.
7520 The default for Fortran code is @option{-fargument-noalias-global}.
7521 (The default for C code and code written in other C-based languages
7522 is @option{-fargument-alias}.
7523 These defaults apply regardless of whether you use @command{g77} or
7524 @command{gcc} to compile your code.)
7526 Note that, on some systems, compiling with @option{-fforce-addr} in
7527 effect can produce more optimal code when the default aliasing
7528 options are in effect (and when optimization is enabled).
7530 If your program is not working when compiled with optimization,
7531 it is possible it is violating the Fortran standards (77 and 90)
7532 by relying on the ability to ``safely'' modify variables and
7533 arrays that are aliased, via procedure calls, to other variables
7534 and arrays, without using @code{EQUIVALENCE} to explicitly
7535 set up this kind of aliasing.
7537 (The FORTRAN 77 standard's prohibition of this sort of
7538 overlap, generally referred to therein as ``storage
7539 assocation'', appears in Sections 15.9.3.6.
7540 This prohibition allows implementations, such as @command{g77},
7541 to, for example, implement the passing of procedures and
7542 even values in @code{COMMON} via copy operations into local,
7543 perhaps more efficiently accessed temporaries at entry to a
7544 procedure, and, where appropriate, via copy operations back
7545 out to their original locations in memory at exit from that
7546 procedure, without having to take into consideration the
7547 order in which the local copies are updated by the code,
7548 among other things.)
7550 To test this hypothesis, try compiling your program with
7551 the @option{-fargument-alias} option, which causes the
7552 compiler to revert to assumptions essentially the same as
7553 made by versions of @command{g77} prior to 0.5.20.
7555 If the program works using this option, that strongly suggests
7556 that the bug is in your program.
7557 Finding and fixing the bug(s) should result in a program that
7558 is more standard-conforming and that can be compiled by @command{g77}
7559 in a way that results in a faster executable.
7561 (You might want to try compiling with @option{-fargument-noalias},
7562 a kind of half-way point, to see if the problem is limited to
7563 aliasing between dummy arguments and @code{COMMON} variables---this
7564 option assumes that such aliasing is not done, while still allowing
7565 aliasing among dummy arguments.)
7567 An example of aliasing that is invalid according to the standards
7568 is shown in the following program, which might @emph{not} produce
7569 the expected results when executed:
7577 SUBROUTINE FOO(J, K)
7584 The above program attempts to use the temporary aliasing of the
7585 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
7586 pathological behavior---the simultaneous changing of the values
7587 of @emph{both} @samp{J} and @samp{K} when either one of them
7590 The programmer likely expects the program to print these values:
7597 However, since the program is not standard-conforming, an
7598 implementation's behavior when running it is undefined, because
7599 subroutine @samp{FOO} modifies at least one of the arguments,
7600 and they are aliased with each other.
7601 (Even if one of the assignment statements was deleted, the
7602 program would still violate these rules.
7603 This kind of on-the-fly aliasing is permitted by the standard
7604 only when none of the aliased items are defined, or written,
7605 while the aliasing is in effect.)
7607 As a practical example, an optimizing compiler might schedule
7608 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
7609 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
7610 resulting in the following output:
7617 Essentially, compilers are promised (by the standard and, therefore,
7618 by programmers who write code they claim to be standard-conforming)
7619 that if they cannot detect aliasing via static analysis of a single
7620 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
7621 such aliasing exists.
7622 In such cases, compilers are free to assume that an assignment to
7623 one variable will not change the value of another variable, allowing
7624 it to avoid generating code to re-read the value of the other
7625 variable, to re-schedule reads and writes, and so on, to produce
7626 a faster executable.
7628 The same promise holds true for arrays (as seen by the called
7629 procedure)---an element of one dummy array cannot be aliased
7630 with, or overlap, any element of another dummy array or be
7631 in a @code{COMMON} area known to the procedure.
7633 (These restrictions apply only when the procedure defines, or
7634 writes to, one of the aliased variables or arrays.)
7636 Unfortunately, there is no way to find @emph{all} possible cases of
7637 violations of the prohibitions against aliasing in Fortran code.
7638 Static analysis is certainly imperfect, as is run-time analysis,
7639 since neither can catch all violations.
7640 (Static analysis can catch all likely violations, and some that
7641 might never actually happen, while run-time analysis can catch
7642 only those violations that actually happen during a particular run.
7643 Neither approach can cope with programs mixing Fortran code with
7644 routines written in other languages, however.)
7646 Currently, @command{g77} provides neither static nor run-time facilities
7647 to detect any cases of this problem, although other products might.
7648 Run-time facilities are more likely to be offered by future
7649 versions of @command{g77}, though patches improving @command{g77} so that
7650 it provides either form of detection are welcome.
7652 @node Output Assumed To Flush
7653 @subsection Output Assumed To Flush
7654 @cindex ALWAYS_FLUSH
7655 @cindex synchronous write errors
7657 @cindex flushing output
7659 @cindex I/O, flushing
7660 @cindex output, flushing
7661 @cindex writes, flushing
7663 @cindex network file system
7665 For several versions prior to 0.5.20, @command{g77} configured its
7666 version of the @code{libf2c} run-time library so that one of
7667 its configuration macros, @code{ALWAYS_FLUSH}, was defined.
7669 This was done as a result of a belief that many programs expected
7670 output to be flushed to the operating system (under UNIX, via
7671 the @code{fflush()} library call) with the result that errors,
7672 such as disk full, would be immediately flagged via the
7673 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
7675 Because of the adverse effects this approach had on the performance
7676 of many programs, @command{g77} no longer configures @code{libf2c}
7677 (now named @code{libg2c} in its @command{g77} incarnation)
7678 to always flush output.
7680 If your program depends on this behavior, either insert the
7681 appropriate @samp{CALL FLUSH} statements, or modify the sources
7682 to the @code{libg2c}, rebuild and reinstall @command{g77}, and
7683 relink your programs with the modified library.
7685 (Ideally, @code{libg2c} would offer the choice at run-time, so
7686 that a compile-time option to @command{g77} or @command{f2c} could
7687 result in generating the appropriate calls to flushing or
7688 non-flushing library routines.)
7690 Some Fortran programs require output
7691 (writes) to be flushed to the operating system (under UNIX,
7692 via the @code{fflush()} library call) so that errors,
7693 such as disk full, are immediately flagged via the relevant
7694 @code{ERR=} and @code{IOSTAT=} mechanism, instead of such
7695 errors being flagged later as subsequent writes occur, forcing
7696 the previously written data to disk, or when the file is
7699 Essentially, the difference can be viewed as synchronous error
7700 reporting (immediate flagging of errors during writes) versus
7701 asynchronous, or, more precisely, buffered error reporting
7702 (detection of errors might be delayed).
7704 @code{libg2c} supports flagging write errors immediately when
7705 it is built with the @code{ALWAYS_FLUSH} macro defined.
7706 This results in a @code{libg2c} that runs slower, sometimes
7707 quite a bit slower, under certain circumstances---for example,
7708 accessing files via the networked file system NFS---but the
7709 effect can be more reliable, robust file I/O.
7711 If you know that Fortran programs requiring this level of precision
7712 of error reporting are to be compiled using the
7713 version of @command{g77} you are building, you might wish to
7714 modify the @command{g77} source tree so that the version of
7715 @code{libg2c} is built with the @code{ALWAYS_FLUSH} macro
7716 defined, enabling this behavior.
7718 To do this, find this line in @file{@value{path-libf2c}/f2c.h} in
7719 your @command{g77} source tree:
7722 /* #define ALWAYS_FLUSH */
7725 Remove the leading @samp{/*@w{ }},
7726 so the line begins with @samp{#define},
7727 and the trailing @samp{@w{ }*/}.
7729 Then build or rebuild @command{g77} as appropriate.
7731 @node Large File Unit Numbers
7732 @subsection Large File Unit Numbers
7734 @cindex unit numbers
7735 @cindex maximum unit number
7736 @cindex illegal unit number
7737 @cindex increasing maximum unit number
7739 If your program crashes at run time with a message including
7740 the text @samp{illegal unit number}, that probably is
7741 a message from the run-time library, @code{libg2c}.
7743 The message means that your program has attempted to use a
7744 file unit number that is out of the range accepted by
7746 Normally, this range is 0 through 99, and the high end
7747 of the range is controlled by a @code{libg2c} source-file
7748 macro named @code{MXUNIT}.
7750 If you can easily change your program to use unit numbers
7751 in the range 0 through 99, you should do so.
7753 As distributed, whether as part of @command{f2c} or @command{g77},
7754 @code{libf2c} accepts file unit numbers only in the range
7756 For example, a statement such as @samp{WRITE (UNIT=100)} causes
7757 a run-time crash in @code{libf2c}, because the unit number,
7758 100, is out of range.
7760 If you know that Fortran programs at your installation require
7761 the use of unit numbers higher than 99, you can change the
7762 value of the @code{MXUNIT} macro, which represents the maximum unit
7763 number, to an appropriately higher value.
7765 To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your
7766 @command{g77} source tree, changing the following line:
7772 Change the line so that the value of @code{MXUNIT} is defined to be
7773 at least one @emph{greater} than the maximum unit number used by
7774 the Fortran programs on your system.
7776 (For example, a program that does @samp{WRITE (UNIT=255)} would require
7777 @code{MXUNIT} set to at least 256 to avoid crashing.)
7779 Then build or rebuild @command{g77} as appropriate.
7781 @emph{Note:} Changing this macro has @emph{no} effect on other limits
7782 your system might place on the number of files open at the same time.
7783 That is, the macro might allow a program to do @samp{WRITE (UNIT=100)},
7784 but the library and operating system underlying @code{libf2c} might
7785 disallow it if many other files have already been opened (via @code{OPEN} or
7786 implicitly via @code{READ}, @code{WRITE}, and so on).
7787 Information on how to increase these other limits should be found
7788 in your system's documentation.
7790 @node Floating-point precision
7791 @subsection Floating-point precision
7793 @cindex IEEE 754 conformance
7794 @cindex conformance, IEEE 754
7795 @cindex floating-point, precision
7796 @cindex ix86 floating-point
7797 @cindex x86 floating-point
7798 If your program depends on exact IEEE 754 floating-point handling it may
7799 help on some systems---specifically x86 or m68k hardware---to use
7800 the @option{-ffloat-store} option or to reset the precision flag on the
7801 floating-point unit.
7802 @xref{Optimize Options}.
7804 However, it might be better simply to put the FPU into double precision
7805 mode and not take the performance hit of @option{-ffloat-store}. On x86
7806 and m68k GNU systems you can do this with a technique similar to that
7807 for turning on floating-point exceptions
7808 (@pxref{Floating-point Exception Handling}).
7809 The control word could be set to double precision by some code like this
7812 #include <fpu_control.h>
7814 fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
7818 (It is not clear whether this has any effect on the operation of the GNU
7819 maths library, but we have no evidence of it causing trouble.)
7821 Some targets (such as the Alpha) may need special options for full IEEE
7823 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and Porting GNU CC}.
7825 @node Inconsistent Calling Sequences
7826 @subsection Inconsistent Calling Sequences
7829 @cindex floating-point, errors
7830 @cindex ix86 FPU stack
7831 @cindex x86 FPU stack
7832 Code containing inconsistent calling sequences in the same file is
7833 normally rejected---see @ref{GLOBALS}.
7834 (Use, say, @command{ftnchek} to ensure
7835 consistency across source files.
7836 @xref{f2c Skeletons and Prototypes,,
7837 Generating Skeletons and Prototypes with @command{f2c}}.)
7839 Mysterious errors, which may appear to be code generation problems, can
7840 appear specifically on the x86 architecture with some such
7841 inconsistencies. On x86 hardware, floating-point return values of
7842 functions are placed on the floating-point unit's register stack, not
7843 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
7844 @code{FUNCTION} as some other sort of procedure, or vice versa,
7845 scrambles the floating-point stack. This may break unrelated code
7846 executed later. Similarly if, say, external C routines are written
7849 @node Overly Convenient Options
7850 @section Overly Convenient Command-line Options
7851 @cindex overly convenient options
7852 @cindex options, overly convenient
7854 These options should be used only as a quick-and-dirty way to determine
7855 how well your program will run under different compilation models
7856 without having to change the source.
7857 Some are more problematic
7858 than others, depending on how portable and maintainable you want the
7859 program to be (and, of course, whether you are allowed to change it
7862 You should not continue to use these command-line options to compile
7863 a given program, but rather should make changes to the source code:
7866 @cindex -finit-local-zero option
7867 @cindex options, -finit-local-zero
7868 @item -finit-local-zero
7869 (This option specifies that any uninitialized local variables
7870 and arrays have default initialization to binary zeros.)
7872 Many other compilers do this automatically, which means lots of
7873 Fortran code developed with those compilers depends on it.
7875 It is safer (and probably
7876 would produce a faster program) to find the variables and arrays that
7877 need such initialization and provide it explicitly via @code{DATA}, so that
7878 @option{-finit-local-zero} is not needed.
7880 Consider using @option{-Wuninitialized} (which requires @option{-O}) to
7881 find likely candidates, but
7882 do not specify @option{-finit-local-zero} or @option{-fno-automatic},
7883 or this technique won't work.
7885 @cindex -fno-automatic option
7886 @cindex options, -fno-automatic
7887 @item -fno-automatic
7888 (This option specifies that all local variables and arrays
7889 are to be treated as if they were named in @code{SAVE} statements.)
7891 Many other compilers do this automatically, which means lots of
7892 Fortran code developed with those compilers depends on it.
7894 The effect of this is that all non-automatic variables and arrays
7895 are made static, that is, not placed on the stack or in heap storage.
7896 This might cause a buggy program to appear to work better.
7897 If so, rather than relying on this command-line option (and hoping all
7898 compilers provide the equivalent one), add @code{SAVE}
7899 statements to some or all program unit sources, as appropriate.
7900 Consider using @option{-Wuninitialized} (which requires @option{-O})
7901 to find likely candidates, but
7902 do not specify @option{-finit-local-zero} or @option{-fno-automatic},
7903 or this technique won't work.
7905 The default is @option{-fautomatic}, which tells @command{g77} to try
7906 and put variables and arrays on the stack (or in fast registers)
7907 where possible and reasonable.
7908 This tends to make programs faster.
7910 @cindex automatic arrays
7911 @cindex arrays, automatic
7912 @emph{Note:} Automatic variables and arrays are not affected
7914 These are variables and arrays that are @emph{necessarily} automatic,
7915 either due to explicit statements, or due to the way they are
7917 Examples include local variables and arrays not given the
7918 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
7919 and local arrays declared with non-constant bounds (automatic
7921 Currently, @command{g77} supports only automatic arrays, not
7922 @code{RECURSIVE} procedures or other means of explicitly
7923 specifying that variables or arrays are automatic.
7925 @cindex -f@var{group}-intrinsics-hide option
7926 @cindex options, -f@var{group}-intrinsics-hide
7927 @item -f@var{group}-intrinsics-hide
7928 Change the source code to use @code{EXTERNAL} for any external procedure
7929 that might be the name of an intrinsic.
7930 It is easy to find these using @option{-f@var{group}-intrinsics-disable}.
7933 @node Faster Programs
7934 @section Faster Programs
7935 @cindex speed, of programs
7936 @cindex programs, speeding up
7938 Aside from the usual @command{gcc} options, such as @option{-O},
7939 @option{-ffast-math}, and so on, consider trying some of the
7940 following approaches to speed up your program (once you get
7945 * Prefer Automatic Uninitialized Variables::
7946 * Avoid f2c Compatibility::
7947 * Use Submodel Options::
7951 @subsection Aligned Data
7953 @cindex data, aligned
7954 @cindex stack, aligned
7955 @cindex aligned data
7956 @cindex aligned stack
7957 @cindex Pentium optimizations
7958 @cindex optimization, for Pentium
7960 On some systems, such as those with Pentium Pro CPUs, programs
7961 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
7962 might run much slower
7963 than possible due to the compiler not aligning these 64-bit
7964 values to 64-bit boundaries in memory.
7965 (The effect also is present, though
7966 to a lesser extent, on the 586 (Pentium) architecture.)
7968 The Intel x86 architecture generally ensures that these programs will
7969 work on all its implementations,
7970 but particular implementations (such as Pentium Pro)
7971 perform better with more strict alignment.
7972 (Such behavior isn't unique to the Intel x86 architecture.)
7973 Other architectures might @emph{demand} 64-bit alignment
7976 There are a variety of approaches to use to address this problem:
7980 @cindex @code{COMMON} layout
7981 @cindex layout of @code{COMMON} blocks
7982 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
7983 that the variables and arrays with the widest alignment
7984 guidelines come first.
7986 For example, on most systems, this would mean placing
7987 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
7988 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
7989 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
7990 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
7991 and @code{INTEGER(KIND=3)} entities.
7993 The reason to use such placement is it makes it more likely
7994 that your data will be aligned properly, without requiring
7995 you to do detailed analysis of each aggregate (@code{COMMON}
7996 and @code{EQUIVALENCE}) area.
7998 Specifically, on systems where the above guidelines are
7999 appropriate, placing @code{CHARACTER} entities before
8000 @code{REAL(KIND=2)} entities can work just as well,
8001 but only if the number of bytes occupied by the @code{CHARACTER}
8002 entities is divisible by the recommended alignment for
8003 @code{REAL(KIND=2)}.
8005 By ordering the placement of entities in aggregate
8006 areas according to the simple guidelines above, you
8007 avoid having to carefully count the number of bytes
8008 occupied by each entity to determine whether the
8009 actual alignment of each subsequent entity meets the
8010 alignment guidelines for the type of that entity.
8012 If you don't ensure correct alignment of @code{COMMON} elements, the
8013 compiler may be forced by some systems to violate the Fortran semantics by
8014 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
8015 If the unfortunate practice is employed of overlaying different types of
8016 data in the @code{COMMON} block, the different variants
8017 of this block may become misaligned with respect to each other.
8018 Even if your platform doesn't require strict alignment,
8019 @code{COMMON} should be laid out as above for portability.
8020 (Unfortunately the FORTRAN 77 standard didn't anticipate this
8021 possible requirement, which is compiler-independent on a given platform.)
8024 @cindex -malign-double option
8025 @cindex options, -malign-double
8026 Use the (x86-specific) @option{-malign-double} option when compiling
8027 programs for the Pentium and Pentium Pro architectures (called 586
8028 and 686 in the @command{gcc} configuration subsystem).
8029 The warning about this in the @command{gcc} manual isn't
8030 generally relevant to Fortran,
8031 but using it will force @code{COMMON} to be padded if necessary to align
8032 @code{DOUBLE PRECISION} data.
8034 When @code{DOUBLE PRECISION} data is forcibly aligned
8035 in @code{COMMON} by @command{g77} due to specifying @option{-malign-double},
8036 @command{g77} issues a warning about the need to
8039 In this case, each and every program unit that uses
8040 the same @code{COMMON} area
8041 must specify the same layout of variables and their types
8043 and be compiled with @option{-malign-double} as well.
8044 @command{g77} will issue warnings in each case,
8045 but as long as every program unit using that area
8046 is compiled with the same warnings,
8047 the resulting object files should work when linked together
8048 unless the program makes additional assumptions about
8049 @code{COMMON} area layouts that are outside the scope
8050 of the FORTRAN 77 standard,
8051 or uses @code{EQUIVALENCE} or different layouts
8052 in ways that assume no padding is ever inserted by the compiler.
8055 Ensure that @file{crt0.o} or @file{crt1.o}
8056 on your system guarantees a 64-bit
8057 aligned stack for @code{main()}.
8058 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
8059 but we don't know of any other x86 setups where it will be right.
8060 Read your system's documentation to determine if
8061 it is appropriate to upgrade to a more recent version
8062 to obtain the optimal alignment.
8065 Progress is being made on making this work
8066 ``out of the box'' on future versions of @command{g77},
8067 @command{gcc}, and some of the relevant operating systems
8068 (such as GNU/Linux).
8070 @cindex alignment testing
8071 @cindex testing alignment
8072 A package that tests the degree to which a Fortran compiler
8073 (such as @command{g77})
8074 aligns 64-bit floating-point variables and arrays
8075 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
8077 @node Prefer Automatic Uninitialized Variables
8078 @subsection Prefer Automatic Uninitialized Variables
8080 If you're using @option{-fno-automatic} already, you probably
8081 should change your code to allow compilation with @option{-fautomatic}
8082 (the default), to allow the program to run faster.
8084 Similarly, you should be able to use @option{-fno-init-local-zero}
8085 (the default) instead of @option{-finit-local-zero}.
8086 This is because it is rare that every variable affected by these
8087 options in a given program actually needs to
8090 For example, @option{-fno-automatic}, which effectively @code{SAVE}s
8091 every local non-automatic variable and array, affects even things like
8093 variables, which rarely need to be @code{SAVE}d, and this often reduces
8094 run-time performances.
8095 Similarly, @option{-fno-init-local-zero} forces such
8096 variables to be initialized to zero---when @code{SAVE}d (such as when
8097 @option{-fno-automatic}), this by itself generally affects only
8098 startup time for a program, but when not @code{SAVE}d,
8099 it can slow down the procedure every time it is called.
8101 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
8102 for information on the @option{-fno-automatic} and
8103 @option{-finit-local-zero} options and how to convert
8104 their use into selective changes in your own code.
8106 @node Avoid f2c Compatibility
8107 @subsection Avoid f2c Compatibility
8108 @cindex -fno-f2c option
8109 @cindex options, -fno-f2c
8110 @cindex @command{f2c} compatibility
8111 @cindex compatibility, @command{f2c}
8113 If you aren't linking with any code compiled using
8114 @command{f2c}, try using the @option{-fno-f2c} option when
8115 compiling @emph{all} the code in your program.
8116 (Note that @code{libf2c} is @emph{not} an example of code
8117 that is compiled using @command{f2c}---it is compiled by a C
8118 compiler, typically @command{gcc}.)
8120 @node Use Submodel Options
8121 @subsection Use Submodel Options
8124 Using an appropriate @option{-m} option to generate specific code for your
8125 CPU may be worthwhile, though it may mean the executable won't run on
8126 other versions of the CPU that don't support the same instruction set.
8127 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
8128 Porting GNU CC}. For instance on an x86 system the compiler might have
8129 been built---as shown by @samp{g77 -v}---for the target
8130 @samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
8131 generate code best optimized for a Pentium you could use the option
8132 @option{-march=pentium}.
8134 For recent CPUs that don't have explicit support in the released version
8135 of @command{gcc}, it @emph{might} still be possible to get improvements
8136 with certain @option{-m} options.
8138 @option{-fomit-frame-pointer} can help performance on x86 systems and
8139 others. It will, however, inhibit debugging on the systems on which it
8140 is not turned on anyway by @option{-O}.
8143 @chapter Known Causes of Trouble with GNU Fortran
8145 @cindex installation trouble
8146 @cindex known causes of trouble
8148 This section describes known problems that affect users of GNU Fortran.
8149 Most of these are not GNU Fortran bugs per se---if they were, we would
8151 But the result for a user might be like the result of a bug.
8153 Some of these problems are due to bugs in other software, some are
8154 missing features that are too much work to add, and some are places
8155 where people's opinions differ as to what is best.
8157 To find out about major bugs discovered in the current release and
8158 possible workarounds for them, see
8159 @uref{ftp://alpha.gnu.org/g77.plan}.
8161 (Note that some of this portion of the manual is lifted
8162 directly from the @command{gcc} manual, with minor modifications
8163 to tailor it to users of @command{g77}.
8164 Anytime a bug seems to have more to do with the @command{gcc}
8165 portion of @command{g77}, see
8166 @ref{Trouble,,Known Causes of Trouble with GNU CC,
8167 gcc,Using and Porting GNU CC}.)
8170 * But-bugs:: Bugs really in other programs or elsewhere.
8171 * Known Bugs:: Bugs known to be in this version of @command{g77}.
8172 * Missing Features:: Features we already know we want to add later.
8173 * Disappointments:: Regrettable things we can't change.
8174 * Non-bugs:: Things we think are right, but some others disagree.
8175 * Warnings and Errors:: Which problems in your code get warnings,
8176 and which get errors.
8180 @section Bugs Not In GNU Fortran
8183 These are bugs to which the maintainers often have to reply,
8184 ``but that isn't a bug in @command{g77}@dots{}''.
8185 Some of these already are fixed in new versions of other
8186 software; some still need to be fixed; some are problems
8187 with how @command{g77} is installed or is being used;
8188 some are the result of bad hardware that causes software
8189 to misbehave in sometimes bizarre ways;
8190 some just cannot be addressed at this time until more
8191 is known about the problem.
8193 Please don't re-report these bugs to the @command{g77} maintainers---if
8194 you must remind someone how important it is to you that the problem
8195 be fixed, talk to the people responsible for the other products
8196 identified below, but preferably only after you've tried the
8197 latest versions of those products.
8198 The @command{g77} maintainers have their hands full working on
8199 just fixing and improving @command{g77}, without serving as a
8200 clearinghouse for all bugs that happen to affect @command{g77}
8203 @xref{Collected Fortran Wisdom}, for information on behavior
8204 of Fortran programs, and the programs that compile them, that
8205 might be @emph{thought} to indicate bugs.
8208 * Signal 11 and Friends:: Strange behavior by any software.
8209 * Cannot Link Fortran Programs:: Unresolved references.
8210 * Large Common Blocks:: Problems on older GNU/Linux systems.
8211 * Debugger Problems:: When the debugger crashes.
8212 * NeXTStep Problems:: Misbehaving executables.
8213 * Stack Overflow:: More misbehaving executables.
8214 * Nothing Happens:: Less behaving executables.
8215 * Strange Behavior at Run Time:: Executables misbehaving due to
8216 bugs in your program.
8217 * Floating-point Errors:: The results look wrong, but@dots{}.
8220 @node Signal 11 and Friends
8221 @subsection Signal 11 and Friends
8223 @cindex hardware errors
8225 A whole variety of strange behaviors can occur when the
8226 software, or the way you are using the software,
8227 stresses the hardware in a way that triggers hardware bugs.
8228 This might seem hard to believe, but it happens frequently
8229 enough that there exist documents explaining in detail
8230 what the various causes of the problems are, what
8231 typical symptoms look like, and so on.
8233 Generally these problems are referred to in this document
8234 as ``signal 11'' crashes, because the Linux kernel, running
8235 on the most popular hardware (the Intel x86 line), often
8236 stresses the hardware more than other popular operating
8238 When hardware problems do occur under GNU/Linux on x86
8239 systems, these often manifest themselves as ``signal 11''
8240 problems, as illustrated by the following diagnostic:
8243 sh# @kbd{g77 myprog.f}
8244 gcc: Internal compiler error: program f771 got fatal signal 11
8248 It is @emph{very} important to remember that the above
8249 message is @emph{not} the only one that indicates a
8250 hardware problem, nor does it always indicate a hardware
8253 In particular, on systems other than those running the Linux
8254 kernel, the message might appear somewhat or very different,
8255 as it will if the error manifests itself while running a
8256 program other than the @command{g77} compiler.
8258 it will appear somewhat different when running your program,
8259 when running Emacs, and so on.
8261 How to cope with such problems is well beyond the scope
8264 However, users of Linux-based systems (such as GNU/Linux)
8265 should review @uref{http://www.bitwizard.nl/sig11/}, a source
8266 of detailed information on diagnosing hardware problems,
8267 by recognizing their common symptoms.
8269 Users of other operating systems and hardware might
8270 find this reference useful as well.
8271 If you know of similar material for another hardware/software
8272 combination, please let us know so we can consider including
8273 a reference to it in future versions of this manual.
8275 @node Cannot Link Fortran Programs
8276 @subsection Cannot Link Fortran Programs
8277 @cindex unresolved reference (various)
8278 @cindex linking error for user code
8280 @cindex @command{ld}, error linking user code
8281 @cindex @command{ld}, can't find strange names
8282 On some systems, perhaps just those with out-of-date (shared?)
8283 libraries, unresolved-reference errors happen when linking @command{g77}-compiled
8284 programs (which should be done using @command{g77}).
8286 If this happens to you, try appending @option{-lc} to the command you
8287 use to link the program, e.g. @samp{g77 foo.f -lc}.
8288 @command{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
8289 but it cannot also specify @option{-lc} because not all systems have a
8290 file named @file{libc.a}.
8292 It is unclear at this point whether there are legitimately installed
8293 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
8296 @cindex undefined reference (_main)
8297 @cindex linking error, user code
8298 @cindex @command{ld}, error linking user code
8300 @cindex @command{ld}, can't find @samp{_main}
8301 If your program doesn't link due to unresolved references to names
8302 like @samp{_main}, make sure you're using the @command{g77} command to do the
8303 link, since this command ensures that the necessary libraries are
8304 loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc}
8305 command to do the actual link.
8306 (Use the @option{-v} option to discover
8307 more about what actually happens when you use the @command{g77} and @command{gcc}
8310 Also, try specifying @option{-lc} as the last item on the @command{g77}
8311 command line, in case that helps.
8313 @node Large Common Blocks
8314 @subsection Large Common Blocks
8315 @cindex common blocks, large
8316 @cindex large common blocks
8317 @cindex linking, errors
8318 @cindex @command{ld}, errors
8319 @cindex errors, linker
8320 On some older GNU/Linux systems, programs with common blocks larger
8321 than 16MB cannot be linked without some kind of error
8322 message being produced.
8324 This is a bug in older versions of @command{ld}, fixed in
8325 more recent versions of @code{binutils}, such as version 2.6.
8327 @node Debugger Problems
8328 @subsection Debugger Problems
8329 @cindex @command{gdb}, support
8330 @cindex support, @command{gdb}
8331 There are some known problems when using @command{gdb} on code
8332 compiled by @command{g77}.
8333 Inadequate investigation as of the release of 0.5.16 results in not
8334 knowing which products are the culprit, but @file{gdb-4.14} definitely
8335 crashes when, for example, an attempt is made to print the contents
8336 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
8337 machines, plus some others.
8338 Attempts to access assumed-size arrays are
8339 also known to crash recent versions of @command{gdb}.
8340 (@command{gdb}'s Fortran support was done for a different compiler
8341 and isn't properly compatible with @command{g77}.)
8343 @node NeXTStep Problems
8344 @subsection NeXTStep Problems
8345 @cindex NeXTStep problems
8347 @cindex segmentation violation
8348 Developers of Fortran code on NeXTStep (all architectures) have to
8349 watch out for the following problem when writing programs with
8350 large, statically allocated (i.e. non-stack based) data structures
8351 (common blocks, saved arrays).
8353 Due to the way the native loader (@file{/bin/ld}) lays out
8354 data structures in virtual memory, it is very easy to create an
8355 executable wherein the @samp{__DATA} segment overlaps (has addresses in
8356 common) with the @samp{UNIX STACK} segment.
8358 This leads to all sorts of trouble, from the executable simply not
8359 executing, to bus errors.
8360 The NeXTStep command line tool @command{ebadexec} points to
8361 the problem as follows:
8364 % @kbd{/bin/ebadexec a.out}
8365 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
8366 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
8367 STACK segment (truncated address = 0x400000 rounded size =
8368 0x3c00000) of executable file: a.out
8371 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
8374 This can be cured by assigning the @samp{__DATA} segment
8375 (virtual) addresses beyond the stack segment.
8377 estimate for this is from address 6000000 (hexadecimal) onwards---this
8378 has always worked for me [Toon Moene]:
8381 % @kbd{g77 -segaddr __DATA 6000000 test.f}
8382 % @kbd{ebadexec a.out}
8383 ebadexec: file: a.out appears to be executable
8387 Browsing through @file{@value{path-g77}/Makefile.in},
8388 you will find that the @code{f771} program itself also has to be
8389 linked with these flags---it has large statically allocated
8391 (Version 0.5.18 reduces this somewhat, but probably
8394 (The above item was contributed by Toon Moene
8395 (@email{toon@@moene.indiv.nluug.nl}).)
8397 @node Stack Overflow
8398 @subsection Stack Overflow
8399 @cindex stack, overflow
8400 @cindex segmentation violation
8401 @command{g77} code might fail at runtime (probably with a ``segmentation
8402 violation'') due to overflowing the stack.
8403 This happens most often on systems with an environment
8404 that provides substantially more heap space (for use
8405 when arbitrarily allocating and freeing memory) than stack
8408 Often this can be cured by
8409 increasing or removing your shell's limit on stack usage, typically
8410 using @kbd{limit stacksize} (in @command{csh} and derivatives) or
8411 @kbd{ulimit -s} (in @command{sh} and derivatives).
8413 Increasing the allowed stack size might, however, require
8414 changing some operating system or system configuration parameters.
8416 You might be able to work around the problem by compiling with the
8417 @option{-fno-automatic} option to reduce stack usage, probably at the
8420 @command{g77}, on most machines, puts many variables and arrays on the stack
8421 where possible, and can be configured (by changing
8422 @code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force
8423 smaller-sized entities into static storage (saving
8424 on stack space) or permit larger-sized entities to be put on the
8425 stack (which can improve run-time performance, as it presents
8426 more opportunities for the GBE to optimize the generated code).
8428 @emph{Note:} Putting more variables and arrays on the stack
8429 might cause problems due to system-dependent limits on stack size.
8430 Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no
8431 effect on automatic variables and arrays.
8432 @xref{But-bugs}, for more information.
8433 @emph{Note:} While @code{libg2c} places a limit on the range
8434 of Fortran file-unit numbers, the underlying library and operating
8435 system might impose different kinds of limits.
8436 For example, some systems limit the number of files simultaneously
8437 open by a running program.
8438 Information on how to increase these limits should be found
8439 in your system's documentation.
8441 @cindex automatic arrays
8442 @cindex arrays, automatic
8443 However, if your program uses large automatic arrays
8444 (for example, has declarations like @samp{REAL A(N)} where
8445 @samp{A} is a local array and @samp{N} is a dummy or
8446 @code{COMMON} variable that can have a large value),
8447 neither use of @option{-fno-automatic},
8448 nor changing the cut-off point for @command{g77} for using the stack,
8449 will solve the problem by changing the placement of these
8450 large arrays, as they are @emph{necessarily} automatic.
8452 @command{g77} currently provides no means to specify that
8453 automatic arrays are to be allocated on the heap instead
8455 So, other than increasing the stack size, your best bet is to
8456 change your source code to avoid large automatic arrays.
8457 Methods for doing this currently are outside the scope of
8460 (@emph{Note:} If your system puts stack and heap space in the
8461 same memory area, such that they are effectively combined, then
8462 a stack overflow probably indicates a program that is either
8463 simply too large for the system, or buggy.)
8465 @node Nothing Happens
8466 @subsection Nothing Happens
8467 @cindex nothing happens
8468 @cindex naming programs
8469 @cindex @command{test} programs
8470 @cindex programs, @command{test}
8471 It is occasionally reported that a ``simple'' program,
8472 such as a ``Hello, World!'' program, does nothing when
8473 it is run, even though the compiler reported no errors,
8474 despite the program containing nothing other than a
8475 simple @code{PRINT} statement.
8477 This most often happens because the program has been
8478 compiled and linked on a UNIX system and named @command{test},
8479 though other names can lead to similarly unexpected
8480 run-time behavior on various systems.
8482 Essentially this problem boils down to giving
8483 your program a name that is already known to
8484 the shell you are using to identify some other program,
8485 which the shell continues to execute instead of your
8486 program when you invoke it via, for example:
8493 Under UNIX and many other system, a simple command name
8494 invokes a searching mechanism that might well not choose
8495 the program located in the current working directory if
8496 there is another alternative (such as the @command{test}
8497 command commonly installed on UNIX systems).
8499 The reliable way to invoke a program you just linked in
8500 the current directory under UNIX is to specify it using
8501 an explicit pathname, as in:
8509 Users who encounter this problem should take the time to
8510 read up on how their shell searches for commands, how to
8511 set their search path, and so on.
8512 The relevant UNIX commands to learn about include
8513 @command{man}, @command{info} (on GNU systems), @command{setenv} (or
8514 @command{set} and @command{env}), @command{which}, and @command{find}.
8516 @node Strange Behavior at Run Time
8517 @subsection Strange Behavior at Run Time
8518 @cindex segmentation violation
8520 @cindex overwritten data
8521 @cindex data, overwritten
8522 @command{g77} code might fail at runtime with ``segmentation violation'',
8523 ``bus error'', or even something as subtle as a procedure call
8524 overwriting a variable or array element that it is not supposed
8527 These can be symptoms of a wide variety of actual bugs that
8528 occurred earlier during the program's run, but manifested
8529 themselves as @emph{visible} problems some time later.
8531 Overflowing the bounds of an array---usually by writing beyond
8532 the end of it---is one of two kinds of bug that often occurs
8534 (Compile your code with the @option{-fbounds-check} option
8535 to catch many of these kinds of errors at program run time.)
8537 The other kind of bug is a mismatch between the actual arguments
8538 passed to a procedure and the dummy arguments as declared by that
8541 Both of these kinds of bugs, and some others as well, can be
8542 difficult to track down, because the bug can change its behavior,
8543 or even appear to not occur, when using a debugger.
8545 That is, these bugs can be quite sensitive to data, including
8546 data representing the placement of other data in memory (that is,
8547 pointers, such as the placement of stack frames in memory).
8549 @command{g77} now offers the
8550 ability to catch and report some of these problems at compile, link, or
8551 run time, such as by generating code to detect references to
8552 beyond the bounds of most arrays (except assumed-size arrays),
8553 and checking for agreement between calling and called procedures.
8554 Future improvements are likely to be made in the procedure-mismatch area,
8557 In the meantime, finding and fixing the programming
8558 bugs that lead to these behaviors is, ultimately, the user's
8559 responsibility, as difficult as that task can sometimes be.
8561 @cindex infinite spaces printed
8562 @cindex space, endless printing of
8563 @cindex libc, non-ANSI or non-default
8565 @cindex linking against non-standard library
8567 One runtime problem that has been observed might have a simple solution.
8568 If a formatted @code{WRITE} produces an endless stream of spaces, check
8569 that your program is linked against the correct version of the C library.
8570 The configuration process takes care to account for your
8571 system's normal @file{libc} not being ANSI-standard, which will
8572 otherwise cause this behaviour.
8573 If your system's default library is
8574 ANSI-standard and you subsequently link against a non-ANSI one, there
8575 might be problems such as this one.
8577 Specifically, on Solaris2 systems,
8578 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
8580 @node Floating-point Errors
8581 @subsection Floating-point Errors
8582 @cindex floating-point errors
8583 @cindex rounding errors
8584 @cindex inconsistent floating-point results
8585 @cindex results, inconsistent
8586 Some programs appear to produce inconsistent floating-point
8587 results compiled by @command{g77} versus by other compilers.
8589 Often the reason for this behavior is the fact that floating-point
8590 values are represented on almost all Fortran systems by
8591 @emph{approximations}, and these approximations are inexact
8592 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
8593 0.7, 0.8, 0.9, 1.1, and so on.
8594 Most Fortran systems, including all current ports of @command{g77},
8595 use binary arithmetic to represent these approximations.
8597 Therefore, the exact value of any floating-point approximation
8598 as manipulated by @command{g77}-compiled code is representable by
8599 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
8600 so on (just keep dividing by two) through the precision of the
8601 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
8602 @code{REAL(KIND=2)}), then multiplying the sum by a integral
8603 power of two (in Fortran, by @samp{2**N}) that typically is between
8604 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
8605 @code{REAL(KIND=2)}, then multiplying by -1 if the number
8608 So, a value like 0.2 is exactly represented in decimal---since
8609 it is a fraction, @samp{2/10}, with a denominator that is compatible
8610 with the base of the number system (base 10).
8611 However, @samp{2/10} cannot be represented by any finite number
8612 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
8613 be exactly represented in binary notation.
8615 (On the other hand, decimal notation can represent any binary
8616 number in a finite number of digits.
8617 Decimal notation cannot do so with ternary, or base-3,
8618 notation, which would represent floating-point numbers as
8619 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
8620 After all, no finite number of decimal digits can exactly
8621 represent @samp{1/3}.
8622 Fortunately, few systems use ternary notation.)
8624 Moreover, differences in the way run-time I/O libraries convert
8625 between these approximations and the decimal representation often
8626 used by programmers and the programs they write can result in
8627 apparent differences between results that do not actually exist,
8628 or exist to such a small degree that they usually are not worth
8631 For example, consider the following program:
8638 When compiled by @command{g77}, the above program might output
8639 @samp{0.20000003}, while another compiler might produce a
8640 executable that outputs @samp{0.2}.
8642 This particular difference is due to the fact that, currently,
8643 conversion of floating-point values by the @code{libg2c} library,
8644 used by @command{g77}, handles only double-precision values.
8646 Since @samp{0.2} in the program is a single-precision value, it
8647 is converted to double precision (still in binary notation)
8648 before being converted back to decimal.
8649 The conversion to binary appends @emph{binary} zero digits to the
8650 original value---which, again, is an inexact approximation of
8651 0.2---resulting in an approximation that is much less exact
8652 than is connoted by the use of double precision.
8654 (The appending of binary zero digits has essentially the same
8655 effect as taking a particular decimal approximation of
8656 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
8657 zeros to it, producing @samp{0.33333330000000000}.
8658 Treating the resulting decimal approximation as if it really
8659 had 18 or so digits of valid precision would make it seem
8660 a very poor approximation of @samp{1/3}.)
8662 As a result of converting the single-precision approximation
8663 to double precision by appending binary zeros, the conversion
8664 of the resulting double-precision
8665 value to decimal produces what looks like an incorrect
8666 result, when in fact the result is @emph{inexact}, and
8667 is probably no less inaccurate or imprecise an approximation
8668 of 0.2 than is produced by other compilers that happen to output
8669 the converted value as ``exactly'' @samp{0.2}.
8670 (Some compilers behave in a way that can make them appear
8671 to retain more accuracy across a conversion of a single-precision
8672 constant to double precision.
8673 @xref{Context-Sensitive Constants}, to see why
8674 this practice is illusory and even dangerous.)
8676 Note that a more exact approximation of the constant is
8677 computed when the program is changed to specify a
8678 double-precision constant:
8685 Future versions of @command{g77} and/or @code{libg2c} might convert
8686 single-precision values directly to decimal,
8687 instead of converting them to double precision first.
8688 This would tend to result in output that is more consistent
8689 with that produced by some other Fortran implementations.
8691 A useful source of information on floating-point computation is David
8692 Goldberg, `What Every Computer Scientist Should Know About
8693 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
8695 An online version is available at
8696 @uref{http://docs.sun.com/},
8697 and there is a supplemented version, in PostScript form, at
8698 @uref{http://www.validgh.com/goldberg/paper.ps}.
8700 Information related to the IEEE 754
8701 floating-point standard by a leading light can be found at
8702 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
8703 see also slides from the short course referenced from
8704 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
8705 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
8706 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
8707 and library code for GNU/Linux x86 systems.
8709 The supplement to the PostScript-formatted Goldberg document,
8710 referenced above, is available in HTML format.
8711 See `Differences Among IEEE 754 Implementations' by Doug Priest,
8713 @uref{http://www.validgh.com/goldberg/addendum.html}.
8714 This document explores some of the issues surrounding computing
8715 of extended (80-bit) results on processors such as the x86,
8716 especially when those results are arbitrarily truncated
8717 to 32-bit or 64-bit values by the compiler
8720 @cindex spills of floating-point results
8721 @cindex 80-bit spills
8722 @cindex truncation, of floating-point values
8723 (@emph{Note:} @command{g77} specifically, and @command{gcc} generally,
8724 does arbitrarily truncate 80-bit results during spills
8726 It is not yet clear whether a future version of
8727 the GNU compiler suite will offer 80-bit spills
8728 as an option, or perhaps even as the default behavior.)
8730 @c xref would be different between editions:
8731 The GNU C library provides routines for controlling the FPU, and other
8732 documentation about this.
8734 @xref{Floating-point precision}, regarding IEEE 754 conformance.
8738 @node Missing Features
8739 @section Missing Features
8741 This section lists features we know are missing from @command{g77},
8742 and which we want to add someday.
8743 (There is no priority implied in the ordering below.)
8746 GNU Fortran language:
8747 * Better Source Model::
8748 * Fortran 90 Support::
8749 * Intrinsics in PARAMETER Statements::
8750 * Arbitrary Concatenation::
8751 * SELECT CASE on CHARACTER Type::
8752 * RECURSIVE Keyword::
8753 * Popular Non-standard Types::
8754 * Full Support for Compiler Types::
8755 * Array Bounds Expressions::
8756 * POINTER Statements::
8757 * Sensible Non-standard Constructs::
8758 * READONLY Keyword::
8760 * Expressions in FORMAT Statements::
8761 * Explicit Assembler Code::
8762 * Q Edit Descriptor::
8764 GNU Fortran dialects:
8765 * Old-style PARAMETER Statements::
8766 * TYPE and ACCEPT I/O Statements::
8767 * STRUCTURE UNION RECORD MAP::
8768 * OPEN CLOSE and INQUIRE Keywords::
8769 * ENCODE and DECODE::
8770 * AUTOMATIC Statement::
8771 * Suppressing Space Padding::
8772 * Fortran Preprocessor::
8773 * Bit Operations on Floating-point Data::
8774 * Really Ugly Character Assignments::
8778 * Floating-point Exception Handling::
8779 * Nonportable Conversions::
8780 * Large Automatic Arrays::
8781 * Support for Threads::
8782 * Increasing Precision/Range::
8783 * Enabling Debug Lines::
8787 * Gracefully Handle Sensible Bad Code::
8788 * Non-standard Conversions::
8789 * Non-standard Intrinsics::
8790 * Modifying DO Variable::
8791 * Better Pedantic Compilation::
8792 * Warn About Implicit Conversions::
8793 * Invalid Use of Hollerith Constant::
8794 * Dummy Array Without Dimensioning Dummy::
8795 * Invalid FORMAT Specifiers::
8796 * Ambiguous Dialects::
8798 * Informational Messages::
8800 Run-time facilities:
8801 * Uninitialized Variables at Run Time::
8802 * Portable Unformatted Files::
8803 * Better List-directed I/O::
8804 * Default to Console I/O::
8807 * Labels Visible to Debugger::
8810 @node Better Source Model
8811 @subsection Better Source Model
8813 @command{g77} needs to provide, as the default source-line model,
8814 a ``pure visual'' mode, where
8815 the interpretation of a source program in this mode can be accurately
8816 determined by a user looking at a traditionally displayed rendition
8817 of the program (assuming the user knows whether the program is fixed
8820 The design should assume the user cannot tell tabs from spaces
8821 and cannot see trailing spaces on lines, but has canonical tab stops
8822 and, for fixed-form source, has the ability to always know exactly
8823 where column 72 is (since the Fortran standard itself requires
8824 this for fixed-form source).
8826 This would change the default treatment of fixed-form source
8827 to not treat lines with tabs as if they were infinitely long---instead,
8828 they would end at column 72 just as if the tabs were replaced
8829 by spaces in the canonical way.
8831 As part of this, provide common alternate models (Digital, @command{f2c},
8832 and so on) via command-line options.
8833 This includes allowing arbitrarily long
8834 lines for free-form source as well as fixed-form source and providing
8835 various limits and diagnostics as appropriate.
8837 @cindex sequence numbers
8838 @cindex columns 73 through 80
8839 Also, @command{g77} should offer, perhaps even default to, warnings
8840 when characters beyond the last valid column are anything other
8842 This would mean code with ``sequence numbers'' in columns 73 through 80
8843 would be rejected, and there's a lot of that kind of code around,
8844 but one of the most frequent bugs encountered by new users is
8845 accidentally writing fixed-form source code into and beyond
8847 So, maybe the users of old code would be able to more easily handle
8848 having to specify, say, a @option{-Wno-col73to80} option.
8850 @node Fortran 90 Support
8851 @subsection Fortran 90 Support
8852 @cindex Fortran 90, support
8853 @cindex support, Fortran 90
8855 @command{g77} does not support many of the features that
8856 distinguish Fortran 90 (and, now, Fortran 95) from
8859 Some Fortran 90 features are supported, because they
8860 make sense to offer even to die-hard users of F77.
8861 For example, many of them codify various ways F77 has
8862 been extended to meet users' needs during its tenure,
8863 so @command{g77} might as well offer them as the primary
8864 way to meet those same needs, even if it offers compatibility
8865 with one or more of the ways those needs were met
8866 by other F77 compilers in the industry.
8868 Still, many important F90 features are not supported,
8869 because no attempt has been made to research each and
8870 every feature and assess its viability in @command{g77}.
8871 In the meantime, users who need those features must
8872 use Fortran 90 compilers anyway, and the best approach
8873 to adding some F90 features to GNU Fortran might well be
8874 to fund a comprehensive project to create GNU Fortran 95.
8876 @node Intrinsics in PARAMETER Statements
8877 @subsection Intrinsics in @code{PARAMETER} Statements
8878 @cindex PARAMETER statement
8879 @cindex statements, PARAMETER
8881 @command{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
8882 This feature is considered to be absolutely vital, even though it
8883 is not standard-conforming, and is scheduled for version 0.6.
8885 Related to this, @command{g77} doesn't allow non-integral
8886 exponentiation in @code{PARAMETER} statements, such as
8887 @samp{PARAMETER (R=2**.25)}.
8888 It is unlikely @command{g77} will ever support this feature,
8889 as doing it properly requires complete emulation of
8890 a target computer's floating-point facilities when
8891 building @command{g77} as a cross-compiler.
8892 But, if the @command{gcc} back end is enhanced to provide
8893 such a facility, @command{g77} will likely use that facility
8894 in implementing this feature soon afterwards.
8896 @node Arbitrary Concatenation
8897 @subsection Arbitrary Concatenation
8898 @cindex concatenation
8899 @cindex CHARACTER*(*)
8900 @cindex run-time, dynamic allocation
8902 @command{g77} doesn't support arbitrary operands for concatenation
8903 in contexts where run-time allocation is required.
8909 CALL FOO(A // 'suffix')
8912 @node SELECT CASE on CHARACTER Type
8913 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
8915 Character-type selector/cases for @code{SELECT CASE} currently
8918 @node RECURSIVE Keyword
8919 @subsection @code{RECURSIVE} Keyword
8920 @cindex RECURSIVE keyword
8921 @cindex keywords, RECURSIVE
8922 @cindex recursion, lack of
8923 @cindex lack of recursion
8925 @command{g77} doesn't support the @code{RECURSIVE} keyword that
8927 Nor does it provide any means for compiling procedures
8928 designed to do recursion.
8930 All recursive code can be rewritten to not use recursion,
8931 but the result is not pretty.
8933 @node Increasing Precision/Range
8934 @subsection Increasing Precision/Range
8936 @cindex -qrealsize=8
8939 @cindex increasing precision
8940 @cindex precision, increasing
8941 @cindex increasing range
8942 @cindex range, increasing
8946 Some compilers, such as @command{f2c}, have an option (@option{-r8},
8947 @option{-qrealsize=8} or
8948 similar) that provides automatic treatment of @code{REAL}
8949 entities such that they have twice the storage size, and
8950 a corresponding increase in the range and precision, of what
8951 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
8952 (This affects @code{COMPLEX} the same way.)
8954 They also typically offer another option (@option{-i8}) to increase
8955 @code{INTEGER} entities so they are twice as large
8956 (with roughly twice as much range).
8958 (There are potential pitfalls in using these options.)
8960 @command{g77} does not yet offer any option that performs these
8961 kinds of transformations.
8962 Part of the problem is the lack of detailed specifications regarding
8963 exactly how these options affect the interpretation of constants,
8964 intrinsics, and so on.
8966 Until @command{g77} addresses this need, programmers could improve
8967 the portability of their code by modifying it to not require
8968 compile-time options to produce correct results.
8969 Some free tools are available which may help, specifically
8970 in Toolpack (which one would expect to be sound) and the @file{fortran}
8971 section of the Netlib repository.
8973 Use of preprocessors can provide a fairly portable means
8974 to work around the lack of widely portable methods in the Fortran
8975 language itself (though increasing acceptance of Fortran 90 would
8976 alleviate this problem).
8978 @node Popular Non-standard Types
8979 @subsection Popular Non-standard Types
8980 @cindex @code{INTEGER*2} support
8981 @cindex types, @code{INTEGER*2}
8982 @cindex @code{LOGICAL*1} support
8983 @cindex types, @code{LOGICAL*1}
8985 @command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
8987 Version 0.6 will provide full support for this very
8988 popular set of features.
8989 In the meantime, version 0.5.18 provides rudimentary support
8992 @node Full Support for Compiler Types
8993 @subsection Full Support for Compiler Types
8995 @cindex @code{REAL*16} support
8996 @cindex types, @code{REAL*16}
8997 @cindex @code{INTEGER*8} support
8998 @cindex types, @code{INTEGER*8}
8999 @command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
9000 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
9001 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
9002 This means providing intrinsic support, and maybe constant
9003 support (using F90 syntax) as well, and, for most
9004 machines will result in automatic support of @code{INTEGER*1},
9005 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
9007 This is scheduled for version 0.6.
9009 @node Array Bounds Expressions
9010 @subsection Array Bounds Expressions
9011 @cindex array elements, in adjustable array bounds
9012 @cindex function references, in adjustable array bounds
9013 @cindex array bounds, adjustable
9014 @cindex @code{DIMENSION} statement
9015 @cindex statements, @code{DIMENSION}
9017 @command{g77} doesn't support more general expressions to dimension
9018 arrays, such as array element references, function
9021 For example, @command{g77} currently does not accept the following:
9025 INTEGER N(10), M(N(2), N(1))
9028 @node POINTER Statements
9029 @subsection POINTER Statements
9030 @cindex POINTER statement
9031 @cindex statements, POINTER
9032 @cindex Cray pointers
9034 @command{g77} doesn't support pointers or allocatable objects
9035 (other than automatic arrays).
9036 This set of features is
9037 probably considered just behind intrinsics
9038 in @code{PARAMETER} statements on the list of large,
9039 important things to add to @command{g77}.
9041 In the meantime, consider using the @code{INTEGER(KIND=7)}
9042 declaration to specify that a variable must be
9043 able to hold a pointer.
9044 This construct is not portable to other non-GNU compilers,
9045 but it is portable to all machines GNU Fortran supports
9046 when @command{g77} is used.
9048 @xref{Functions and Subroutines}, for information on
9049 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
9050 constructs, which are useful for passing pointers to
9051 procedures written in languages other than Fortran.
9053 @node Sensible Non-standard Constructs
9054 @subsection Sensible Non-standard Constructs
9056 @command{g77} rejects things other compilers accept,
9057 like @samp{INTRINSIC SQRT,SQRT}.
9058 As time permits in the future, some of these things that are easy for
9059 humans to read and write and unlikely to be intended to mean something
9060 else will be accepted by @command{g77} (though @option{-fpedantic} should
9061 trigger warnings about such non-standard constructs).
9063 Until @command{g77} no longer gratuitously rejects sensible code,
9064 you might as well fix your code
9065 to be more standard-conforming and portable.
9067 The kind of case that is important to except from the
9068 recommendation to change your code is one where following
9069 good coding rules would force you to write non-standard
9070 code that nevertheless has a clear meaning.
9072 For example, when writing an @code{INCLUDE} file that
9073 defines a common block, it might be appropriate to
9074 include a @code{SAVE} statement for the common block
9075 (such as @samp{SAVE /CBLOCK/}), so that variables
9076 defined in the common block retain their values even
9077 when all procedures declaring the common block become
9078 inactive (return to their callers).
9080 However, putting @code{SAVE} statements in an @code{INCLUDE}
9081 file would prevent otherwise standard-conforming code
9082 from also specifying the @code{SAVE} statement, by itself,
9083 to indicate that all local variables and arrays are to
9084 have the @code{SAVE} attribute.
9086 For this reason, @command{g77} already has been changed to
9087 allow this combination, because although the general
9088 problem of gratuitously rejecting unambiguous and
9089 ``safe'' constructs still exists in @command{g77}, this
9090 particular construct was deemed useful enough that
9091 it was worth fixing @command{g77} for just this case.
9093 So, while there is no need to change your code
9094 to avoid using this particular construct, there
9095 might be other, equally appropriate but non-standard
9096 constructs, that you shouldn't have to stop using
9097 just because @command{g77} (or any other compiler)
9098 gratuitously rejects it.
9100 Until the general problem is solved, if you have
9101 any such construct you believe is worthwhile
9102 using (e.g. not just an arbitrary, redundant
9103 specification of an attribute), please submit a
9104 bug report with an explanation, so we can consider
9105 fixing @command{g77} just for cases like yours.
9107 @node READONLY Keyword
9108 @subsection @code{READONLY} Keyword
9111 Support for @code{READONLY}, in @code{OPEN} statements,
9112 requires @code{libg2c} support,
9113 to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
9114 does not delete a file opened on a unit
9115 with the @code{READONLY} keyword,
9116 and perhaps to trigger a fatal diagnostic
9117 if a @code{WRITE} or @code{PRINT}
9118 to such a unit is attempted.
9120 @emph{Note:} It is not sufficient for @command{g77} and @code{libg2c}
9121 (its version of @code{libf2c})
9122 to assume that @code{READONLY} does not need some kind of explicit support
9124 due to UNIX systems not (generally) needing it.
9125 @command{g77} is not just a UNIX-based compiler!
9127 Further, mounting of non-UNIX filesystems on UNIX systems
9129 might require proper @code{READONLY} support.
9132 (Similar issues might be involved with supporting the @code{SHARED}
9135 @node FLUSH Statement
9136 @subsection @code{FLUSH} Statement
9138 @command{g77} could perhaps use a @code{FLUSH} statement that
9139 does what @samp{CALL FLUSH} does,
9140 but that supports @samp{*} as the unit designator (same unit as for
9141 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
9144 @node Expressions in FORMAT Statements
9145 @subsection Expressions in @code{FORMAT} Statements
9146 @cindex FORMAT statement
9147 @cindex statements, FORMAT
9149 @command{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
9150 Supporting this requires a significant redesign or replacement
9153 However, @command{g77} does support
9154 this construct when the expression is constant
9155 (as of version 0.5.22).
9159 PARAMETER (IWIDTH = 12)
9160 10 FORMAT (I<IWIDTH>)
9163 Otherwise, at least for output (@code{PRINT} and
9164 @code{WRITE}), Fortran code making use of this feature can
9165 be rewritten to avoid it by constructing the @code{FORMAT}
9166 string in a @code{CHARACTER} variable or array, then
9167 using that variable or array in place of the @code{FORMAT}
9168 statement label to do the original @code{PRINT} or @code{WRITE}.
9170 Many uses of this feature on input can be rewritten this way
9171 as well, but not all can.
9172 For example, this can be rewritten:
9179 However, this cannot, in general, be rewritten, especially
9180 when @code{ERR=} and @code{END=} constructs are employed:
9187 @node Explicit Assembler Code
9188 @subsection Explicit Assembler Code
9190 @command{g77} needs to provide some way, a la @command{gcc}, for @command{g77}
9191 code to specify explicit assembler code.
9193 @node Q Edit Descriptor
9194 @subsection Q Edit Descriptor
9195 @cindex FORMAT statement
9196 @cindex Q edit descriptor
9197 @cindex edit descriptor, Q
9199 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
9200 (This is meant to get the number of characters remaining in an input record.)
9201 Supporting this requires a significant redesign or replacement
9204 A workaround might be using internal I/O or the stream-based intrinsics.
9205 @xref{FGetC Intrinsic (subroutine)}.
9207 @node Old-style PARAMETER Statements
9208 @subsection Old-style PARAMETER Statements
9209 @cindex PARAMETER statement
9210 @cindex statements, PARAMETER
9212 @command{g77} doesn't accept @samp{PARAMETER I=1}.
9213 Supporting this obsolete form of
9214 the @code{PARAMETER} statement would not be particularly hard, as most of the
9215 parsing code is already in place and working.
9218 spent implementing it, you might as well fix your code to use the
9219 standard form, @samp{PARAMETER (I=1)} (possibly needing
9220 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
9221 otherwise, in the obsolete form of @code{PARAMETER}, the
9222 type of the variable is set from the type of the constant being
9225 @node TYPE and ACCEPT I/O Statements
9226 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
9227 @cindex TYPE statement
9228 @cindex statements, TYPE
9229 @cindex ACCEPT statement
9230 @cindex statements, ACCEPT
9232 @command{g77} doesn't support the I/O statements @code{TYPE} and
9234 These are common extensions that should be easy to support,
9235 but also are fairly easy to work around in user code.
9237 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
9238 by @samp{PRINT fmt,list}.
9239 And, any @samp{ACCEPT fmt,list} statement can be
9240 replaced by @samp{READ fmt,list}.
9242 @node STRUCTURE UNION RECORD MAP
9243 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
9244 @cindex STRUCTURE statement
9245 @cindex statements, STRUCTURE
9246 @cindex UNION statement
9247 @cindex statements, UNION
9248 @cindex RECORD statement
9249 @cindex statements, RECORD
9250 @cindex MAP statement
9251 @cindex statements, MAP
9253 @command{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
9255 This set of extensions is quite a bit
9256 lower on the list of large, important things to add to @command{g77}, partly
9257 because it requires a great deal of work either upgrading or
9258 replacing @code{libg2c}.
9260 @node OPEN CLOSE and INQUIRE Keywords
9261 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
9262 @cindex disposition of files
9263 @cindex OPEN statement
9264 @cindex statements, OPEN
9265 @cindex CLOSE statement
9266 @cindex statements, CLOSE
9267 @cindex INQUIRE statement
9268 @cindex statements, INQUIRE
9270 @command{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
9271 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
9272 These extensions are easy to add to @command{g77} itself, but
9273 require much more work on @code{libg2c}.
9275 @cindex FORM='PRINT'
9276 @cindex ANS carriage control
9277 @cindex carriage control
9280 @command{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
9281 translate the traditional `carriage control' characters in column 1 of
9282 output to use backspaces, carriage returns and the like. However
9283 programs exist to translate them in output files (or standard output).
9284 These are typically called either @command{fpr} or @command{asa}. You can get
9285 a version of @command{asa} from
9286 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
9287 systems which will probably build easily on other systems.
9288 Alternatively, @command{fpr} is in BSD distributions in various archive
9291 @c (Can both programs can be used in a pipeline,
9292 @c with a named input file,
9293 @c and/or with a named output file???)
9295 @node ENCODE and DECODE
9296 @subsection @code{ENCODE} and @code{DECODE}
9297 @cindex ENCODE statement
9298 @cindex statements, ENCODE
9299 @cindex DECODE statement
9300 @cindex statements, DECODE
9302 @command{g77} doesn't support @code{ENCODE} or @code{DECODE}.
9304 These statements are best replaced by READ and WRITE statements
9305 involving internal files (CHARACTER variables and arrays).
9307 For example, replace a code fragment like
9312 DECODE (80, 9000, LINE) A, B, C
9314 9000 FORMAT (1X, 3(F10.5))
9323 READ (UNIT=LINE, FMT=9000) A, B, C
9325 9000 FORMAT (1X, 3(F10.5))
9328 Similarly, replace a code fragment like
9333 ENCODE (80, 9000, LINE) A, B, C
9335 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
9344 WRITE (UNIT=LINE, FMT=9000) A, B, C
9346 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
9349 It is entirely possible that @code{ENCODE} and @code{DECODE} will
9350 be supported by a future version of @command{g77}.
9352 @node AUTOMATIC Statement
9353 @subsection @code{AUTOMATIC} Statement
9354 @cindex @code{AUTOMATIC} statement
9355 @cindex statements, @code{AUTOMATIC}
9356 @cindex automatic variables
9357 @cindex variables, automatic
9359 @command{g77} doesn't support the @code{AUTOMATIC} statement that
9362 @code{AUTOMATIC} would identify a variable or array
9363 as not being @code{SAVE}'d, which is normally the default,
9364 but which would be especially useful for code that, @emph{generally},
9365 needed to be compiled with the @option{-fno-automatic} option.
9367 @code{AUTOMATIC} also would serve as a hint to the compiler that placing
9368 the variable or array---even a very large array--on the stack is acceptable.
9370 @code{AUTOMATIC} would not, by itself, designate the containing procedure
9373 @code{AUTOMATIC} should work syntactically like @code{SAVE},
9374 in that @code{AUTOMATIC} with no variables listed should apply to
9375 all pertinent variables and arrays
9376 (which would not include common blocks or their members).
9378 Variables and arrays denoted as @code{AUTOMATIC}
9379 would not be permitted to be initialized via @code{DATA}
9380 or other specification of any initial values,
9381 requiring explicit initialization,
9382 such as via assignment statements.
9386 Perhaps @code{UNSAVE} and @code{STATIC},
9387 as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
9388 should be provided as well.
9390 @node Suppressing Space Padding
9391 @subsection Suppressing Space Padding of Source Lines
9393 @command{g77} should offer VXT-Fortran-style suppression of virtual
9394 spaces at the end of a source line
9395 if an appropriate command-line option is specified.
9397 This affects cases where
9398 a character constant is continued onto the next line in a fixed-form
9399 source file, as in the following example:
9402 10 PRINT *,'HOW MANY
9407 @command{g77}, and many other compilers, virtually extend
9408 the continued line through column 72 with spaces that become part
9409 of the character constant, but Digital Fortran normally didn't,
9410 leaving only one space between @samp{MANY} and @samp{SPACES?}
9411 in the output of the above statement.
9413 Fairly recently, at least one version of Digital Fortran
9414 was enhanced to provide the other behavior when a
9415 command-line option is specified, apparently due to demand
9416 from readers of the USENET group @file{comp.lang.fortran}
9417 to offer conformance to this widespread practice in the
9419 @command{g77} should return the favor by offering conformance
9420 to Digital's approach to handling the above example.
9422 @node Fortran Preprocessor
9423 @subsection Fortran Preprocessor
9425 @command{g77} should offer a preprocessor designed specifically
9426 for Fortran to replace @samp{cpp -traditional}.
9427 There are several out there worth evaluating, at least.
9429 Such a preprocessor would recognize Hollerith constants,
9430 properly parse comments and character constants, and so on.
9431 It might also recognize, process, and thus preprocess
9432 files included via the @code{INCLUDE} directive.
9434 @node Bit Operations on Floating-point Data
9435 @subsection Bit Operations on Floating-point Data
9436 @cindex @code{And} intrinsic
9437 @cindex intrinsics, @code{And}
9438 @cindex @code{Or} intrinsic
9439 @cindex intrinsics, @code{Or}
9440 @cindex @code{Shift} intrinsic
9441 @cindex intrinsics, @code{Shift}
9443 @command{g77} does not allow @code{REAL} and other non-integral types for
9444 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
9446 For example, this program is rejected by @command{g77}, because
9447 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
9450 DATA A/7.54/, B/9.112/
9455 @node Really Ugly Character Assignments
9456 @subsection Really Ugly Character Assignments
9458 An option such as @option{-fugly-char} should be provided
9463 DATA A1 / '12345678' /
9473 @node POSIX Standard
9474 @subsection @code{POSIX} Standard
9476 @command{g77} should support the POSIX standard for Fortran.
9478 @node Floating-point Exception Handling
9479 @subsection Floating-point Exception Handling
9480 @cindex floating-point, exceptions
9481 @cindex exceptions, floating-point
9482 @cindex FPE handling
9485 The @command{gcc} backend and, consequently, @command{g77}, currently provides no
9486 general control over whether or not floating-point exceptions are trapped or
9488 (Ignoring them typically results in NaN values being
9489 propagated in systems that conform to IEEE 754.)
9490 The behaviour is normally inherited from the system-dependent startup
9491 code, though some targets, such as the Alpha, have code generation
9492 options which change the behaviour.
9494 Most systems provide some C-callable mechanism to change this; this can
9495 be invoked at startup using @command{gcc}'s @code{constructor} attribute.
9496 For example, just compiling and linking the following C code with your
9497 program will turn on exception trapping for the ``common'' exceptions
9498 on a GNU system using glibc 2.2 or newer:
9501 #define _GNU_SOURCE 1
9503 static void __attribute__ ((constructor))
9506 /* Enable some exceptions. At startup all exceptions are masked. */
9508 feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
9512 A convenient trick is to compile this something like:
9514 gcc -o libtrapfpe.a trapfpe.c
9516 and then use it by adding @option{-trapfpe} to the @command{g77} command line
9519 @node Nonportable Conversions
9520 @subsection Nonportable Conversions
9521 @cindex nonportable conversions
9522 @cindex conversions, nonportable
9524 @command{g77} doesn't accept some particularly nonportable,
9525 silent data-type conversions such as @code{LOGICAL}
9526 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
9527 is type @code{REAL}), that other compilers might
9530 Some of these conversions are accepted by @command{g77}
9531 when the @option{-fugly-logint} option is specified.
9532 Perhaps it should accept more or all of them.
9534 @node Large Automatic Arrays
9535 @subsection Large Automatic Arrays
9536 @cindex automatic arrays
9537 @cindex arrays, automatic
9539 Currently, automatic arrays always are allocated on the stack.
9540 For situations where the stack cannot be made large enough,
9541 @command{g77} should offer a compiler option that specifies
9542 allocation of automatic arrays in heap storage.
9544 @node Support for Threads
9545 @subsection Support for Threads
9547 @cindex parallel processing
9549 Neither the code produced by @command{g77} nor the @code{libg2c} library
9550 are thread-safe, nor does @command{g77} have support for parallel processing
9551 (other than the instruction-level parallelism available on some
9553 A package such as PVM might help here.
9555 @node Enabling Debug Lines
9556 @subsection Enabling Debug Lines
9558 @cindex comment line, debug
9560 An option such as @option{-fdebug-lines} should be provided
9561 to turn fixed-form lines beginning with @samp{D}
9562 to be treated as if they began with a space,
9563 instead of as if they began with a @samp{C}
9566 @node Better Warnings
9567 @subsection Better Warnings
9569 Because of how @command{g77} generates code via the back end,
9570 it doesn't always provide warnings the user wants.
9579 Currently, the above is not flagged as a case of
9580 using an uninitialized variable,
9581 because @command{g77} generates a run-time library call that looks,
9582 to the GBE, like it might actually @emph{modify} @samp{A} at run time.
9583 (And, in fact, depending on the previous run-time library call,
9586 Fixing this requires one of the following:
9590 Switch to new library, @code{libg77}, that provides
9591 a more ``clean'' interface,
9592 vis-a-vis input, output, and modified arguments,
9593 so the GBE can tell what's going on.
9595 This would provide a pretty big performance improvement,
9596 at least theoretically, and, ultimately, in practice,
9597 for some types of code.
9600 Have @command{g77} pass a pointer to a temporary
9601 containing a copy of @samp{A},
9602 instead of to @samp{A} itself.
9603 The GBE would then complain about the copy operation
9604 involving a potentially uninitialized variable.
9606 This might also provide a performance boost for some code,
9607 because @samp{A} might then end up living in a register,
9608 which could help with inner loops.
9611 Have @command{g77} use a GBE construct similar to @code{ADDR_EXPR}
9612 but with extra information on the fact that the
9613 item pointed to won't be modified
9614 (a la @code{const} in C).
9616 Probably the best solution for now, but not quite trivial
9617 to implement in the general case.
9618 Worth considering after @command{g77} 0.6 is considered
9622 @node Gracefully Handle Sensible Bad Code
9623 @subsection Gracefully Handle Sensible Bad Code
9625 @command{g77} generally should continue processing for
9626 warnings and recoverable (user) errors whenever possible---that
9627 is, it shouldn't gratuitously make bad or useless code.
9638 When compiling the above with @option{-ff2c-intrinsics-disable},
9639 @command{g77} should indeed complain about passing @code{ZABS},
9640 but it still should compile, instead of rejecting
9641 the entire @code{CALL} statement.
9642 (Some of this is related to improving
9643 the compiler internals to improve how statements are analyzed.)
9645 @node Non-standard Conversions
9646 @subsection Non-standard Conversions
9648 @option{-Wconversion} and related should flag places where non-standard
9649 conversions are found.
9650 Perhaps much of this would be part of @option{-Wugly*}.
9652 @node Non-standard Intrinsics
9653 @subsection Non-standard Intrinsics
9655 @command{g77} needs a new option, like @option{-Wintrinsics}, to warn about use of
9656 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
9657 This would help find code that might fail silently when ported to another
9660 @node Modifying DO Variable
9661 @subsection Modifying @code{DO} Variable
9663 @command{g77} should warn about modifying @code{DO} variables
9664 via @code{EQUIVALENCE}.
9665 (The internal information gathered to produce this warning
9666 might also be useful in setting the
9667 internal ``doiter'' flag for a variable or even array
9668 reference within a loop, since that might produce faster code someday.)
9670 For example, this code is invalid, so @command{g77} should warn about
9671 the invalid assignment to @samp{NOTHER}:
9674 EQUIVALENCE (I, NOTHER)
9676 IF (I.EQ. 10) NOTHER = 20
9680 @node Better Pedantic Compilation
9681 @subsection Better Pedantic Compilation
9683 @command{g77} needs to support @option{-fpedantic} more thoroughly,
9684 and use it only to generate
9685 warnings instead of rejecting constructs outright.
9687 if a variable that dimensions an array is not a dummy or placed
9688 explicitly in @code{COMMON} (F77 does not allow it to be
9689 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
9690 follow statement-function-definition statements; about all sorts of
9691 syntactic extensions.
9693 @node Warn About Implicit Conversions
9694 @subsection Warn About Implicit Conversions
9696 @command{g77} needs a @option{-Wpromotions} option to warn if source code appears
9697 to expect automatic, silent, and
9698 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
9699 constants to @code{REAL(KIND=2)} based on context.
9701 For example, it would warn about cases like this:
9704 DOUBLE PRECISION FOO
9705 PARAMETER (TZPHI = 9.435784839284958)
9709 @node Invalid Use of Hollerith Constant
9710 @subsection Invalid Use of Hollerith Constant
9712 @command{g77} should disallow statements like @samp{RETURN 2HAB},
9713 which are invalid in both source forms
9714 (unlike @samp{RETURN (2HAB)},
9715 which probably still makes no sense but at least can
9716 be reliably parsed).
9717 Fixed-form processing rejects it, but not free-form, except
9718 in a way that is a bit difficult to understand.
9720 @node Dummy Array Without Dimensioning Dummy
9721 @subsection Dummy Array Without Dimensioning Dummy
9723 @command{g77} should complain when a list of dummy arguments containing an
9724 adjustable dummy array does
9725 not also contain every variable listed in the dimension list of the
9728 Currently, @command{g77} does complain about a variable that
9729 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
9730 area, but this needs to be extended to catch cases where it doesn't appear in
9731 every dummy list that also lists any arrays it dimensions.
9733 For example, @command{g77} should warn about the entry point @samp{ALT}
9734 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
9738 SUBROUTINE PRIMARY(ARRAY, ISIZE)
9743 @node Invalid FORMAT Specifiers
9744 @subsection Invalid FORMAT Specifiers
9746 @command{g77} should check @code{FORMAT} specifiers for validity
9747 as it does @code{FORMAT} statements.
9749 For example, a diagnostic would be produced for:
9752 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
9755 @node Ambiguous Dialects
9756 @subsection Ambiguous Dialects
9758 @command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic},
9759 @option{-Wvxt}, @option{-Wf90}, and so on.
9760 These would warn about places in the user's source where ambiguities
9761 are found, helpful in resolving ambiguities in the program's
9762 dialect or dialects.
9765 @subsection Unused Labels
9767 @command{g77} should warn about unused labels when @option{-Wunused} is in effect.
9769 @node Informational Messages
9770 @subsection Informational Messages
9772 @command{g77} needs an option to suppress information messages (notes).
9773 @option{-w} does this but also suppresses warnings.
9774 The default should be to suppress info messages.
9776 Perhaps info messages should simply be eliminated.
9778 @node Uninitialized Variables at Run Time
9779 @subsection Uninitialized Variables at Run Time
9781 @command{g77} needs an option to initialize everything (not otherwise
9782 explicitly initialized) to ``weird''
9783 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
9784 largest-magnitude integers, would help track down references to
9785 some kinds of uninitialized variables at run time.
9787 Note that use of the options @samp{-O -Wuninitialized} can catch
9788 many such bugs at compile time.
9790 @node Portable Unformatted Files
9791 @subsection Portable Unformatted Files
9793 @cindex unformatted files
9794 @cindex file formats
9796 @cindex byte ordering
9797 @command{g77} has no facility for exchanging unformatted files with systems
9798 using different number formats---even differing only in endianness (byte
9799 order)---or written by other compilers. Some compilers provide
9800 facilities at least for doing byte-swapping during unformatted I/O.
9802 It is unrealistic to expect to cope with exchanging unformatted files
9803 with arbitrary other compiler runtimes, but the @command{g77} runtime
9804 should at least be able to read files written by @command{g77} on systems
9805 with different number formats, particularly if they differ only in byte
9808 In case you do need to write a program to translate to or from
9809 @command{g77} (@code{libf2c}) unformatted files, they are written as
9813 Unformatted sequential records consist of
9816 A number giving the length of the record contents;
9818 the length of record contents again (for backspace).
9821 The record length is of C type
9822 @code{long}; this means that it is 8 bytes on 64-bit systems such as
9823 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
9824 Consequently such files cannot be exchanged between 64-bit and 32-bit
9825 systems, even with the same basic number format.
9827 Unformatted direct access files form a byte stream of length
9828 @var{records}*@var{recl} bytes, where @var{records} is the maximum
9829 record number (@code{REC=@var{records}}) written and @var{recl} is the
9830 record length in bytes specified in the @code{OPEN} statement
9831 (@code{RECL=@var{recl}}). Data appear in the records as determined by
9832 the relevant @code{WRITE} statement. Dummy records with arbitrary
9833 contents appear in the file in place of records which haven't been
9837 Thus for exchanging a sequential or direct access unformatted file
9838 between big- and little-endian 32-bit systems using IEEE 754 floating
9839 point it would be sufficient to reverse the bytes in consecutive words
9840 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
9841 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
9844 If necessary, it is possible to do byte-oriented i/o with @command{g77}'s
9845 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
9846 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
9847 array or a set of scalars.
9851 If you need to exchange binary data between arbitrary system and
9852 compiler variations, we recommend using a portable binary format with
9853 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
9854 or PACT's PDB@footnote{No, not @emph{that} one.}
9855 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
9856 say, CDF or XDR, HDF-like systems write in the native number formats and
9857 only incur overhead when they are read on a system with a different
9858 format.) A future @command{g77} runtime library should use such
9861 @node Better List-directed I/O
9862 @subsection Better List-directed I/O
9864 Values output using list-directed I/O
9865 (@samp{PRINT *, R, D})
9866 should be written with a field width, precision, and so on
9867 appropriate for the type (precision) of each value.
9869 (Currently, no distinction is made between single-precision
9870 and double-precision values
9873 It is likely this item will require the @code{libg77} project
9876 In the meantime, use of formatted I/O is recommended.
9877 While it might be of little consolation,
9878 @command{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
9879 as long as @samp{WIDTH} is defined as a named constant
9880 (via @code{PARAMETER}).
9881 That at least allows some compile-time specification
9882 of the precision of a data type,
9883 perhaps controlled by preprocessing directives.
9885 @node Default to Console I/O
9886 @subsection Default to Console I/O
9888 The default I/O units,
9889 specified by @samp{READ @var{fmt}},
9890 @samp{READ (UNIT=*)},
9891 @samp{WRITE (UNIT=*)}, and
9892 @samp{PRINT @var{fmt}},
9893 should not be units 5 (input) and 6 (output),
9894 but, rather, unit numbers not normally available
9895 for use in statements such as @code{OPEN} and @code{CLOSE}.
9897 Changing this would allow a program to connect units 5 and 6
9898 to files via @code{OPEN},
9899 but still use @samp{READ (UNIT=*)} and @samp{PRINT}
9900 to do I/O to the ``console''.
9902 This change probably requires the @code{libg77} project.
9904 @node Labels Visible to Debugger
9905 @subsection Labels Visible to Debugger
9907 @command{g77} should output debugging information for statements labels,
9908 for use by debuggers that know how to support them.
9909 Same with weirder things like construct names.
9910 It is not yet known if any debug formats or debuggers support these.
9912 @node Disappointments
9913 @section Disappointments and Misunderstandings
9915 These problems are perhaps regrettable, but we don't know any practical
9916 way around them for now.
9919 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
9920 external name @samp{foo_}.
9921 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
9922 and @samp{SUBROUTINE FOO}.
9923 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
9926 @node Mangling of Names
9927 @subsection Mangling of Names in Source Code
9928 @cindex naming issues
9929 @cindex external names
9930 @cindex common blocks
9934 The current external-interface design, which includes naming of
9935 external procedures, COMMON blocks, and the library interface,
9936 has various usability problems, including things like adding
9937 underscores where not really necessary (and preventing easier
9938 inter-language operability) and yet not providing complete
9939 namespace freedom for user C code linked with Fortran apps (due
9940 to the naming of functions in the library, among other things).
9942 Project GNU should at least get all this ``right'' for systems
9943 it fully controls, such as the Hurd, and provide defaults and
9944 options for compatibility with existing systems and interoperability
9945 with popular existing compilers.
9947 @node Multiple Definitions of External Names
9948 @subsection Multiple Definitions of External Names
9950 @cindex BLOCK DATA statement
9951 @cindex statements, BLOCK DATA
9952 @cindex @code{COMMON} statement
9953 @cindex statements, @code{COMMON}
9954 @cindex naming conflicts
9956 @command{g77} doesn't allow a common block and an external procedure or
9957 @code{BLOCK DATA} to have the same name.
9958 Some systems allow this, but @command{g77} does not,
9959 to be compatible with @command{f2c}.
9961 @command{g77} could special-case the way it handles
9962 @code{BLOCK DATA}, since it is not compatible with @command{f2c} in this
9963 particular area (necessarily, since @command{g77} offers an
9964 important feature here), but
9965 it is likely that such special-casing would be very annoying to people
9966 with programs that use @samp{EXTERNAL FOO}, with no other mention of
9967 @samp{FOO} in the same program unit, to refer to external procedures, since
9968 the result would be that @command{g77} would treat these references as requests to
9969 force-load BLOCK DATA program units.
9971 In that case, if @command{g77} modified
9972 names of @code{BLOCK DATA} so they could have the same names as
9973 @code{COMMON}, users
9974 would find that their programs wouldn't link because the @samp{FOO} procedure
9975 didn't have its name translated the same way.
9978 @command{g77} could emit a null-but-externally-satisfying definition of
9979 @samp{FOO} with its name transformed as if it had been a
9980 @code{BLOCK DATA}, but that probably invites more trouble than it's
9983 @node Limitation on Implicit Declarations
9984 @subsection Limitation on Implicit Declarations
9985 @cindex IMPLICIT CHARACTER*(*) statement
9986 @cindex statements, IMPLICIT CHARACTER*(*)
9988 @command{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
9989 This is not standard-conforming.
9992 @section Certain Changes We Don't Want to Make
9994 This section lists changes that people frequently request, but which
9995 we do not make because we think GNU Fortran is better without them.
9998 * Backslash in Constants:: Why @samp{'\\'} is a constant that
9999 is one, not two, characters long.
10000 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
10002 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
10003 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
10004 single-precision constant,
10005 and might be interpreted as
10006 @samp{9.435785} or similar.
10007 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
10008 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
10009 not behave as expected.
10012 @node Backslash in Constants
10013 @subsection Backslash in Constants
10015 @cindex @command{f77} support
10016 @cindex support, @command{f77}
10018 In the opinion of many experienced Fortran users,
10019 @option{-fno-backslash} should be the default, not @option{-fbackslash},
10020 as currently set by @command{g77}.
10022 First of all, you can always specify
10023 @option{-fno-backslash} to turn off this processing.
10025 Despite not being within the spirit (though apparently within the
10026 letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to
10027 @option{-fbackslash} because that is what most UNIX @command{f77} commands
10028 default to, and apparently lots of code depends on this feature.
10030 This is a particularly troubling issue.
10031 The use of a C construct in the midst of Fortran code
10032 is bad enough, worse when it makes existing Fortran
10033 programs stop working (as happens when programs written
10034 for non-UNIX systems are ported to UNIX systems with
10035 compilers that provide the @option{-fbackslash} feature
10036 as the default---sometimes with no option to turn it off).
10038 The author of GNU Fortran wished, for reasons of linguistic
10039 purity, to make @option{-fno-backslash} the default for GNU
10040 Fortran and thus require users of UNIX @command{f77} and @command{f2c}
10041 to specify @option{-fbackslash} to get the UNIX behavior.
10043 However, the realization that @command{g77} is intended as
10044 a replacement for @emph{UNIX} @command{f77}, caused the author
10045 to choose to make @command{g77} as compatible with
10046 @command{f77} as feasible, which meant making @option{-fbackslash}
10049 The primary focus on compatibility is at the source-code
10050 level, and the question became ``What will users expect
10051 a replacement for @command{f77} to do, by default?''
10052 Although at least one UNIX @command{f77} does not provide
10053 @option{-fbackslash} as a default, it appears that
10054 the majority of them do, which suggests that
10055 the majority of code that is compiled by UNIX @command{f77}
10056 compilers expects @option{-fbackslash} to be the default.
10058 It is probably the case that more code exists
10059 that would @emph{not} work with @option{-fbackslash}
10060 in force than code that requires it be in force.
10062 However, most of @emph{that} code is not being compiled
10063 with @command{f77},
10064 and when it is, new build procedures (shell scripts,
10065 makefiles, and so on) must be set up anyway so that
10066 they work under UNIX.
10067 That makes a much more natural and safe opportunity for
10068 non-UNIX users to adapt their build procedures for
10069 @command{g77}'s default of @option{-fbackslash} than would
10070 exist for the majority of UNIX @command{f77} users who
10071 would have to modify existing, working build procedures
10072 to explicitly specify @option{-fbackslash} if that was
10075 One suggestion has been to configure the default for
10076 @option{-fbackslash} (and perhaps other options as well)
10077 based on the configuration of @command{g77}.
10079 This is technically quite straightforward, but will be avoided
10080 even in cases where not configuring defaults to be
10081 dependent on a particular configuration greatly inconveniences
10082 some users of legacy code.
10084 Many users appreciate the GNU compilers because they provide an
10085 environment that is uniform across machines.
10086 These users would be
10087 inconvenienced if the compiler treated things like the
10088 format of the source code differently on certain machines.
10090 Occasionally users write programs intended only for a particular machine
10092 On these occasions, the users would benefit if the GNU Fortran compiler
10093 were to support by default the same dialect as the other compilers on
10095 But such applications are rare.
10096 And users writing a
10097 program to run on more than one type of machine cannot possibly benefit
10098 from this kind of compatibility.
10099 (This is consistent with the design goals for @command{gcc}.
10100 To change them for @command{g77}, you must first change them
10102 Do not ask the maintainers of @command{g77} to do this for you,
10103 or to disassociate @command{g77} from the widely understood, if
10104 not widely agreed-upon, goals for GNU compilers in general.)
10106 This is why GNU Fortran does and will treat backslashes in the same
10107 fashion on all types of machines (by default).
10108 @xref{Direction of Language Development}, for more information on
10109 this overall philosophy guiding the development of the GNU Fortran
10112 Of course, users strongly concerned about portability should indicate
10113 explicitly in their build procedures which options are expected
10114 by their source code, or write source code that has as few such
10115 expectations as possible.
10117 For example, avoid writing code that depends on backslash (@samp{\})
10118 being interpreted either way in particular, such as by
10119 starting a program unit with:
10123 PARAMETER (BACKSL = '\\')
10127 Then, use concatenation of @samp{BACKSL} anyplace a backslash
10129 In this way, users can write programs which have the same meaning
10130 in many Fortran dialects.
10132 (However, this technique does not work for Hollerith constants---which
10133 is just as well, since the only generally portable uses for Hollerith
10134 constants are in places where character constants can and should
10135 be used instead, for readability.)
10137 @node Initializing Before Specifying
10138 @subsection Initializing Before Specifying
10139 @cindex initialization, statement placement
10140 @cindex placing initialization statements
10142 @command{g77} does not allow @samp{DATA VAR/1/} to appear in the
10143 source code before @samp{COMMON VAR},
10144 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
10145 In general, @command{g77} requires initialization of a variable
10146 or array to be specified @emph{after} all other specifications
10147 of attributes (type, size, placement, and so on) of that variable
10148 or array are specified (though @emph{confirmation} of data type is
10151 It is @emph{possible} @command{g77} will someday allow all of this,
10152 even though it is not allowed by the FORTRAN 77 standard.
10154 Then again, maybe it is better to have
10155 @command{g77} always require placement of @code{DATA}
10156 so that it can possibly immediately write constants
10157 to the output file, thus saving time and space.
10159 That is, @samp{DATA A/1000000*1/} should perhaps always
10160 be immediately writable to canonical assembler, unless it's already known
10161 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
10162 and to do this it cannot be followed by @samp{COMMON A}.
10164 @node Context-Sensitive Intrinsicness
10165 @subsection Context-Sensitive Intrinsicness
10166 @cindex intrinsics, context-sensitive
10167 @cindex context-sensitive intrinsics
10169 @command{g77} treats procedure references to @emph{possible} intrinsic
10170 names as always enabling their intrinsic nature, regardless of
10171 whether the @emph{form} of the reference is valid for that
10174 For example, @samp{CALL SQRT} is interpreted by @command{g77} as
10175 an invalid reference to the @code{SQRT} intrinsic function,
10176 because the reference is a subroutine invocation.
10178 First, @command{g77} recognizes the statement @samp{CALL SQRT}
10179 as a reference to a @emph{procedure} named @samp{SQRT}, not
10180 to a @emph{variable} with that name (as it would for a statement
10181 such as @samp{V = SQRT}).
10183 Next, @command{g77} establishes that, in the program unit being compiled,
10184 @code{SQRT} is an intrinsic---not a subroutine that
10185 happens to have the same name as an intrinsic (as would be
10186 the case if, for example, @samp{EXTERNAL SQRT} was present).
10188 Finally, @command{g77} recognizes that the @emph{form} of the
10189 reference is invalid for that particular intrinsic.
10190 That is, it recognizes that it is invalid for an intrinsic
10191 @emph{function}, such as @code{SQRT}, to be invoked as
10192 a @emph{subroutine}.
10194 At that point, @command{g77} issues a diagnostic.
10196 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
10197 references an external subroutine of their own, not an
10198 intrinsic function.
10200 However, @command{g77} knows about intrinsic
10201 subroutines, not just functions, and is able to support both having
10202 the same names, for example.
10204 As a result of this, @command{g77} rejects calls
10205 to intrinsics that are not subroutines, and function invocations
10206 of intrinsics that are not functions, just as it (and most compilers)
10207 rejects invocations of intrinsics with the wrong number (or types)
10210 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
10211 a user-written subroutine named @samp{SQRT}.
10213 @node Context-Sensitive Constants
10214 @subsection Context-Sensitive Constants
10215 @cindex constants, context-sensitive
10216 @cindex context-sensitive constants
10218 @command{g77} does not use context to determine the types of
10219 constants or named constants (@code{PARAMETER}), except
10220 for (non-standard) typeless constants such as @samp{'123'O}.
10222 For example, consider the following statement:
10225 PRINT *, 9.435784839284958 * 2D0
10229 @command{g77} will interpret the (truncated) constant
10230 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
10231 constant, because the suffix @code{D0} is not specified.
10233 As a result, the output of the above statement when
10234 compiled by @command{g77} will appear to have ``less precision''
10235 than when compiled by other compilers.
10237 In these and other cases, some compilers detect the
10238 fact that a single-precision constant is used in
10239 a double-precision context and therefore interpret the
10240 single-precision constant as if it was @emph{explicitly}
10241 specified as a double-precision constant.
10242 (This has the effect of appending @emph{decimal}, not
10243 @emph{binary}, zeros to the fractional part of the
10244 number---producing different computational results.)
10246 The reason this misfeature is dangerous is that a slight,
10247 apparently innocuous change to the source code can change
10248 the computational results.
10253 DOUBLE PRECISION FIVE
10254 PARAMETER (ALMOST = 5.000000000001)
10256 CLOSE = 5.000000000001
10257 PRINT *, 5.000000000001 - FIVE
10258 PRINT *, ALMOST - FIVE
10259 PRINT *, CLOSE - FIVE
10264 Running the above program should
10265 result in the same value being
10266 printed three times.
10267 With @command{g77} as the compiler,
10270 However, compiled by many other compilers,
10271 running the above program would print
10272 two or three distinct values, because
10273 in two or three of the statements, the
10274 constant @samp{5.000000000001}, which
10275 on most systems is exactly equal to @samp{5.}
10276 when interpreted as a single-precision constant,
10277 is instead interpreted as a double-precision
10278 constant, preserving the represented
10280 However, this ``clever'' promotion of
10281 type does not extend to variables or,
10282 in some compilers, to named constants.
10284 Since programmers often are encouraged to replace manifest
10285 constants or permanently-assigned variables with named
10286 constants (@code{PARAMETER} in Fortran), and might need
10287 to replace some constants with variables having the same
10288 values for pertinent portions of code,
10289 it is important that compilers treat code so modified in the
10290 same way so that the results of such programs are the same.
10291 @command{g77} helps in this regard by treating constants just
10292 the same as variables in terms of determining their types
10293 in a context-independent way.
10295 Still, there is a lot of existing Fortran code that has
10296 been written to depend on the way other compilers freely
10297 interpret constants' types based on context, so anything
10298 @command{g77} can do to help flag cases of this in such code
10299 could be very helpful.
10301 @node Equivalence Versus Equality
10302 @subsection Equivalence Versus Equality
10303 @cindex .EQV., with integer operands
10304 @cindex comparing logical expressions
10305 @cindex logical expressions, comparing
10307 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
10308 is not supported, except via @option{-fugly-logint}, which is not
10309 recommended except for legacy code (where the behavior expected
10310 by the @emph{code} is assumed).
10312 Legacy code should be changed, as resources permit, to use @code{.EQV.}
10313 and @code{.NEQV.} instead, as these are permitted by the various
10316 New code should never be written expecting @code{.EQ.} or @code{.NE.}
10317 to work if either of its operands is @code{LOGICAL}.
10319 The problem with supporting this ``feature'' is that there is
10320 unlikely to be consensus on how it works, as illustrated by the
10321 following sample program:
10325 DATA L,M,N /3*.FALSE./
10326 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
10330 The issue raised by the above sample program is: what is the
10331 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
10332 @code{LOGICAL} operands?
10334 Some programmers will argue that it is the same as the precedence
10335 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
10337 By this interpretation, the subexpression @samp{M.EQ.N} must be
10338 evaluated first in the above program, resulting in a program that,
10339 when run, does not execute the @code{PRINT} statement.
10341 Other programmers will argue that the precedence is the same as
10342 the precedence for @code{.EQV.}, which is restricted by the standards
10343 to @code{LOGICAL} operands.
10344 By this interpretation, the subexpression @samp{L.AND.M} must be
10345 evaluated first, resulting in a program that @emph{does} execute
10346 the @code{PRINT} statement.
10348 Assigning arbitrary semantic interpretations to syntactic expressions
10349 that might legitimately have more than one ``obvious'' interpretation
10350 is generally unwise.
10352 The creators of the various Fortran standards have done a good job
10353 in this case, requiring a distinct set of operators (which have their
10354 own distinct precedence) to compare @code{LOGICAL} operands.
10355 This requirement results in expression syntax with more certain
10356 precedence (without requiring substantial context), making it easier
10357 for programmers to read existing code.
10358 @command{g77} will avoid muddying up elements of the Fortran language
10359 that were well-designed in the first place.
10361 (Ask C programmers about the precedence of expressions such as
10362 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
10363 you, without knowing more context, whether the @samp{&} and @samp{-}
10364 operators are infix (binary) or unary!)
10366 Most dangerous of all is the fact that,
10367 even assuming consensus on its meaning,
10368 an expression like @samp{L.AND.M.EQ.N},
10369 if it is the result of a typographical error,
10370 doesn't @emph{look} like it has such a typo.
10371 Even experienced Fortran programmers would not likely notice that
10372 @samp{L.AND.M.EQV.N} was, in fact, intended.
10374 So, this is a prime example of a circumstance in which
10375 a quality compiler diagnoses the code,
10376 instead of leaving it up to someone debugging it
10377 to know to turn on special compiler options
10378 that might diagnose it.
10380 @node Order of Side Effects
10381 @subsection Order of Side Effects
10382 @cindex side effects, order of evaluation
10383 @cindex order of evaluation, side effects
10385 @command{g77} does not necessarily produce code that, when run, performs
10386 side effects (such as those performed by function invocations)
10387 in the same order as in some other compiler---or even in the same
10388 order as another version, port, or invocation (using different
10389 command-line options) of @command{g77}.
10391 It is never safe to depend on the order of evaluation of side effects.
10392 For example, an expression like this may very well behave differently
10393 from one compiler to another:
10396 J = IFUNC() - IFUNC()
10400 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
10402 Either invocation might happen first.
10403 If @samp{IFUNC} returns 5 the first time it is invoked, and
10404 returns 12 the second time, @samp{J} might end up with the
10405 value @samp{7}, or it might end up with @samp{-7}.
10407 Generally, in Fortran, procedures with side-effects intended to
10408 be visible to the caller are best designed as @emph{subroutines},
10410 Examples of such side-effects include:
10414 The generation of random numbers
10415 that are intended to influence return values.
10419 (other than internal I/O to local variables).
10422 Updating information in common blocks.
10425 An example of a side-effect that is not intended to be visible
10426 to the caller is a function that maintains a cache of recently
10427 calculated results, intended solely to speed repeated invocations
10428 of the function with identical arguments.
10429 Such a function can be safely used in expressions, because
10430 if the compiler optimizes away one or more calls to the
10431 function, operation of the program is unaffected (aside
10432 from being speeded up).
10434 @node Warnings and Errors
10435 @section Warning Messages and Error Messages
10437 @cindex error messages
10438 @cindex warnings vs errors
10439 @cindex messages, warning and error
10440 The GNU compiler can produce two kinds of diagnostics: errors and
10442 Each kind has a different purpose:
10446 @emph{Errors} report problems that make it impossible to compile your
10448 GNU Fortran reports errors with the source file name, line
10449 number, and column within the line where the problem is apparent.
10452 @emph{Warnings} report other unusual conditions in your code that
10453 @emph{might} indicate a problem, although compilation can (and does)
10455 Warning messages also report the source file name, line number,
10456 and column information,
10457 but include the text @samp{warning:} to distinguish them
10458 from error messages.
10461 Warnings might indicate danger points where you should check to make sure
10462 that your program really does what you intend; or the use of obsolete
10463 features; or the use of nonstandard features of GNU Fortran.
10464 Many warnings are issued only if you ask for them, with one of the
10465 @option{-W} options (for instance, @option{-Wall} requests a variety of
10468 @emph{Note:} Currently, the text of the line and a pointer to the column
10469 is printed in most @command{g77} diagnostics.
10470 Probably, as of version 0.6, @command{g77} will
10471 no longer print the text of the source line, instead printing
10472 the column number following the file name and line number in
10473 a form that GNU Emacs recognizes.
10474 This change is expected to speed up and reduce the memory usage
10475 of the @command{g77} compiler.
10477 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
10479 @c GNU Fortran always tries to compile your program if possible; it never
10480 @c gratuitously rejects a program whose meaning is clear merely because
10481 @c (for instance) it fails to conform to a standard. In some cases,
10482 @c however, the Fortran standard specifies that certain extensions are
10483 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
10484 @c compiler. The @option{-pedantic} option tells GNU Fortran to issue warnings
10485 @c in such cases; @option{-pedantic-errors} says to make them errors instead.
10486 @c This does not mean that @emph{all} non-ANSI constructs get warnings
10489 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
10490 more detail on these and related command-line options.
10492 @node Open Questions
10493 @chapter Open Questions
10495 Please consider offering useful answers to these questions!
10499 @code{LOC()} and other intrinsics are probably somewhat misclassified.
10500 Is the a need for more precise classification of intrinsics, and if so,
10501 what are the appropriate groupings?
10502 Is there a need to individually
10503 enable/disable/delete/hide intrinsics from the command line?
10507 @chapter Reporting Bugs
10509 @cindex reporting bugs
10511 Your bug reports play an essential role in making GNU Fortran reliable.
10513 When you encounter a problem, the first thing to do is to see if it is
10516 If it isn't known, then you should report the problem.
10518 Reporting a bug might help you by bringing a solution to your problem, or
10520 (If it does not, look in the service directory; see
10522 In any case, the principal function of a bug report is
10523 to help the entire community by making the next version of GNU Fortran work
10525 Bug reports are your contribution to the maintenance of GNU Fortran.
10527 Since the maintainers are very overloaded, we cannot respond to every
10529 However, if the bug has not been fixed, we are likely to
10530 send you a patch and ask you to tell us whether it works.
10532 In order for a bug report to serve its purpose, you must include the
10533 information that makes for fixing the bug.
10536 * Criteria: Bug Criteria. Have you really found a bug?
10537 * Where: Bug Lists. Where to send your bug report.
10538 * Reporting: Bug Reporting. How to report a bug effectively.
10541 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
10542 for information on problems we already know about.
10544 @xref{Service,,How To Get Help with GNU Fortran},
10545 for information on where to ask for help.
10548 @section Have You Found a Bug?
10549 @cindex bug criteria
10551 If you are not sure whether you have found a bug, here are some guidelines:
10554 @cindex fatal signal
10557 If the compiler gets a fatal signal, for any input whatever, that is a
10559 Reliable compilers never crash---they just remain obsolete.
10561 @cindex invalid assembly code
10562 @cindex assembly code, invalid
10564 If the compiler produces invalid assembly code, for any input whatever,
10565 @c (except an @code{asm} statement),
10566 that is a compiler bug, unless the
10567 compiler reports errors (not just warnings) which would ordinarily
10568 prevent the assembler from being run.
10570 @cindex undefined behavior
10571 @cindex undefined function value
10573 If the compiler produces valid assembly code that does not correctly
10574 execute the input source code, that is a compiler bug.
10576 However, you must double-check to make sure, because you might have run
10577 into an incompatibility between GNU Fortran and traditional Fortran.
10578 @c (@pxref{Incompatibilities}).
10579 These incompatibilities might be considered
10580 bugs, but they are inescapable consequences of valuable features.
10582 Or you might have a program whose behavior is undefined, which happened
10583 by chance to give the desired results with another Fortran compiler.
10584 It is best to check the relevant Fortran standard thoroughly if
10585 it is possible that the program indeed does something undefined.
10587 After you have localized the error to a single source line, it should
10588 be easy to check for these things.
10589 If your program is correct and well defined, you have found
10592 It might help if, in your submission, you identified the specific
10593 language in the relevant Fortran standard that specifies the
10594 desired behavior, if it isn't likely to be obvious and agreed-upon
10595 by all Fortran users.
10598 If the compiler produces an error message for valid input, that is a
10601 @cindex invalid input
10603 If the compiler does not produce an error message for invalid input,
10604 that is a compiler bug.
10605 However, you should note that your idea of
10606 ``invalid input'' might be someone else's idea
10607 of ``an extension'' or ``support for traditional practice''.
10610 If you are an experienced user of Fortran compilers, your suggestions
10611 for improvement of GNU Fortran are welcome in any case.
10614 Many, perhaps most, bug reports against @command{g77} turn out to
10615 be bugs in the user's code.
10616 While we find such bug reports educational, they sometimes take
10617 a considerable amount of time to track down or at least respond
10618 to---time we could be spending making @command{g77}, not some user's
10621 Some steps you can take to verify that the bug is not certainly
10622 in the code you're compiling with @command{g77}:
10626 Compile your code using the @command{g77} options @samp{-W -Wall -O}.
10627 These options enable many useful warning; the @option{-O} option
10628 enables flow analysis that enables the uninitialized-variable
10631 If you investigate the warnings and find evidence of possible bugs
10632 in your code, fix them first and retry @command{g77}.
10635 Compile your code using the @command{g77} options @option{-finit-local-zero},
10636 @option{-fno-automatic}, @option{-ffloat-store}, and various
10637 combinations thereof.
10639 If your code works with any of these combinations, that is not
10640 proof that the bug isn't in @command{g77}---a @command{g77} bug exposed
10641 by your code might simply be avoided, or have a different, more subtle
10642 effect, when different options are used---but it can be a
10643 strong indicator that your code is making unwarranted assumptions
10644 about the Fortran dialect and/or underlying machine it is
10645 being compiled and run on.
10647 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10648 for information on the @option{-fno-automatic} and
10649 @option{-finit-local-zero} options and how to convert
10650 their use into selective changes in your own code.
10654 Validate your code with @command{ftnchek} or a similar code-checking
10656 @command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
10657 or @uref{ftp://ftp.dsm.fordham.edu}.
10660 @cindex Makefile example
10661 Here are some sample @file{Makefile} rules using @command{ftnchek}
10662 ``project'' files to do cross-file checking and @command{sfmakedepend}
10663 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
10664 to maintain dependencies automatically.
10665 These assume the use of GNU @command{make}.
10668 # Dummy suffix for ftnchek targets:
10672 # How to compile .f files (for implicit rule):
10674 # Assume `include' directory:
10675 FFLAGS = -Iinclude -g -O -Wall
10677 # Flags for ftnchek:
10678 CHEK1 = -array=0 -include=includes -noarray
10679 CHEK2 = -nonovice -usage=1 -notruncation
10680 CHEKFLAGS = $(CHEK1) $(CHEK2)
10682 # Run ftnchek with all the .prj files except the one corresponding
10683 # to the target's root:
10685 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
10686 -noextern -library $<
10688 # Derive a project file from a source file:
10690 ftnchek $(CHEKFLAGS) -noextern -project -library $<
10692 # The list of objects is assumed to be in variable OBJS.
10693 # Sources corresponding to the objects:
10694 SRCS = $(OBJS:%.o=%.f)
10695 # ftnchek project files:
10696 PRJS = $(OBJS:%.o=%.prj)
10698 # Build the program
10700 $(FC) -o $@ $(OBJS)
10702 chekall: $(PRJS) ; \
10703 ftnchek $(CHEKFLAGS) $(PRJS)
10707 # For Emacs M-x find-tag:
10711 # Rebuild dependencies:
10713 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
10717 Try your code out using other Fortran compilers, such as @command{f2c}.
10718 If it does not work on at least one other compiler (assuming the
10719 compiler supports the features the code needs), that is a strong
10720 indicator of a bug in the code.
10722 However, even if your code works on many compilers @emph{except}
10723 @command{g77}, that does @emph{not} mean the bug is in @command{g77}.
10724 It might mean the bug is in your code, and that @command{g77} simply
10725 exposes it more readily than other compilers.
10729 @section Where to Report Bugs
10730 @cindex bug report mailing lists
10731 @kindex @value{email-bugs}
10732 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
10734 Often people think of posting bug reports to a newsgroup instead of
10736 This sometimes appears to work, but it has one problem which can be
10737 crucial: a newsgroup posting does not contain a mail path back to the
10739 Thus, if maintainers need more information, they might be unable
10740 to reach you. For this reason, you should always send bug reports by
10741 mail to the proper mailing list.
10743 As a last resort, send bug reports on paper to:
10747 Free Software Foundation
10748 59 Temple Place - Suite 330
10749 Boston, MA 02111-1307, USA
10752 @node Bug Reporting
10753 @section How to Report Bugs
10754 @cindex compiler bugs, reporting
10756 The fundamental principle of reporting bugs usefully is this:
10757 @strong{report all the facts}.
10758 If you are not sure whether to state a
10759 fact or leave it out, state it!
10761 Often people omit facts because they think they know what causes the
10762 problem and they conclude that some details don't matter.
10764 assume that the name of the variable you use in an example does not matter.
10765 Well, probably it doesn't, but one cannot be sure.
10766 Perhaps the bug is a
10767 stray memory reference which happens to fetch from the location where that
10768 name is stored in memory; perhaps, if the name were different, the contents
10769 of that location would fool the compiler into doing the right thing despite
10771 Play it safe and give a specific, complete example.
10773 easiest thing for you to do, and the most helpful.
10775 Keep in mind that the purpose of a bug report is to enable someone to
10776 fix the bug if it is not known.
10777 It isn't very important what happens if
10778 the bug is already known.
10779 Therefore, always write your bug reports on
10780 the assumption that the bug is not known.
10782 Sometimes people give a few sketchy facts and ask, ``Does this ring a
10784 This cannot help us fix a bug, so it is rarely helpful.
10785 We respond by asking for enough details to enable us to investigate.
10786 You might as well expedite matters by sending them to begin with.
10787 (Besides, there are enough bells ringing around here as it is.)
10789 Try to make your bug report self-contained.
10790 If we have to ask you for
10791 more information, it is best if you include all the previous information
10792 in your response, as well as the information that was missing.
10794 Please report each bug in a separate message.
10795 This makes it easier for
10796 us to track which bugs have been fixed and to forward your bugs reports
10797 to the appropriate maintainer.
10799 Do not compress and encode any part of your bug report using programs
10800 such as @file{uuencode}.
10801 If you do so it will slow down the processing
10803 If you must submit multiple large files, use @file{shar},
10804 which allows us to read your message without having to run any
10805 decompression programs.
10807 (As a special exception for GNU Fortran bug-reporting, at least
10808 for now, if you are sending more than a few lines of code, if
10809 your program's source file format contains ``interesting'' things
10810 like trailing spaces or strange characters, or if you need to
10811 include binary data files, it is acceptable to put all the
10812 files together in a @command{tar} archive, and, whether you need to
10813 do that, it is acceptable to then compress the single file (@command{tar}
10814 archive or source file)
10815 using @command{gzip} and encode it via @command{uuencode}.
10816 Do not use any MIME stuff---the current maintainer can't decode this.
10817 Using @command{compress} instead of @command{gzip} is acceptable, assuming
10818 you have licensed the use of the patented algorithm in
10819 @command{compress} from Unisys.)
10821 To enable someone to investigate the bug, you should include all these
10826 The version of GNU Fortran.
10827 You can get this by running @command{g77} with the @option{-v} option.
10828 (Ignore any error messages that might be displayed
10829 when the linker is run.)
10831 Without this, we won't know whether there is any point in looking for
10832 the bug in the current version of GNU Fortran.
10835 @cindex preprocessor
10836 @cindex cpp program
10837 @cindex programs, cpp
10839 A complete input file that will reproduce the bug.
10841 If your source file(s) require preprocessing
10842 (for example, their names have suffixes like
10843 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
10844 and the bug is in the compiler proper (@file{f771})
10845 or in a subsequent phase of processing,
10846 run your source file through the C preprocessor
10847 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
10848 Then, include the contents of @var{newfile} in the bug report.
10849 (When you do this, use the same preprocessor options---such as
10850 @option{-I}, @option{-D}, and @option{-U}---that you used in actual
10853 A single statement is not enough of an example.
10854 In order to compile it,
10855 it must be embedded in a complete file of compiler input.
10856 The bug might depend on the details of how this is done.
10858 Without a real example one can compile,
10859 all anyone can do about your bug report is wish you luck.
10860 It would be futile to try to guess how to provoke the bug.
10861 For example, bugs in register allocation and reloading
10862 can depend on every little detail of the source and include files
10866 @cindex included files
10867 @cindex INCLUDE directive
10868 @cindex directive, INCLUDE
10869 @cindex #include directive
10870 @cindex directive, #include
10871 Note that you should include with your bug report any files
10872 included by the source file
10873 (via the @code{#include} or @code{INCLUDE} directive)
10874 that you send, and any files they include, and so on.
10876 It is not necessary to replace
10877 the @code{#include} and @code{INCLUDE} directives
10878 with the actual files in the version of the source file that
10879 you send, but it might make submitting the bug report easier
10881 However, be sure to @emph{reproduce} the bug using the @emph{exact}
10882 version of the source material you submit, to avoid wild-goose
10886 The command arguments you gave GNU Fortran to compile that example
10887 and observe the bug. For example, did you use @option{-O}? To guarantee
10888 you won't omit something important, list all the options.
10890 If we were to try to guess the arguments, we would probably guess wrong
10891 and then we would not encounter the bug.
10894 The type of machine you are using, and the operating system name and
10896 (Much of this information is printed by @samp{g77 -v}---if you
10897 include that, send along any additional info you have that you
10898 don't see clearly represented in that output.)
10901 The operands you gave to the @command{configure} command when you installed
10905 A complete list of any modifications you have made to the compiler
10906 source. (We don't promise to investigate the bug unless it happens in
10907 an unmodified compiler. But if you've made modifications and don't tell
10908 us, then you are sending us on a wild-goose chase.)
10910 Be precise about these changes. A description in English is not
10911 enough---send a context diff for them.
10913 Adding files of your own (such as a machine description for a machine we
10914 don't support) is a modification of the compiler source.
10917 Details of any other deviations from the standard procedure for installing
10921 A description of what behavior you observe that you believe is
10922 incorrect. For example, ``The compiler gets a fatal signal,'' or,
10923 ``The assembler instruction at line 208 in the output is incorrect.''
10925 Of course, if the bug is that the compiler gets a fatal signal, then one
10926 can't miss it. But if the bug is incorrect output, the maintainer might
10927 not notice unless it is glaringly wrong. None of us has time to study
10928 all the assembler code from a 50-line Fortran program just on the chance that
10929 one instruction might be wrong. We need @emph{you} to do this part!
10931 Even if the problem you experience is a fatal signal, you should still
10932 say so explicitly. Suppose something strange is going on, such as, your
10933 copy of the compiler is out of synch, or you have encountered a bug in
10934 the C library on your system. (This has happened!) Your copy might
10935 crash and the copy here would not. If you @i{said} to expect a crash,
10936 then when the compiler here fails to crash, we would know that the bug
10937 was not happening. If you don't say to expect a crash, then we would
10938 not know whether the bug was happening. We would not be able to draw
10939 any conclusion from our observations.
10941 If the problem is a diagnostic when building GNU Fortran with some other
10942 compiler, say whether it is a warning or an error.
10944 Often the observed symptom is incorrect output when your program is run.
10945 Sad to say, this is not enough information unless the program is short
10946 and simple. None of us has time to study a large program to figure out
10947 how it would work if compiled correctly, much less which line of it was
10948 compiled wrong. So you will have to do that. Tell us which source line
10949 it is, and what incorrect result happens when that line is executed. A
10950 person who understands the program can find this as easily as finding a
10951 bug in the program itself.
10954 If you send examples of assembler code output from GNU Fortran,
10955 please use @option{-g} when you make them. The debugging information
10956 includes source line numbers which are essential for correlating the
10957 output with the input.
10960 If you wish to mention something in the GNU Fortran source, refer to it by
10961 context, not by line number.
10963 The line numbers in the development sources don't match those in your
10964 sources. Your line numbers would convey no convenient information to the
10968 Additional information from a debugger might enable someone to find a
10969 problem on a machine which he does not have available. However, you
10970 need to think when you collect this information if you want it to have
10971 any chance of being useful.
10973 @cindex backtrace for bug reports
10974 For example, many people send just a backtrace, but that is never
10975 useful by itself. A simple backtrace with arguments conveys little
10976 about GNU Fortran because the compiler is largely data-driven; the same
10977 functions are called over and over for different RTL insns, doing
10978 different things depending on the details of the insn.
10980 Most of the arguments listed in the backtrace are useless because they
10981 are pointers to RTL list structure. The numeric values of the
10982 pointers, which the debugger prints in the backtrace, have no
10983 significance whatever; all that matters is the contents of the objects
10984 they point to (and most of the contents are other such pointers).
10986 In addition, most compiler passes consist of one or more loops that
10987 scan the RTL insn sequence. The most vital piece of information about
10988 such a loop---which insn it has reached---is usually in a local variable,
10989 not in an argument.
10992 What you need to provide in addition to a backtrace are the values of
10993 the local variables for several stack frames up. When a local
10994 variable or an argument is an RTX, first print its value and then use
10995 the GDB command @command{pr} to print the RTL expression that it points
10996 to. (If GDB doesn't run on your machine, use your debugger to call
10997 the function @code{debug_rtx} with the RTX as an argument.) In
10998 general, whenever a variable is a pointer, its value is no use
10999 without the data it points to.
11002 Here are some things that are not necessary:
11006 A description of the envelope of the bug.
11008 Often people who encounter a bug spend a lot of time investigating
11009 which changes to the input file will make the bug go away and which
11010 changes will not affect it.
11012 This is often time consuming and not very useful, because the way we
11013 will find the bug is by running a single example under the debugger with
11014 breakpoints, not by pure deduction from a series of examples. You might
11015 as well save your time for something else.
11017 Of course, if you can find a simpler example to report @emph{instead} of
11018 the original one, that is a convenience. Errors in the output will be
11019 easier to spot, running under the debugger will take less time, etc.
11020 Most GNU Fortran bugs involve just one function, so the most straightforward
11021 way to simplify an example is to delete all the function definitions
11022 except the one where the bug occurs. Those earlier in the file may be
11023 replaced by external declarations if the crucial function depends on
11024 them. (Exception: inline functions might affect compilation of functions
11025 defined later in the file.)
11027 However, simplification is not vital; if you don't want to do this,
11028 report the bug anyway and send the entire test case you used.
11031 In particular, some people insert conditionals @samp{#ifdef BUG} around
11032 a statement which, if removed, makes the bug not happen. These are just
11033 clutter; we won't pay any attention to them anyway. Besides, you should
11034 send us preprocessor output, and that can't have conditionals.
11037 A patch for the bug.
11039 A patch for the bug is useful if it is a good one. But don't omit the
11040 necessary information, such as the test case, on the assumption that a
11041 patch is all we need. We might see problems with your patch and decide
11042 to fix the problem another way, or we might not understand it at all.
11044 Sometimes with a program as complicated as GNU Fortran it is very hard to
11045 construct an example that will make the program follow a certain path
11046 through the code. If you don't send the example, we won't be able to
11047 construct one, so we won't be able to verify that the bug is fixed.
11049 And if we can't understand what bug you are trying to fix, or why your
11050 patch should be an improvement, we won't install it. A test case will
11051 help us to understand.
11053 See @uref{http://gcc.gnu.org/contribute.html}
11054 for guidelines on how to make it easy for us to
11055 understand and install your patches.
11058 A guess about what the bug is or what it depends on.
11060 Such guesses are usually wrong. Even the maintainer can't guess right
11061 about such things without first using the debugger to find the facts.
11066 We have no way of examining a core dump for your type of machine
11067 unless we have an identical system---and if we do have one,
11068 we should be able to reproduce the crash ourselves.
11072 @chapter How To Get Help with GNU Fortran
11074 If you need help installing, using or changing GNU Fortran, there are two
11079 Look in the service directory for someone who might help you for a fee.
11080 The service directory is found in the file named @file{SERVICE} in the
11081 GNU CC distribution.
11084 Send a message to @email{@value{email-help}}.
11089 @node Adding Options
11090 @chapter Adding Options
11091 @cindex options, adding
11092 @cindex adding options
11094 To add a new command-line option to @command{g77}, first decide
11095 what kind of option you wish to add.
11096 Search the @command{g77} and @command{gcc} documentation for one
11097 or more options that is most closely like the one you want to add
11098 (in terms of what kind of effect it has, and so on) to
11099 help clarify its nature.
11103 @emph{Fortran options} are options that apply only
11104 when compiling Fortran programs.
11105 They are accepted by @command{g77} and @command{gcc}, but
11106 they apply only when compiling Fortran programs.
11109 @emph{Compiler options} are options that apply
11110 when compiling most any kind of program.
11113 @emph{Fortran options} are listed in the file
11114 @file{@value{path-g77}/lang-options.h},
11115 which is used during the build of @command{gcc} to
11116 build a list of all options that are accepted by
11117 at least one language's compiler.
11118 This list goes into the @code{documented_lang_options} array
11119 in @file{gcc/toplev.c}, which uses this array to
11120 determine whether a particular option should be
11121 offered to the linked-in front end for processing
11122 by calling @code{lang_option_decode}, which, for
11123 @command{g77}, is in @file{@value{path-g77}/com.c} and just
11124 calls @code{ffe_decode_option}.
11126 If the linked-in front end ``rejects'' a
11127 particular option passed to it, @file{toplev.c}
11128 just ignores the option, because @emph{some}
11129 language's compiler is willing to accept it.
11131 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
11132 to work, even though Fortran compilation does
11133 not currently support the @option{-fno-asm} option;
11134 even though the @code{f771} version of @code{lang_decode_option}
11135 rejects @option{-fno-asm}, @file{toplev.c} doesn't
11136 produce a diagnostic because some other language (C)
11139 This also means that commands like
11140 @samp{g77 -fno-asm foo.f} yield no diagnostics,
11141 despite the fact that no phase of the command was
11142 able to recognize and process @option{-fno-asm}---perhaps
11143 a warning about this would be helpful if it were
11146 Code that processes Fortran options is found in
11147 @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
11148 This code needs to check positive and negative forms
11151 The defaults for Fortran options are set in their
11152 global definitions, also found in @file{@value{path-g77}/top.c}.
11153 Many of these defaults are actually macros defined
11154 in @file{@value{path-g77}/target.h}, since they might be
11156 However, since, in practice, GNU compilers
11157 should behave the same way on all configurations
11158 (especially when it comes to language constructs),
11159 the practice of setting defaults in @file{target.h}
11160 is likely to be deprecated and, ultimately, stopped
11161 in future versions of @command{g77}.
11163 Accessor macros for Fortran options, used by code
11164 in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
11166 @emph{Compiler options} are listed in @file{gcc/toplev.c}
11167 in the array @code{f_options}.
11168 An option not listed in @code{lang_options} is
11169 looked up in @code{f_options} and handled from there.
11171 The defaults for compiler options are set in the
11172 global definitions for the corresponding variables,
11173 some of which are in @file{gcc/toplev.c}.
11175 You can set different defaults for @emph{Fortran-oriented}
11176 or @emph{Fortran-reticent} compiler options by changing
11177 the source code of @command{g77} and rebuilding.
11178 How to do this depends on the version of @command{g77}:
11181 @item G77 0.5.24 (EGCS 1.1)
11182 @itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
11183 Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.
11185 (Note that these versions of @command{g77}
11186 perform internal consistency checking automatically
11187 when the @option{-fversion} option is specified.)
11190 @itemx G77 0.5.24 (EGCS 1.0)
11191 Change the way @code{f771} handles the @option{-fset-g77-defaults}
11192 option, which is always provided as the first option when
11193 called by @command{g77} or @command{gcc}.
11195 This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
11196 Have it change just the variables that you want to default
11197 to a different setting for Fortran compiles compared to
11198 compiles of other languages.
11200 The @option{-fset-g77-defaults} option is passed to @code{f771}
11201 automatically because of the specification information
11202 kept in @file{@value{path-g77}/lang-specs.h}.
11203 This file tells the @command{gcc} command how to recognize,
11204 in this case, Fortran source files (those to be preprocessed,
11205 and those that are not), and further, how to invoke the
11206 appropriate programs (including @code{f771}) to process
11207 those source files.
11209 It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults},
11210 @option{-fversion}, and other options are passed, as appropriate,
11211 even when the user has not explicitly specified them.
11212 Other ``internal'' options such as @option{-quiet} also
11213 are passed via this mechanism.
11220 If you want to contribute to @command{g77} by doing research,
11221 design, specification, documentation, coding, or testing,
11222 the following information should give you some ideas.
11223 More relevant information might be available from
11224 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
11227 * Efficiency:: Make @command{g77} itself compile code faster.
11228 * Better Optimization:: Teach @command{g77} to generate faster code.
11229 * Simplify Porting:: Make @command{g77} easier to configure, build,
11231 * More Extensions:: Features many users won't know to ask for.
11232 * Machine Model:: @command{g77} should better leverage @command{gcc}.
11233 * Internals Documentation:: Make maintenance easier.
11234 * Internals Improvements:: Make internals more robust.
11235 * Better Diagnostics:: Make using @command{g77} on new code easier.
11239 @section Improve Efficiency
11242 Don't bother doing any performance analysis until most of the
11243 following items are taken care of, because there's no question
11244 they represent serious space/time problems, although some of
11245 them show up only given certain kinds of (popular) input.
11249 Improve @code{malloc} package and its uses to specify more info about
11250 memory pools and, where feasible, use obstacks to implement them.
11253 Skip over uninitialized portions of aggregate areas (arrays,
11254 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
11255 This would reduce memory usage for large initialized aggregate
11256 areas, even ones with only one initialized element.
11258 As of version 0.5.18, a portion of this item has already been
11262 Prescan the statement (in @file{sta.c}) so that the nature of the statement
11263 is determined as much as possible by looking entirely at its form,
11264 and not looking at any context (previous statements, including types
11266 This would allow ripping out of the statement-confirmation,
11267 symbol retraction/confirmation, and diagnostic inhibition
11269 Plus, it would result in much-improved diagnostics.
11270 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
11271 is not a subroutine intrinsic, would result actual error instead of the
11272 unimplemented-statement catch-all.
11275 Throughout @command{g77}, don't pass line/column pairs where
11276 a simple @code{ffewhere} type, which points to the error as much as is
11277 desired by the configuration, will do, and don't pass @code{ffelexToken} types
11278 where a simple @code{ffewhere} type will do.
11279 Then, allow new default
11280 configuration of @code{ffewhere} such that the source line text is not
11281 preserved, and leave it to things like Emacs' next-error function
11282 to point to them (now that @samp{next-error} supports column,
11283 or, perhaps, character-offset, numbers).
11284 The change in calling sequences should improve performance somewhat,
11285 as should not having to save source lines.
11286 (Whether this whole
11287 item will improve performance is questionable, but it should
11288 improve maintainability.)
11291 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
11292 as regards the assembly output.
11293 Some of this might require improving
11294 the back end, but lots of improvement in space/time required in @command{g77}
11295 itself can be fairly easily obtained without touching the back end.
11296 Maybe type-conversion, where necessary, can be speeded up as well in
11297 cases like the one shown (converting the @samp{2} into @samp{2.}).
11300 If analysis shows it to be worthwhile, optimize @file{lex.c}.
11303 Consider redesigning @file{lex.c} to not need any feedback
11304 during tokenization, by keeping track of enough parse state on its
11308 @node Better Optimization
11309 @section Better Optimization
11310 @cindex optimization, better
11311 @cindex code generation, improving
11313 Much of this work should be put off until after @command{g77} has
11314 all the features necessary for its widespread acceptance as a
11315 useful F77 compiler.
11316 However, perhaps this work can be done in parallel during
11317 the feature-adding work.
11321 Do the equivalent of the trick of putting @samp{extern inline} in front
11322 of every function definition in @code{libg2c} and #include'ing the resulting
11323 file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions
11324 that are at all worth inlining.
11325 (Some of this has already been done, such as for integral exponentiation.)
11328 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
11329 and it's clear that types line up
11330 and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
11331 make @samp{CHAR_VAR}, not a
11332 temporary, be the receiver for @samp{CHAR_FUNC}.
11333 (This is now done for @code{COMPLEX} variables.)
11336 Design and implement Fortran-specific optimizations that don't
11337 really belong in the back end, or where the front end needs to
11338 give the back end more info than it currently does.
11341 Design and implement a new run-time library interface, with the
11342 code going into @code{libgcc} so no special linking is required to
11343 link Fortran programs using standard language features.
11345 would speed up lots of things, from I/O (using precompiled formats,
11346 doing just one, or, at most, very few, calls for arrays or array sections,
11347 and so on) to general computing (array/section implementations of
11348 various intrinsics, implementation of commonly performed loops that
11349 aren't likely to be optimally compiled otherwise, etc.).
11351 Among the important things the library would do are:
11355 Be a one-stop-shop-type
11356 library, hence shareable and usable by all, in that what are now
11357 library-build-time options in @code{libg2c} would be moved at least to the
11358 @command{g77} compile phase, if not to finer grains (such as choosing how
11359 list-directed I/O formatting is done by default at @code{OPEN} time, for
11360 preconnected units via options or even statements in the main program
11361 unit, maybe even on a per-I/O basis with appropriate pragma-like
11366 Probably requiring the new library design, change interface to
11367 normally have @code{COMPLEX} functions return their values in the way
11368 @command{gcc} would if they were declared @code{__complex__ float},
11370 the mechanism currently used by @code{CHARACTER} functions (whereby the
11371 functions are compiled as returning void and their first arg is
11372 a pointer to where to store the result).
11373 (Don't append underscores to
11374 external names for @code{COMPLEX} functions in some cases once @command{g77} uses
11375 @command{gcc} rather than @command{f2c} calling conventions.)
11378 Do something useful with @code{doiter} references where possible.
11379 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
11380 a @code{DO} loop that uses @samp{I} as the
11381 iteration variable, and the back end might find that info useful
11382 in determining whether it needs to read @samp{I} back into a register after
11384 (It normally has to do that, unless it knows @samp{FOO} never
11385 modifies its passed-by-reference argument, which is rarely the case
11386 for Fortran-77 code.)
11389 @node Simplify Porting
11390 @section Simplify Porting
11391 @cindex porting, simplify
11392 @cindex simplify porting
11394 Making @command{g77} easier to configure, port, build, and install, either
11395 as a single-system compiler or as a cross-compiler, would be
11400 A new library (replacing @code{libg2c}) should improve portability as well as
11401 produce more optimal code.
11402 Further, @command{g77} and the new library should
11403 conspire to simplify naming of externals, such as by removing unnecessarily
11404 added underscores, and to reduce/eliminate the possibility of naming
11405 conflicts, while making debugger more straightforward.
11408 make multi-language applications more feasible, such as by providing
11409 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
11413 Possibly related to a new library, @command{g77} should produce the equivalent
11414 of a @command{gcc} @samp{main(argc, argv)} function when it compiles a
11415 main program unit, instead of compiling something that must be
11416 called by a library
11417 implementation of @code{main()}.
11419 This would do many useful things such as
11420 provide more flexibility in terms of setting up exception handling,
11421 not requiring programmers to start their debugging sessions with
11422 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
11425 The GBE needs to understand the difference between alignment
11426 requirements and desires.
11427 For example, on Intel x86 machines, @command{g77} currently imposes
11428 overly strict alignment requirements, due to the back end, but it
11429 would be useful for Fortran and C programmers to be able to override
11430 these @emph{recommendations} as long as they don't violate the actual
11431 processor @emph{requirements}.
11434 @node More Extensions
11435 @section More Extensions
11436 @cindex extensions, more
11438 These extensions are not the sort of things users ask for ``by name'',
11439 but they might improve the usability of @command{g77}, and Fortran in
11440 general, in the long run.
11441 Some of these items really pertain to improving @command{g77} internals
11442 so that some popular extensions can be more easily supported.
11446 Look through all the documentation on the GNU Fortran language,
11447 dialects, compiler, missing features, bugs, and so on.
11448 Many mentions of incomplete or missing features are
11449 sprinkled throughout.
11450 It is not worth repeating them here.
11453 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
11455 The idea is to provide a forward-looking, effective
11456 replacement for things like the old-style @code{PARAMETER} statement
11458 really need typelessness in a maintainable, portable, clearly documented
11460 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
11461 and whatever else might come along.
11462 (This is not really a call for polymorphism per se, just
11463 an ability to express limited, syntactic polymorphism.)
11466 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
11469 Support arbitrary file unit numbers, instead of limiting them
11470 to 0 through @samp{MXUNIT-1}.
11471 (This is a @code{libg2c} issue.)
11474 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
11475 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
11476 later @code{UNIT=} in the first example is invalid.
11477 Make sure this is what users of this feature would expect.
11480 Currently @command{g77} disallows @samp{READ(1'10)} since
11481 it is an obnoxious syntax, but
11482 supporting it might be pretty easy if needed.
11483 More details are needed, such
11484 as whether general expressions separated by an apostrophe are supported,
11485 or maybe the record number can be a general expression, and so on.
11488 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
11490 Currently there is no support at all
11491 for @code{%FILL} in @code{STRUCTURE} and related syntax,
11492 whereas the rest of the
11493 stuff has at least some parsing support.
11494 This requires either major
11495 changes to @code{libg2c} or its replacement.
11498 F90 and @command{g77} probably disagree about label scoping relative to
11499 @code{INTERFACE} and @code{END INTERFACE}, and their contained
11500 procedure interface bodies (blocks?).
11503 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
11504 since that was added after S8.112.
11507 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
11508 with the final form of the standard (it was vague at S8.112).
11511 It seems to be an ``open'' question whether a file, immediately after being
11512 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
11513 might be nice to offer an option of opening to ``undefined'' status, requiring
11514 an explicit absolute-positioning operation to be performed before any
11515 other (besides @code{CLOSE}) to assist in making applications port to systems
11516 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
11519 @node Machine Model
11520 @section Machine Model
11522 This items pertain to generalizing @command{g77}'s view of
11523 the machine model to more fully accept whatever the GBE
11524 provides it via its configuration.
11528 Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
11529 exclusively so the target float format need not be required.
11531 means changing the way @command{g77} handles initialization of aggregate areas
11532 having more than one type, such as @code{REAL} and @code{INTEGER},
11534 it initializes them as if they were arrays of @code{char} and uses the
11535 bit patterns of the constants of the various types in them to determine
11536 what to stuff in elements of the arrays.
11539 Rely more and more on back-end info and capabilities, especially in the
11540 area of constants (where having the @command{g77} front-end's IL just store
11541 the appropriate tree nodes containing constants might be best).
11544 Suite of C and Fortran programs that a user/administrator can run on a
11545 machine to help determine the configuration for @command{g77} before building
11546 and help determine if the compiler works (especially with whatever
11547 libraries are installed) after building.
11550 @node Internals Documentation
11551 @section Internals Documentation
11553 Better info on how @command{g77} works and how to port it is needed.
11554 Much of this should be done only after the redesign planned for
11557 @xref{Front End}, which contains some information
11558 on @command{g77} internals.
11560 @node Internals Improvements
11561 @section Internals Improvements
11563 Some more items that would make @command{g77} more reliable
11564 and easier to maintain:
11568 Generally make expression handling focus
11569 more on critical syntax stuff, leaving semantics to callers.
11571 anything a caller can check, semantically, let it do so, rather
11572 than having @file{expr.c} do it.
11573 (Exceptions might include things like
11574 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
11576 important to preserve the left-to-right-in-source order of production
11580 Come up with better naming conventions for @option{-D} to establish requirements
11581 to achieve desired implementation dialect via @file{proj.h}.
11584 Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
11587 Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
11590 Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
11591 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
11592 (after determining if there is indeed no real need for it).
11595 Utility to read and check @file{bad.def} messages and their references in the
11596 code, to make sure calls are consistent with message templates.
11599 Search and fix @samp{&ffe@dots{}} and similar so that
11600 @samp{ffe@dots{}ptr@dots{}} macros are
11601 available instead (a good argument for wishing this could have written all
11602 this stuff in C++, perhaps).
11603 On the other hand, it's questionable whether this sort of
11604 improvement is really necessary, given the availability of
11605 tools such as Emacs and Perl, which make finding any
11606 address-taking of structure members easy enough?
11609 Some modules truly export the member names of their structures (and the
11610 structures themselves), maybe fix this, and fix other modules that just
11611 appear to as well (by appending @samp{_}, though it'd be ugly and probably
11612 not worth the time).
11615 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
11617 and use them throughout @command{g77} source code (especially in the definitions
11618 of access macros in @samp{.h} files) so they can be tailored
11619 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
11622 Decorate throughout with @code{const} and other such stuff.
11625 All F90 notational derivations in the source code are still based
11626 on the S8.112 version of the draft standard.
11627 Probably should update
11628 to the official standard, or put documentation of the rules as used
11629 in the code@dots{}uh@dots{}in the code.
11632 Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
11633 inside but invoked via paths not involving @code{ffeexpr_lhs} or
11634 @code{ffeexpr_rhs}) might be creating things
11635 in improper pools, leading to such things staying around too long or
11636 (doubtful, but possible and dangerous) not long enough.
11639 Some @code{ffebld_list_new} (or whatever) calls might not be matched by
11640 @code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
11641 (It definitely is not a problem just yet.)
11644 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
11645 due to alignment/mismatch or other problems---they end up without
11646 @code{ffestorag} objects, so maybe the backend (and other parts of the front
11647 end) can notice that and handle like an @code{opANY} (do what it wants, just
11648 don't complain or crash).
11649 Most of this seems to have been addressed
11650 by now, but a code review wouldn't hurt.
11653 @node Better Diagnostics
11654 @section Better Diagnostics
11656 These are things users might not ask about, or that need to
11657 be looked into, before worrying about.
11658 Also here are items that involve reducing unnecessary diagnostic
11663 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
11664 lengths, type classes, and so on),
11665 @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
11669 Speed up and improve error handling for data when repeat-count is
11671 For example, don't output 20 unnecessary messages after the
11672 first necessary one for:
11677 DATA (X(I), J= 1, 20) /20*5/
11682 (The @code{CONTINUE} statement ensures the @code{DATA} statement
11683 is processed in the context of executable, not specification,
11693 @chapter Diagnostics
11694 @cindex diagnostics
11696 Some diagnostics produced by @command{g77} require sufficient explanation
11697 that the explanations are given below, and the diagnostics themselves
11698 identify the appropriate explanation.
11700 Identification uses the GNU Info format---specifically, the @command{info}
11701 command that displays the explanation is given within square
11702 brackets in the diagnostic.
11706 foo.f:5: Invalid statement [info -f g77 M FOOEY]
11709 More details about the above diagnostic is found in the @command{g77} Info
11710 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
11711 which is displayed by typing the UNIX command
11712 @samp{info -f g77 M FOOEY}.
11714 Other Info readers, such as EMACS, may be just as easily used to display
11715 the pertinent node.
11716 In the above example, @samp{g77} is the Info document name,
11717 @samp{M} is the top-level menu item to select,
11718 and, in that node (named @samp{Diagnostics}, the name of
11719 this chapter, which is the very text you're reading now),
11720 @samp{FOOEY} is the menu item to select.
11723 In this printed version of the @command{g77} manual, the above example
11724 points to a section, below, entitled @samp{FOOEY}---though, of course,
11725 as the above is just a sample, no such section exists.
11729 * CMPAMBIG:: Ambiguous use of intrinsic.
11730 * EXPIMP:: Intrinsic used explicitly and implicitly.
11731 * INTGLOB:: Intrinsic also used as name of global.
11732 * LEX:: Various lexer messages
11733 * GLOBALS:: Disagreements about globals.
11734 * LINKFAIL:: When linking @code{f771} fails.
11735 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
11739 @section @code{CMPAMBIG}
11743 Ambiguous use of intrinsic @var{intrinsic} @dots{}
11746 The type of the argument to the invocation of the @var{intrinsic}
11747 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
11748 Typically, it is @code{COMPLEX(KIND=2)}, also known as
11749 @code{DOUBLE COMPLEX}.
11751 The interpretation of this invocation depends on the particular
11752 dialect of Fortran for which the code was written.
11753 Some dialects convert the real part of the argument to
11754 @code{REAL(KIND=1)}, thus losing precision; other dialects,
11755 and Fortran 90, do no such conversion.
11757 So, GNU Fortran rejects such invocations except under certain
11758 circumstances, to avoid making an incorrect assumption that results
11759 in generating the wrong code.
11761 To determine the dialect of the program unit, perhaps even whether
11762 that particular invocation is properly coded, determine how the
11763 result of the intrinsic is used.
11765 The result of @var{intrinsic} is expected (by the original programmer)
11766 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
11770 It is passed as an argument to a procedure that explicitly or
11771 implicitly declares that argument @code{REAL(KIND=1)}.
11774 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
11775 statement specifying the dummy argument corresponding to an
11776 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
11777 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
11778 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
11779 of @code{REAL(KIND=2)}.
11782 It is used in a context that would otherwise not include
11783 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
11784 invocation as @code{REAL(KIND=2)} would result in unnecessary
11785 promotions and (typically) more expensive operations on the
11796 The above example suggests the programmer expected the real part
11797 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
11798 multiplied by @samp{T} (presumed, along with @samp{R} above, to
11799 be type @code{REAL(KIND=1)}).
11801 Otherwise, the conversion would have to be delayed until after
11802 the multiplication, requiring not only an extra conversion
11803 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
11804 expensive multiplication (a double-precision multiplication instead
11805 of a single-precision one).
11808 The result of @var{intrinsic} is expected (by the original programmer)
11809 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
11813 It is passed as an argument to a procedure that explicitly or
11814 implicitly declares that argument @code{REAL(KIND=2)}.
11816 For example, a procedure specifying a @code{DOUBLE PRECISION}
11817 dummy argument corresponding to an
11818 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
11819 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
11820 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
11821 of @code{REAL(KIND=1)}.
11824 It is used in an expression context that includes
11825 other @code{REAL(KIND=2)} operands,
11826 or is assigned to a @code{REAL(KIND=2)} variable or array element.
11832 DOUBLE PRECISION R, T
11837 The above example suggests the programmer expected the real part
11838 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
11839 by the @code{REAL()} intrinsic.
11841 Otherwise, the conversion would have to be immediately followed
11842 by a conversion back to @code{REAL(KIND=2)}, losing
11843 the original, full precision of the real part of @code{Z},
11844 before being multiplied by @samp{T}.
11847 Once you have determined whether a particular invocation of @var{intrinsic}
11848 expects the Fortran 90 interpretation, you can:
11852 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
11853 @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
11855 if it expected the Fortran 90 interpretation.
11857 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
11858 some other type, such as @code{COMPLEX*32}, you should use the
11859 appropriate intrinsic, such as the one to convert to @code{REAL*16}
11860 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
11861 @code{QIMAG()} in place of @code{DIMAG()}).
11864 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
11866 This converts to @code{REAL(KIND=1)} in all working
11870 If you don't want to change the code, and you are certain that all
11871 ambiguous invocations of @var{intrinsic} in the source file have
11872 the same expectation regarding interpretation, you can:
11876 Compile with the @command{g77} option @option{-ff90}, to enable the
11877 Fortran 90 interpretation.
11880 Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex},
11881 to enable the non-Fortran-90 interpretations.
11884 @xref{REAL() and AIMAG() of Complex}, for more information on this
11887 Note: If the above suggestions don't produce enough evidence
11888 as to whether a particular program expects the Fortran 90
11889 interpretation of this ambiguous invocation of @var{intrinsic},
11890 there is one more thing you can try.
11892 If you have access to most or all the compilers used on the
11893 program to create successfully tested and deployed executables,
11894 read the documentation for, and @emph{also} test out, each compiler
11895 to determine how it treats the @var{intrinsic} intrinsic in
11897 (If all the compilers don't agree on an interpretation, there
11898 might be lurking bugs in the deployed versions of the program.)
11900 The following sample program might help:
11902 @cindex JCB003 program
11906 C Written by James Craig Burley 1997-02-23.
11908 C Determine how compilers handle non-standard REAL
11909 C and AIMAG on DOUBLE COMPLEX operands.
11917 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
11918 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
11922 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
11923 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
11926 C Just to make sure compiler doesn't use naive flow
11927 C analysis to optimize away careful work above,
11928 C which might invalidate results....
11930 SUBROUTINE DUMDUM(Z, R)
11936 If the above program prints contradictory results on a
11937 particular compiler, run away!
11940 @section @code{EXPIMP}
11944 Intrinsic @var{intrinsic} referenced @dots{}
11947 The @var{intrinsic} is explicitly declared in one program
11948 unit in the source file and implicitly used as an intrinsic
11949 in another program unit in the same source file.
11951 This diagnostic is designed to catch cases where a program
11952 might depend on using the name @var{intrinsic} as an intrinsic
11953 in one program unit and as a global name (such as the name
11954 of a subroutine or function) in another, but @command{g77} recognizes
11955 the name as an intrinsic in both cases.
11957 After verifying that the program unit making implicit use
11958 of the intrinsic is indeed written expecting the intrinsic,
11959 add an @samp{INTRINSIC @var{intrinsic}} statement to that
11960 program unit to prevent this warning.
11962 This and related warnings are disabled by using
11963 the @option{-Wno-globals} option when compiling.
11965 Note that this warning is not issued for standard intrinsics.
11966 Standard intrinsics include those described in the FORTRAN 77
11967 standard and, if @option{-ff90} is specified, those described
11968 in the Fortran 90 standard.
11969 Such intrinsics are not as likely to be confused with user
11970 procedures as intrinsics provided as extensions to the
11971 standard by @command{g77}.
11974 @section @code{INTGLOB}
11978 Same name `@var{intrinsic}' given @dots{}
11981 The name @var{intrinsic} is used for a global entity (a common
11982 block or a program unit) in one program unit and implicitly
11983 used as an intrinsic in another program unit.
11985 This diagnostic is designed to catch cases where a program
11986 intends to use a name entirely as a global name, but @command{g77}
11987 recognizes the name as an intrinsic in the program unit that
11988 references the name, a situation that would likely produce
11994 INTEGER FUNCTION TIME()
12000 PRINT *, 'Time is ', TIME()
12004 The above example defines a program unit named @samp{TIME}, but
12005 the reference to @samp{TIME} in the main program unit @samp{SAMP}
12006 is normally treated by @command{g77} as a reference to the intrinsic
12007 @code{TIME()} (unless a command-line option that prevents such
12008 treatment has been specified).
12010 As a result, the program @samp{SAMP} will @emph{not}
12011 invoke the @samp{TIME} function in the same source file.
12013 Since @command{g77} recognizes @code{libU77} procedures as
12014 intrinsics, and since some existing code uses the same names
12015 for its own procedures as used by some @code{libU77}
12016 procedures, this situation is expected to arise often enough
12017 to make this sort of warning worth issuing.
12019 After verifying that the program unit making implicit use
12020 of the intrinsic is indeed written expecting the intrinsic,
12021 add an @samp{INTRINSIC @var{intrinsic}} statement to that
12022 program unit to prevent this warning.
12024 Or, if you believe the program unit is designed to invoke the
12025 program-defined procedure instead of the intrinsic (as
12026 recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}}
12027 statement to the program unit that references the name to
12028 prevent this warning.
12030 This and related warnings are disabled by using
12031 the @option{-Wno-globals} option when compiling.
12033 Note that this warning is not issued for standard intrinsics.
12034 Standard intrinsics include those described in the FORTRAN 77
12035 standard and, if @option{-ff90} is specified, those described
12036 in the Fortran 90 standard.
12037 Such intrinsics are not as likely to be confused with user
12038 procedures as intrinsics provided as extensions to the
12039 standard by @command{g77}.
12042 @section @code{LEX}
12046 Unrecognized character @dots{}
12047 Invalid first character @dots{}
12048 Line too long @dots{}
12049 Non-numeric character @dots{}
12050 Continuation indicator @dots{}
12051 Label at @dots{} invalid with continuation line indicator @dots{}
12052 Character constant @dots{}
12053 Continuation line @dots{}
12054 Statement at @dots{} begins with invalid token
12057 Although the diagnostics identify specific problems, they can
12058 be produced when general problems such as the following occur:
12062 The source file contains something other than Fortran code.
12064 If the code in the file does not look like many of the examples
12065 elsewhere in this document, it might not be Fortran code.
12066 (Note that Fortran code often is written in lower case letters,
12067 while the examples in this document use upper case letters,
12068 for stylistic reasons.)
12070 For example, if the file contains lots of strange-looking
12071 characters, it might be APL source code; if it contains lots
12072 of parentheses, it might be Lisp source code; if it
12073 contains lots of bugs, it might be C++ source code.
12076 The source file contains free-form Fortran code, but @option{-ffree-form}
12077 was not specified on the command line to compile it.
12079 Free form is a newer form for Fortran code.
12080 The older, classic form is called fixed form.
12082 @cindex continuation character
12083 @cindex characters, continuation
12084 Fixed-form code is visually fairly distinctive, because
12085 numerical labels and comments are all that appear in
12086 the first five columns of a line, the sixth column is
12087 reserved to denote continuation lines,
12088 and actual statements start at or beyond column 7.
12089 Spaces generally are not significant, so if you
12090 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
12091 you are looking at fixed-form code.
12094 Comment lines are indicated by the letter @samp{C} or the symbol
12095 @samp{*} in column 1.
12096 @cindex trailing comment
12098 @cindex characters, comment
12100 @cindex exclamation point
12101 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
12102 which many compilers support.)
12104 Free-form code is distinguished from fixed-form source
12105 primarily by the fact that statements may start anywhere.
12106 (If lots of statements start in columns 1 through 6,
12107 that's a strong indicator of free-form source.)
12108 Consecutive keywords must be separated by spaces, so
12109 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
12110 There are no comment lines per se, but @samp{!} starts a
12111 comment anywhere in a line (other than within a character or
12112 Hollerith constant).
12114 @xref{Source Form}, for more information.
12117 The source file is in fixed form and has been edited without
12118 sensitivity to the column requirements.
12120 Statements in fixed-form code must be entirely contained within
12121 columns 7 through 72 on a given line.
12122 Starting them ``early'' is more likely to result in diagnostics
12123 than finishing them ``late'', though both kinds of errors are
12124 often caught at compile time.
12126 For example, if the following code fragment is edited by following
12127 the commented instructions literally, the result, shown afterward,
12128 would produce a diagnostic when compiled:
12131 C On XYZZY systems, remove "C" on next line:
12135 The result of editing the above line might be:
12138 C On XYZZY systems, remove "C" on next line:
12142 However, that leaves the first @samp{C} in the @code{CALL}
12143 statement in column 6, making it a comment line, which is
12144 not really what the author intended, and which is likely
12145 to result in one of the above-listed diagnostics.
12147 @emph{Replacing} the @samp{C} in column 1 with a space
12148 is the proper change to make, to ensure the @code{CALL}
12149 keyword starts in or after column 7.
12151 Another common mistake like this is to forget that fixed-form
12152 source lines are significant through only column 72, and that,
12153 normally, any text beyond column 72 is ignored or is diagnosed
12156 @xref{Source Form}, for more information.
12159 The source file requires preprocessing, and the preprocessing
12160 is not being specified at compile time.
12162 A source file containing lines beginning with @code{#define},
12163 @code{#include}, @code{#if}, and so on is likely one that
12164 requires preprocessing.
12166 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
12167 the file normally will be compiled @emph{without} preprocessing
12170 Change the file's suffix from @samp{.f} to @samp{.F}
12171 (or, on systems with case-insensitive file names,
12172 to @samp{.fpp} or @samp{.FPP}),
12173 from @samp{.for} to @samp{.fpp},
12174 or from @samp{.FOR} to @samp{.FPP}.
12175 @command{g77} compiles files with such names @emph{with}
12179 @cindex preprocessor
12180 @cindex cpp program
12181 @cindex programs, cpp
12182 @cindex @option{-x f77-cpp-input} option
12183 @cindex options, @option{-x f77-cpp-input}
12184 Or, learn how to use @command{gcc}'s @option{-x} option to specify
12185 the language @samp{f77-cpp-input} for Fortran files that
12186 require preprocessing.
12187 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
12190 The source file is preprocessed, and the results of preprocessing
12191 result in syntactic errors that are not necessarily obvious to
12192 someone examining the source file itself.
12194 Examples of errors resulting from preprocessor macro expansion
12195 include exceeding the line-length limit, improperly starting,
12196 terminating, or incorporating the apostrophe or double-quote in
12197 a character constant, improperly forming a Hollerith constant,
12200 @xref{Overall Options,,Options Controlling the Kind of Output},
12201 for suggestions about how to use, and not use, preprocessing
12206 @section @code{GLOBALS}
12210 Global name @var{name} defined at @dots{} already defined@dots{}
12211 Global name @var{name} at @dots{} has different type@dots{}
12212 Too many arguments passed to @var{name} at @dots{}
12213 Too few arguments passed to @var{name} at @dots{}
12214 Argument #@var{n} of @var{name} is @dots{}
12217 These messages all identify disagreements about the
12218 global procedure named @var{name} among different program units
12219 (usually including @var{name} itself).
12221 Whether a particular disagreement is reported
12222 as a warning or an error
12223 can depend on the relative order
12224 of the disagreeing portions of the source file.
12226 Disagreements between a procedure invocation
12227 and the @emph{subsequent} procedure itself
12228 are, usually, diagnosed as errors
12229 when the procedure itself @emph{precedes} the invocation.
12230 Other disagreements are diagnosed via warnings.
12232 @cindex forward references
12233 @cindex in-line code
12234 @cindex compilation, in-line
12235 This distinction, between warnings and errors,
12236 is due primarily to the present tendency of the @command{gcc} back end
12237 to inline only those procedure invocations that are
12238 @emph{preceded} by the corresponding procedure definitions.
12239 If the @command{gcc} back end is changed
12240 to inline ``forward references'',
12241 in which invocations precede definitions,
12242 the @command{g77} front end will be changed
12243 to treat both orderings as errors, accordingly.
12245 The sorts of disagreements that are diagnosed by @command{g77} include
12246 whether a procedure is a subroutine or function;
12247 if it is a function, the type of the return value of the procedure;
12248 the number of arguments the procedure accepts;
12249 and the type of each argument.
12251 Disagreements regarding global names among program units
12252 in a Fortran program @emph{should} be fixed in the code itself.
12253 However, if that is not immediately practical,
12254 and the code has been working for some time,
12255 it is possible it will work
12256 when compiled with the @option{-fno-globals} option.
12258 The @option{-fno-globals} option
12259 causes these diagnostics to all be warnings
12260 and disables all inlining of references to global procedures
12261 (to avoid subsequent compiler crashes and bad-code generation).
12262 Use of the @option{-Wno-globals} option as well as @option{-fno-globals}
12263 suppresses all of these diagnostics.
12264 (@option{-Wno-globals} by itself disables only the warnings,
12267 After using @option{-fno-globals} to work around these problems,
12268 it is wise to stop using that option and address them by fixing
12269 the Fortran code, because such problems, while they might not
12270 actually result in bugs on some systems, indicate that the code
12271 is not as portable as it could be.
12272 In particular, the code might appear to work on a particular
12273 system, but have bugs that affect the reliability of the data
12274 without exhibiting any other outward manifestations of the bugs.
12277 @section @code{LINKFAIL}
12280 On AIX 4.1, @command{g77} might not build with the native (non-GNU) tools
12281 due to a linker bug in coping with the @option{-bbigtoc} option which
12282 leads to a @samp{Relocation overflow} error. The GNU linker is not
12283 recommended on current AIX versions, though; it was developed under a
12284 now-unsupported version. This bug is said to be fixed by `update PTF
12285 U455193 for APAR IX75823'.
12287 Compiling with @option{-mminimal-toc}
12288 might solve this problem, e.g.@: by adding
12290 BOOT_CFLAGS='-mminimal-toc -O2 -g'
12292 to the @code{make bootstrap} command line.
12295 @section @code{Y2KBAD}
12296 @cindex Y2K compliance
12297 @cindex Year 2000 compliance
12301 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
12304 This diagnostic indicates that
12305 the specific intrinsic invoked by the name @var{name}
12306 is known to have an interface
12307 that is not Year-2000 (Y2K) compliant.
12309 @xref{Year 2000 (Y2K) Problems}.