1 \input texinfo @c -*-texinfo-*-
5 @set last-update 2001-11-20
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.
201 @node Top, Copying,, (DIR)
207 This manual documents how to run, install and port @command{g77},
208 as well as its new features and incompatibilities,
209 and how to report bugs.
210 It corresponds to the @value{which-g77} version of @command{g77}.
215 This manual documents how to run and install @command{g77},
216 as well as its new features and incompatibilities, and how to report
218 It corresponds to the @value{which-g77} version of @command{g77}.
221 This manual documents how to port @command{g77},
222 as well as its new features and incompatibilities,
223 and how to report bugs.
224 It corresponds to the @value{which-g77} version of @command{g77}.
228 @emph{Warning:} This document is still under development,
229 and might not accurately reflect the @command{g77} code base
230 of which it is a part.
231 Efforts are made to keep it somewhat up-to-date,
232 but they are particularly concentrated
233 on any version of this information
234 that is distributed as part of a @emph{released} @command{g77}.
236 In particular, while this document is intended to apply to
237 the @value{which-g77} version of @command{g77},
238 only an official @emph{release} of that version
239 is expected to contain documentation that is
240 most consistent with the @command{g77} product in that version.
244 * Copying:: GNU General Public License says
245 how you can copy and share GNU Fortran.
246 * GNU Free Documentation License::
247 How you can copy and share this manual.
248 * Contributors:: People who have contributed to GNU Fortran.
249 * Funding:: How to help assure continued work for free software.
250 * Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
252 * Getting Started:: Finding your way around this manual.
253 * What is GNU Fortran?:: How @command{g77} fits into the universe.
254 * G77 and GCC:: You can compile Fortran, C, or other programs.
255 * Invoking G77:: Command options supported by @command{g77}.
256 * News:: News about recent releases of @command{g77}.
257 * Changes:: User-visible changes to recent releases of @command{g77}.
258 * Language:: The GNU Fortran language.
259 * Compiler:: The GNU Fortran compiler.
260 * Other Dialects:: Dialects of Fortran supported by @command{g77}.
261 * Other Compilers:: Fortran compilers other than @command{g77}.
262 * Other Languages:: Languages other than Fortran.
263 * Debugging and Interfacing:: How @command{g77} generates code.
264 * Collected Fortran Wisdom:: How to avoid Trouble.
265 * Trouble:: If you have trouble with GNU Fortran.
266 * Open Questions:: Things we'd like to know.
267 * Bugs:: How, why, and where to report bugs.
268 * Service:: How to find suppliers of support for GNU Fortran.
271 * Adding Options:: Guidance on teaching @command{g77} about new options.
272 * Projects:: Projects for @command{g77} internals hackers.
273 * Front End:: Design and implementation of the @command{g77} front end.
276 * M: Diagnostics. Diagnostics produced by @command{g77}.
278 * Index:: Index of concepts and symbol names.
280 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
287 @unnumbered Contributors to GNU Fortran
291 In addition to James Craig Burley, who wrote the front end,
292 many people have helped create and improve GNU Fortran.
296 The packaging and compiler portions of GNU Fortran are based largely
297 on the GNU CC compiler.
298 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
299 for more information.
302 The run-time library used by GNU Fortran is a repackaged version
303 of the @code{libf2c} library (combined from the @code{libF77} and
304 @code{libI77} libraries) provided as part of @command{f2c}, available for
305 free from @code{netlib} sites on the Internet.
308 Cygnus Support and The Free Software Foundation contributed
309 significant money and/or equipment to Craig's efforts.
312 The following individuals served as alpha testers prior to @command{g77}'s
313 public release. This work consisted of testing, researching, sometimes
314 debugging, and occasionally providing small amounts of code and fixes
315 for @command{g77}, plus offering plenty of helpful advice to Craig:
321 Dr.@: Mark Fernyhough
323 Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
327 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
329 Dr.@: A. O. V. Le Blanc
351 Dave Love (@email{d.love@@dl.ac.uk})
352 wrote the libU77 part of the run-time library.
355 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
356 provided the patch to add rudimentary support
357 for @code{INTEGER*1}, @code{INTEGER*2}, and
359 This inspired Craig to add further support,
360 even though the resulting support
361 would still be incomplete, because version 0.6 is still
365 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
366 and encouraged Craig to rewrite the documentation in texinfo
367 format by contributing a first pass at a translation of the
368 old @file{g77-0.5.16/f/DOC} file.
371 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
372 some analysis of generated code as part of an overall project
373 to improve @command{g77} code generation to at least be as good
374 as @command{f2c} used in conjunction with @command{gcc}.
375 So far, this has resulted in the three, somewhat
376 experimental, options added by @command{g77} to the @command{gcc}
377 compiler and its back end.
379 (These, in turn, had made their way into the @code{egcs}
380 version of the compiler, and do not exist in @command{gcc}
381 version 2.8 or versions of @command{g77} based on that version
385 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
388 Thanks to Mary Cortani and the staff at Craftwork Solutions
389 (@email{support@@craftwork.com}) for all of their support.
392 Many other individuals have helped debug, test, and improve @command{g77}
393 over the past several years, and undoubtedly more people
394 will be doing so in the future.
395 If you have done so, and would like
396 to see your name listed in the above list, please ask!
397 The default is that people wish to remain anonymous.
400 @include funding.texi
402 @node Funding GNU Fortran
403 @chapter Funding GNU Fortran
404 @cindex funding improvements
405 @cindex improvements, funding
407 James Craig Burley (@email{@value{email-burley}}), the original author
408 of @command{g77}, stopped working on it in September 1999
409 (He has a web page at @uref{@value{www-burley}}.)
411 GNU Fortran is currently maintained by Toon Moene
412 (@email{toon@@moene.indiv.nluug.nl}), with the help of countless other
415 As with other GNU software, funding is important because it can pay for
416 needed equipment, personnel, and so on.
418 @cindex FSF, funding the
419 @cindex funding the FSF
420 The FSF provides information on the best way to fund ongoing
421 development of GNU software (such as GNU Fortran) in documents
422 such as the ``GNUS Bulletin''.
423 Email @email{gnu@@gnu.org} for information on funding the FSF.
425 Another important way to support work on GNU Fortran is to volunteer
427 Work is needed on documentation, testing, porting
428 to various machines, and in some cases, coding (although major
429 changes planned for version 0.6 make it difficult to add manpower to this
432 Email @email{@value{email-general}} to volunteer for this work.
434 However, we strongly expect that there will never be a version 0.6
435 of @command{g77}. Work on this compiler has stopped as of the release
436 of GCC 3.1, except for bug fixing. @command{g77} will be succeeded by
437 @command{g95} - see @uref{http://g95.sourceforge.net}.
439 @xref{Funding,,Funding Free Software}, for more information.
441 @node Getting Started
442 @chapter Getting Started
443 @cindex getting started
448 If you don't need help getting started reading the portions
449 of this manual that are most important to you, you should skip
450 this portion of the manual.
452 If you are new to compilers, especially Fortran compilers, or
453 new to how compilers are structured under UNIX and UNIX-like
454 systems, you'll want to see @ref{What is GNU Fortran?}.
456 If you are new to GNU compilers, or have used only one GNU
457 compiler in the past and not had to delve into how it lets
458 you manage various versions and configurations of @command{gcc},
459 you should see @ref{G77 and GCC}.
461 Everyone except experienced @command{g77} users should
462 see @ref{Invoking G77}.
464 If you're acquainted with previous versions of @command{g77},
465 you should see @ref{News,,News About GNU Fortran}.
466 Further, if you've actually used previous versions of @command{g77},
467 especially if you've written or modified Fortran code to
468 be compiled by previous versions of @command{g77}, you
469 should see @ref{Changes}.
471 If you intend to write or otherwise compile code that is
472 not already strictly conforming ANSI FORTRAN 77---and this
473 is probably everyone---you should see @ref{Language}.
475 If you run into trouble getting Fortran code to compile,
476 link, run, or work properly, you might find answers
477 if you see @ref{Debugging and Interfacing},
478 see @ref{Collected Fortran Wisdom},
479 and see @ref{Trouble}.
480 You might also find that the problems you are encountering
481 are bugs in @command{g77}---see @ref{Bugs}, for information on
482 reporting them, after reading the other material.
484 If you need further help with @command{g77}, or with
485 freely redistributable software in general,
488 If you would like to help the @command{g77} project,
489 see @ref{Funding GNU Fortran}, for information on
490 helping financially, and see @ref{Projects}, for information
491 on helping in other ways.
493 If you're generally curious about the future of
494 @command{g77}, see @ref{Projects}.
495 If you're curious about its past,
496 see @ref{Contributors},
497 and see @ref{Funding GNU Fortran}.
499 To see a few of the questions maintainers of @command{g77} have,
500 and that you might be able to answer,
501 see @ref{Open Questions}.
504 @node What is GNU Fortran?
505 @chapter What is GNU Fortran?
506 @cindex concepts, basic
507 @cindex basic concepts
509 GNU Fortran, or @command{g77}, is designed initially as a free replacement
510 for, or alternative to, the UNIX @command{f77} command.
511 (Similarly, @command{gcc} is designed as a replacement
512 for the UNIX @command{cc} command.)
514 @command{g77} also is designed to fit in well with the other
515 fine GNU compilers and tools.
517 Sometimes these design goals conflict---in such cases, resolution
518 often is made in favor of fitting in well with Project GNU.
519 These cases are usually identified in the appropriate
520 sections of this manual.
523 As compilers, @command{g77}, @command{gcc}, and @command{f77}
524 share the following characteristics:
532 They read a user's program, stored in a file and
533 containing instructions written in the appropriate
534 language (Fortran, C, and so on).
535 This file contains @dfn{source code}.
537 @cindex translation of user programs
539 @cindex code, machine
542 They translate the user's program into instructions
543 a computer can carry out more quickly than it takes
544 to translate the instructions in the first place.
545 These instructions are called @dfn{machine code}---code
546 designed to be efficiently translated and processed
547 by a machine such as a computer.
548 Humans usually aren't as good writing machine code
549 as they are at writing Fortran or C, because
550 it is easy to make tiny mistakes writing machine code.
551 When writing Fortran or C, it is easy
552 to make big mistakes.
555 @cindex bugs, finding
556 @cindex @command{gdb}, command
557 @cindex commands, @command{gdb}
559 They provide information in the generated machine code
560 that can make it easier to find bugs in the program
561 (using a debugging tool, called a @dfn{debugger},
562 such as @command{gdb}).
566 @cindex @command{ld} command
567 @cindex commands, @command{ld}
569 They locate and gather machine code already generated
570 to perform actions requested by statements in
572 This machine code is organized
573 into @dfn{libraries} and is located and gathered
574 during the @dfn{link} phase of the compilation
576 (Linking often is thought of as a separate
577 step, because it can be directly invoked via the
578 @command{ld} command.
579 However, the @command{g77} and @command{gcc}
580 commands, as with most compiler commands, automatically
581 perform the linking step by calling on @command{ld}
582 directly, unless asked to not do so by the user.)
584 @cindex language, incorrect use of
585 @cindex incorrect use of language
587 They attempt to diagnose cases where the user's
588 program contains incorrect usages of the language.
589 The @dfn{diagnostics} produced by the compiler
590 indicate the problem and the location in the user's
591 source file where the problem was first noticed.
592 The user can use this information to locate and
594 @cindex diagnostics, incorrect
595 @cindex incorrect diagnostics
596 @cindex error messages, incorrect
597 @cindex incorrect error messages
598 (Sometimes an incorrect usage
599 of the language leads to a situation where the
600 compiler can no longer make any sense of what
601 follows---while a human might be able to---and
602 thus ends up complaining about many ``problems''
603 it encounters that, in fact, stem from just one
604 problem, usually the first one reported.)
607 @cindex questionable instructions
609 They attempt to diagnose cases where the user's
610 program contains a correct usage of the language,
611 but instructs the computer to do something questionable.
612 These diagnostics often are in the form of @dfn{warnings},
613 instead of the @dfn{errors} that indicate incorrect
614 usage of the language.
617 How these actions are performed is generally under the
619 Using command-line options, the user can specify
620 how persnickety the compiler is to be regarding
621 the program (whether to diagnose questionable usage
622 of the language), how much time to spend making
623 the generated machine code run faster, and so on.
625 @cindex components of @command{g77}
626 @cindex @command{g77}, components of
627 @command{g77} consists of several components:
629 @cindex @command{gcc}, command
630 @cindex commands, @command{gcc}
633 A modified version of the @command{gcc} command, which also might be
634 installed as the system's @command{cc} command.
635 (In many cases, @command{cc} refers to the
636 system's ``native'' C compiler, which
637 might be a non-GNU compiler, or an older version
638 of @command{gcc} considered more stable or that is
639 used to build the operating system kernel.)
641 @cindex @command{g77}, command
642 @cindex commands, @command{g77}
644 The @command{g77} command itself, which also might be installed as the
645 system's @command{f77} command.
647 @cindex libg2c library
648 @cindex libf2c library
649 @cindex libraries, libf2c
650 @cindex libraries, libg2c
651 @cindex run-time, library
653 The @code{libg2c} run-time library.
654 This library contains the machine code needed to support
655 capabilities of the Fortran language that are not directly
656 provided by the machine code generated by the @command{g77}
659 @code{libg2c} is just the unique name @command{g77} gives
660 to its version of @code{libf2c} to distinguish it from
661 any copy of @code{libf2c} installed from @command{f2c}
662 (or versions of @command{g77} that built @code{libf2c} under
666 The maintainer of @code{libf2c} currently is
667 @email{dmg@@bell-labs.com}.
669 @cindex @code{f771}, program
670 @cindex programs, @code{f771}
672 @cindex @command{as} command
673 @cindex commands, @command{as}
674 @cindex assembly code
675 @cindex code, assembly
677 The compiler itself, internally named @code{f771}.
679 Note that @code{f771} does not generate machine code directly---it
680 generates @dfn{assembly code} that is a more readable form
681 of machine code, leaving the conversion to actual machine code
682 to an @dfn{assembler}, usually named @command{as}.
685 @command{gcc} is often thought of as ``the C compiler'' only,
686 but it does more than that.
687 Based on command-line options and the names given for files
688 on the command line, @command{gcc} determines which actions to perform, including
689 preprocessing, compiling (in a variety of possible languages), assembling,
692 @cindex driver, gcc command as
693 @cindex @command{gcc}, command as driver
694 @cindex executable file
695 @cindex files, executable
697 @cindex programs, cc1
700 @cindex programs, cpp
701 For example, the command @samp{gcc foo.c} @dfn{drives} the file
702 @file{foo.c} through the preprocessor @command{cpp}, then
703 the C compiler (internally named
704 @code{cc1}), then the assembler (usually @command{as}), then the linker
705 (@command{ld}), producing an executable program named @file{a.out} (on
708 @cindex cc1plus program
709 @cindex programs, cc1plus
710 As another example, the command @samp{gcc foo.cc} would do much the same as
711 @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
712 @command{gcc} would use the C++ compiler (named @code{cc1plus}).
714 @cindex @code{f771}, program
715 @cindex programs, @code{f771}
716 In a GNU Fortran installation, @command{gcc} recognizes Fortran source
717 files by name just like it does C and C++ source files.
718 It knows to use the Fortran compiler named @code{f771}, instead of
719 @code{cc1} or @code{cc1plus}, to compile Fortran files.
721 @cindex @command{gcc}, not recognizing Fortran source
722 @cindex unrecognized file format
723 @cindex file format not recognized
724 Non-Fortran-related operation of @command{gcc} is generally
725 unaffected by installing the GNU Fortran version of @command{gcc}.
726 However, without the installed version of @command{gcc} being the
727 GNU Fortran version, @command{gcc} will not be able to compile
728 and link Fortran programs---and since @command{g77} uses @command{gcc}
729 to do most of the actual work, neither will @command{g77}!
731 @cindex @command{g77}, command
732 @cindex commands, @command{g77}
733 The @command{g77} command is essentially just a front-end for
734 the @command{gcc} command.
735 Fortran users will normally use @command{g77} instead of @command{gcc},
736 because @command{g77}
737 knows how to specify the libraries needed to link with Fortran programs
738 (@code{libg2c} and @code{lm}).
739 @command{g77} can still compile and link programs and
740 source files written in other languages, just like @command{gcc}.
742 @cindex printing version information
743 @cindex version information, printing
744 The command @samp{g77 -v} is a quick
745 way to display lots of version information for the various programs
746 used to compile a typical preprocessed Fortran source file---this
747 produces much more output than @samp{gcc -v} currently does.
748 (If it produces an error message near the end of the output---diagnostics
749 from the linker, usually @command{ld}---you might
750 have an out-of-date @code{libf2c} that improperly handles
752 In the output of this command, the line beginning @samp{GNU Fortran Front
753 End} identifies the version number of GNU Fortran; immediately
754 preceding that line is a line identifying the version of @command{gcc}
755 with which that version of @command{g77} was built.
757 @cindex libf2c library
758 @cindex libraries, libf2c
759 The @code{libf2c} library is distributed with GNU Fortran for
760 the convenience of its users, but is not part of GNU Fortran.
761 It contains the procedures
762 needed by Fortran programs while they are running.
765 @cindex code, in-line
766 For example, while code generated by @command{g77} is likely
767 to do additions, subtractions, and multiplications @dfn{in line}---in
768 the actual compiled code---it is not likely to do trigonometric
771 Instead, operations like trigonometric
772 functions are compiled by the @code{f771} compiler
773 (invoked by @command{g77} when compiling Fortran code) into machine
774 code that, when run, calls on functions in @code{libg2c}, so
775 @code{libg2c} must be linked with almost every useful program
776 having any component compiled by GNU Fortran.
777 (As mentioned above, the @command{g77} command takes
778 care of all this for you.)
780 The @code{f771} program represents most of what is unique to GNU Fortran.
781 While much of the @code{libg2c} component comes from
782 the @code{libf2c} component of @command{f2c},
783 a free Fortran-to-C converter distributed by Bellcore (AT&T),
784 plus @code{libU77}, provided by Dave Love,
785 and the @command{g77} command is just a small front-end to @command{gcc},
786 @code{f771} is a combination of two rather
787 large chunks of code.
789 @cindex GNU Back End (GBE)
791 @cindex @command{gcc}, back end
792 @cindex back end, gcc
793 @cindex code generator
794 One chunk is the so-called @dfn{GNU Back End}, or GBE,
795 which knows how to generate fast code for a wide variety of processors.
796 The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
797 @code{cc1plus}, and @code{f771}, plus others.
798 Often the GBE is referred to as the ``gcc back end'' or
799 even just ``gcc''---in this manual, the term GBE is used
800 whenever the distinction is important.
802 @cindex GNU Fortran Front End (FFE)
804 @cindex @command{g77}, front end
805 @cindex front end, @command{g77}
806 The other chunk of @code{f771} is the
807 majority of what is unique about GNU Fortran---the code that knows how
808 to interpret Fortran programs to determine what they are intending to
809 do, and then communicate that knowledge to the GBE for actual compilation
811 This chunk is called the @dfn{Fortran Front End} (FFE).
812 The @code{cc1} and @code{cc1plus} programs have their own front ends,
813 for the C and C++ languages, respectively.
814 These fronts ends are responsible for diagnosing
815 incorrect usage of their respective languages by the
816 programs the process, and are responsible for most of
817 the warnings about questionable constructs as well.
818 (The GBE handles producing some warnings, like those
819 concerning possible references to undefined variables.)
821 Because so much is shared among the compilers for various languages,
822 much of the behavior and many of the user-selectable options for these
823 compilers are similar.
824 For example, diagnostics (error messages and
825 warnings) are similar in appearance; command-line
826 options like @option{-Wall} have generally similar effects; and the quality
827 of generated code (in terms of speed and size) is roughly similar
828 (since that work is done by the shared GBE).
831 @chapter Compile Fortran, C, or Other Programs
832 @cindex compiling programs
833 @cindex programs, compiling
835 @cindex @command{gcc}, command
836 @cindex commands, @command{gcc}
837 A GNU Fortran installation includes a modified version of the @command{gcc}
840 In a non-Fortran installation, @command{gcc} recognizes C, C++,
841 and Objective-C source files.
843 In a GNU Fortran installation, @command{gcc} also recognizes Fortran source
844 files and accepts Fortran-specific command-line options, plus some
845 command-line options that are designed to cater to Fortran users
846 but apply to other languages as well.
848 @xref{G++ and GCC,,Compile C; C++; or Objective-C,gcc,Using and Porting GNU CC},
849 for information on the way different languages are handled
850 by the GNU CC compiler (@command{gcc}).
852 @cindex @command{g77}, command
853 @cindex commands, @command{g77}
854 Also provided as part of GNU Fortran is the @command{g77} command.
855 The @command{g77} command is designed to make compiling and linking Fortran
856 programs somewhat easier than when using the @command{gcc} command for
858 It does this by analyzing the command line somewhat and changing it
859 appropriately before submitting it to the @command{gcc} command.
862 @cindex @command{g77} options, -v
864 Use the @option{-v} option with @command{g77}
865 to see what is going on---the first line of output is the invocation
866 of the @command{gcc} command.
877 @chapter The GNU Fortran Language
879 @cindex standard, ANSI FORTRAN 77
880 @cindex ANSI FORTRAN 77 standard
881 @cindex reference works
882 GNU Fortran supports a variety of extensions to, and dialects
883 of, the Fortran language.
884 Its primary base is the ANSI FORTRAN 77 standard, currently available on
886 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
887 or as monolithic text at
888 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
889 It offers some extensions that are popular among users
890 of UNIX @command{f77} and @command{f2c} compilers, some that
891 are popular among users of other compilers (such as Digital
892 products), some that are popular among users of the
893 newer Fortran 90 standard, and some that are introduced
897 (If you need a text on Fortran,
898 a few freely available electronic references have pointers from
899 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
900 net project', @cite{User Notes on Fortran Programming} at
901 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
902 material might not apply specifically to @command{g77}.)
904 Part of what defines a particular implementation of a Fortran
905 system, such as @command{g77}, is the particular characteristics
906 of how it supports types, constants, and so on.
907 Much of this is left up to the implementation by the various
908 Fortran standards and accepted practice in the industry.
910 The GNU Fortran @emph{language} is described below.
911 Much of the material is organized along the same lines
912 as the ANSI FORTRAN 77 standard itself.
914 @xref{Other Dialects}, for information on features @command{g77} supports
915 that are not part of the GNU Fortran language.
917 @emph{Note}: This portion of the documentation definitely needs a lot
921 Relationship to the ANSI FORTRAN 77 standard:
922 * Direction of Language Development:: Where GNU Fortran is headed.
923 * Standard Support:: Degree of support for the standard.
925 Extensions to the ANSI FORTRAN 77 standard:
928 * Terms and Concepts::
929 * Characters Lines Sequence::
930 * Data Types and Constants::
932 * Specification Statements::
933 * Control Statements::
934 * Functions and Subroutines::
935 * Scope and Classes of Names::
937 * Fortran 90 Features::
940 @node Direction of Language Development
941 @section Direction of Language Development
942 @cindex direction of language development
943 @cindex features, language
944 @cindex language, features
946 The purpose of the following description of the GNU Fortran
947 language is to promote wide portability of GNU Fortran programs.
949 GNU Fortran is an evolving language, due to the
950 fact that @command{g77} itself is in beta test.
951 Some current features of the language might later
952 be redefined as dialects of Fortran supported by @command{g77}
953 when better ways to express these features are added to @command{g77},
955 Such features would still be supported by
956 @command{g77}, but would be available only when
957 one or more command-line options were used.
959 The GNU Fortran @emph{language} is distinct from the
960 GNU Fortran @emph{compilation system} (@command{g77}).
962 For example, @command{g77} supports various dialects of
963 Fortran---in a sense, these are languages other than
964 GNU Fortran---though its primary
965 purpose is to support the GNU Fortran language, which also is
966 described in its documentation and by its implementation.
968 On the other hand, non-GNU compilers might offer
969 support for the GNU Fortran language, and are encouraged
972 Currently, the GNU Fortran language is a fairly fuzzy object.
973 It represents something of a cross between what @command{g77} accepts
974 when compiling using the prevailing defaults and what this
975 document describes as being part of the language.
977 Future versions of @command{g77} are expected to clarify the
978 definition of the language in the documentation.
979 Often, this will mean adding new features to the language, in the form
980 of both new documentation and new support in @command{g77}.
981 However, it might occasionally mean removing a feature
982 from the language itself to ``dialect'' status.
983 In such a case, the documentation would be adjusted
984 to reflect the change, and @command{g77} itself would likely be changed
985 to require one or more command-line options to continue supporting
988 The development of the GNU Fortran language is intended to strike
993 Serving as a mostly-upwards-compatible language from the
994 de facto UNIX Fortran dialect as supported by @command{f77}.
997 Offering new, well-designed language features.
998 Attributes of such features include
999 not making existing code any harder to read
1000 (for those who might be unaware that the new
1001 features are not in use) and
1002 not making state-of-the-art
1003 compilers take longer to issue diagnostics,
1007 Supporting existing, well-written code without gratuitously
1008 rejecting non-standard constructs, regardless of the origin
1009 of the code (its dialect).
1012 Offering default behavior and command-line options to reduce
1013 and, where reasonable, eliminate the need for programmers to make
1014 any modifications to code that already works in existing
1015 production environments.
1018 Diagnosing constructs that have different meanings in different
1019 systems, languages, and dialects, while offering clear,
1020 less ambiguous ways to express each of the different meanings
1021 so programmers can change their code appropriately.
1024 One of the biggest practical challenges for the developers of the
1025 GNU Fortran language is meeting the sometimes contradictory demands
1028 For example, a feature might be widely used in one popular environment,
1029 but the exact same code that utilizes that feature might not work
1030 as expected---perhaps it might mean something entirely different---in
1031 another popular environment.
1033 Traditionally, Fortran compilers---even portable ones---have solved this
1034 problem by simply offering the appropriate feature to users of
1035 the respective systems.
1036 This approach treats users of various Fortran systems and dialects
1037 as remote ``islands'', or camps, of programmers, and assume that these
1038 camps rarely come into contact with each other (or,
1039 especially, with each other's code).
1041 Project GNU takes a radically different approach to software and language
1042 design, in that it assumes that users of GNU software do not necessarily
1043 care what kind of underlying system they are using, regardless
1044 of whether they are using software (at the user-interface
1045 level) or writing it (for example, writing Fortran or C code).
1047 As such, GNU users rarely need consider just what kind of underlying
1048 hardware (or, in many cases, operating system) they are using at any
1050 They can use and write software designed for a general-purpose,
1051 widely portable, heterogenous environment---the GNU environment.
1053 In line with this philosophy, GNU Fortran must evolve into a product
1054 that is widely ported and portable not only in the sense that it can
1055 be successfully built, installed, and run by users, but in the larger
1056 sense that its users can use it in the same way, and expect largely the
1057 same behaviors from it, regardless of the kind of system they are using
1058 at any particular time.
1060 This approach constrains the solutions @command{g77} can use to resolve
1061 conflicts between various camps of Fortran users.
1062 If these two camps disagree about what a particular construct should
1063 mean, @command{g77} cannot simply be changed to treat that particular construct as
1064 having one meaning without comment (such as a warning), lest the users
1065 expecting it to have the other meaning are unpleasantly surprised that
1066 their code misbehaves when executed.
1068 The use of the ASCII backslash character in character constants is
1069 an excellent (and still somewhat unresolved) example of this kind of
1071 @xref{Backslash in Constants}.
1072 Other examples are likely to arise in the future, as @command{g77} developers
1073 strive to improve its ability to accept an ever-wider variety of existing
1074 Fortran code without requiring significant modifications to said code.
1076 Development of GNU Fortran is further constrained by the desire
1077 to avoid requiring programmers to change their code.
1078 This is important because it allows programmers, administrators,
1079 and others to more faithfully evaluate and validate @command{g77}
1080 (as an overall product and as new versions are distributed)
1081 without having to support multiple versions of their programs
1082 so that they continue to work the same way on their existing
1083 systems (non-GNU perhaps, but possibly also earlier versions
1086 @node Standard Support
1087 @section ANSI FORTRAN 77 Standard Support
1088 @cindex ANSI FORTRAN 77 support
1089 @cindex standard, support for
1090 @cindex support, FORTRAN 77
1091 @cindex compatibility, FORTRAN 77
1092 @cindex FORTRAN 77 compatibility
1094 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
1095 In summary, the only ANSI FORTRAN 77 features @command{g77} doesn't
1096 support are those that are probably rarely used in actual code,
1097 some of which are explicitly disallowed by the Fortran 90 standard.
1100 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
1101 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
1102 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
1103 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
1106 @node No Passing External Assumed-length
1107 @subsection No Passing External Assumed-length
1109 @command{g77} disallows passing of an external procedure
1110 as an actual argument if the procedure's
1111 type is declared @code{CHARACTER*(*)}. For example:
1121 It isn't clear whether the standard considers this conforming.
1123 @node No Passing Dummy Assumed-length
1124 @subsection No Passing Dummy Assumed-length
1126 @command{g77} disallows passing of a dummy procedure
1127 as an actual argument if the procedure's
1128 type is declared @code{CHARACTER*(*)}.
1131 SUBROUTINE BAR(CFUNC)
1139 It isn't clear whether the standard considers this conforming.
1141 @node No Pathological Implied-DO
1142 @subsection No Pathological Implied-DO
1144 The @code{DO} variable for an implied-@code{DO} construct in a
1145 @code{DATA} statement may not be used as the @code{DO} variable
1146 for an outer implied-@code{DO} construct. For example, this
1147 fragment is disallowed by @command{g77}:
1150 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
1154 This also is disallowed by Fortran 90, as it offers no additional
1155 capabilities and would have a variety of possible meanings.
1157 Note that it is @emph{very} unlikely that any production Fortran code
1158 tries to use this unsupported construct.
1160 @node No Useless Implied-DO
1161 @subsection No Useless Implied-DO
1163 An array element initializer in an implied-@code{DO} construct in a
1164 @code{DATA} statement must contain at least one reference to the @code{DO}
1165 variables of each outer implied-@code{DO} construct. For example,
1166 this fragment is disallowed by @command{g77}:
1169 DATA (A, I= 1, 1) /1./
1173 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
1174 requirements offer no additional capabilities.
1175 However, @command{g77} doesn't necessarily diagnose all cases
1176 where this requirement is not met.
1178 Note that it is @emph{very} unlikely that any production Fortran code
1179 tries to use this unsupported construct.
1182 @section Conformance
1184 (The following information augments or overrides the information in
1185 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1187 Chapter 1 of that document otherwise serves as the basis
1188 for the relevant aspects of GNU Fortran.)
1190 The definition of the GNU Fortran language is akin to that of
1191 the ANSI FORTRAN 77 language in that it does not generally require
1192 conforming implementations to diagnose cases where programs do
1193 not conform to the language.
1195 However, @command{g77} as a compiler is being developed in a way that
1196 is intended to enable it to diagnose such cases in an easy-to-understand
1199 A program that conforms to the GNU Fortran language should, when
1200 compiled, linked, and executed using a properly installed @command{g77}
1201 system, perform as described by the GNU Fortran language definition.
1202 Reasons for different behavior include, among others:
1206 Use of resources (memory---heap, stack, and so on; disk space; CPU
1207 time; etc.) exceeds those of the system.
1210 Range and/or precision of calculations required by the program
1211 exceeds that of the system.
1214 Excessive reliance on behaviors that are system-dependent
1215 (non-portable Fortran code).
1218 Bugs in the program.
1221 Bug in @command{g77}.
1227 Despite these ``loopholes'', the availability of a clear specification
1228 of the language of programs submitted to @command{g77}, as this document
1229 is intended to provide, is considered an important aspect of providing
1230 a robust, clean, predictable Fortran implementation.
1232 The definition of the GNU Fortran language, while having no special
1233 legal status, can therefore be viewed as a sort of contract, or agreement.
1234 This agreement says, in essence, ``if you write a program in this language,
1235 and run it in an environment (such as a @command{g77} system) that supports
1236 this language, the program should behave in a largely predictable way''.
1239 @section Notation Used in This Chapter
1241 (The following information augments or overrides the information in
1242 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1244 Chapter 1 of that document otherwise serves as the basis
1245 for the relevant aspects of GNU Fortran.)
1247 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
1248 and ``must not'' and ``may not'' denote prohibition.
1249 Terms such as ``might'', ``should'', and ``can'' generally add little or
1250 nothing in the way of weight to the GNU Fortran language itself,
1251 but are used to explain or illustrate the language.
1256 ``The @code{FROBNITZ} statement must precede all executable
1257 statements in a program unit, and may not specify any dummy
1258 arguments. It may specify local or common variables and arrays.
1259 Its use should be limited to portions of the program designed to
1260 be non-portable and system-specific, because it might cause the
1261 containing program unit to behave quite differently on different
1265 Insofar as the GNU Fortran language is specified,
1266 the requirements and permissions denoted by the above sample statement
1267 are limited to the placement of the statement and the kinds of
1268 things it may specify.
1269 The rest of the statement---the content regarding non-portable portions
1270 of the program and the differing behavior of program units containing
1271 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
1273 That content offers advice and warnings about the @code{FROBNITZ}
1276 @emph{Remember:} The GNU Fortran language definition specifies
1277 both what constitutes a valid GNU Fortran program and how,
1278 given such a program, a valid GNU Fortran implementation is
1279 to interpret that program.
1281 It is @emph{not} incumbent upon a valid GNU Fortran implementation
1282 to behave in any particular way, any consistent way, or any
1283 predictable way when it is asked to interpret input that is
1284 @emph{not} a valid GNU Fortran program.
1286 Such input is said to have @dfn{undefined} behavior when
1287 interpreted by a valid GNU Fortran implementation, though
1288 an implementation may choose to specify behaviors for some
1289 cases of inputs that are not valid GNU Fortran programs.
1291 Other notation used herein is that of the GNU texinfo format,
1292 which is used to generate printed hardcopy, on-line hypertext
1293 (Info), and on-line HTML versions, all from a single source
1295 This notation is used as follows:
1299 Keywords defined by the GNU Fortran language are shown
1300 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
1303 Note that, in practice, many Fortran programs are written
1304 in lowercase---uppercase is used in this manual as a
1305 means to readily distinguish keywords and sample Fortran-related
1306 text from the prose in this document.
1309 Portions of actual sample program, input, or output text
1310 look like this: @samp{Actual program text}.
1312 Generally, uppercase is used for all Fortran-specific and
1313 Fortran-related text, though this does not always include
1314 literal text within Fortran code.
1316 For example: @samp{PRINT *, 'My name is Bob'}.
1319 A metasyntactic variable---that is, a name used in this document
1320 to serve as a placeholder for whatever text is used by the
1321 user or programmer---appears as shown in the following example:
1323 ``The @code{INTEGER @var{ivar}} statement specifies that
1324 @var{ivar} is a variable or array of type @code{INTEGER}.''
1326 In the above example, any valid text may be substituted for
1327 the metasyntactic variable @var{ivar} to make the statement
1328 apply to a specific instance, as long as the same text is
1329 substituted for @emph{both} occurrences of @var{ivar}.
1332 Ellipses (``@dots{}'') are used to indicate further text that
1333 is either unimportant or expanded upon further, elsewhere.
1336 Names of data types are in the style of Fortran 90, in most
1339 @xref{Kind Notation}, for information on the relationship
1340 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
1341 and the more traditional, less portably concise nomenclature
1342 (such as @code{INTEGER*4}).
1345 @node Terms and Concepts
1346 @section Fortran Terms and Concepts
1348 (The following information augments or overrides the information in
1349 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1351 Chapter 2 of that document otherwise serves as the basis
1352 for the relevant aspects of GNU Fortran.)
1356 * Statements Comments Lines::
1357 * Scope of Names and Labels::
1360 @node Syntactic Items
1361 @subsection Syntactic Items
1363 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
1365 @cindex limits, lengths of names
1366 In GNU Fortran, a symbolic name is at least one character long,
1367 and has no arbitrary upper limit on length.
1368 However, names of entities requiring external linkage (such as
1369 external functions, external subroutines, and @code{COMMON} areas)
1370 might be restricted to some arbitrary length by the system.
1371 Such a restriction is no more constrained than that of one
1372 through six characters.
1374 Underscores (@samp{_}) are accepted in symbol names after the first
1375 character (which must be a letter).
1377 @node Statements Comments Lines
1378 @subsection Statements, Comments, and Lines
1380 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
1382 @cindex trailing comment
1384 @cindex characters, comment
1386 @cindex exclamation point
1387 @cindex continuation character
1388 @cindex characters, continuation
1389 Use of an exclamation point (@samp{!}) to begin a
1390 trailing comment (a comment that extends to the end of the same
1391 source line) is permitted under the following conditions:
1395 The exclamation point does not appear in column 6.
1396 Otherwise, it is treated as an indicator of a continuation
1400 The exclamation point appears outside a character or Hollerith
1402 Otherwise, the exclamation point is considered part of the
1406 The exclamation point appears to the left of any other possible
1408 That is, a trailing comment may contain exclamation points
1409 in their commentary text.
1414 @cindex statements, separated by semicolon
1415 Use of a semicolon (@samp{;}) as a statement separator
1416 is permitted under the following conditions:
1420 The semicolon appears outside a character or Hollerith
1422 Otherwise, the semicolon is considered part of the
1426 The semicolon appears to the left of a trailing comment.
1427 Otherwise, the semicolon is considered part of that
1431 Neither a logical @code{IF} statement nor a non-construct
1432 @code{WHERE} statement (a Fortran 90 feature) may be
1433 followed (in the same, possibly continued, line) by
1434 a semicolon used as a statement separator.
1436 This restriction avoids the confusion
1437 that can result when reading a line such as:
1440 IF (VALIDP) CALL FOO; CALL BAR
1444 Some readers might think the @samp{CALL BAR} is executed
1445 only if @samp{VALIDP} is @code{.TRUE.}, while others might
1446 assume its execution is unconditional.
1448 (At present, @command{g77} does not diagnose code that
1449 violates this restriction.)
1452 @node Scope of Names and Labels
1453 @subsection Scope of Symbolic Names and Statement Labels
1456 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
1458 Included in the list of entities that have a scope of a
1459 program unit are construct names (a Fortran 90 feature).
1460 @xref{Construct Names}, for more information.
1462 @node Characters Lines Sequence
1463 @section Characters, Lines, and Execution Sequence
1465 (The following information augments or overrides the information in
1466 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1468 Chapter 3 of that document otherwise serves as the basis
1469 for the relevant aspects of GNU Fortran.)
1474 * Continuation Line::
1476 * Statement Labels::
1479 * Cpp-style directives::
1483 @subsection GNU Fortran Character Set
1486 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
1488 Letters include uppercase letters (the twenty-six characters
1489 of the English alphabet) and lowercase letters (their lowercase
1491 Generally, lowercase letters may be used in place of uppercase
1492 letters, though in character and Hollerith constants, they
1495 Special characters include:
1501 Semicolon (@samp{;})
1505 @cindex exclamation point
1506 Exclamation point (@samp{!})
1510 @cindex double quote
1511 Double quote (@samp{"})
1516 Backslash (@samp{\})
1520 @cindex question mark
1521 Question mark (@samp{?})
1527 Hash mark (@samp{#})
1532 Ampersand (@samp{&})
1536 @cindex percent sign
1537 Percent sign (@samp{%})
1542 Underscore (@samp{_})
1548 @cindex open bracket
1549 @cindex left bracket
1550 Open angle (@samp{<})
1556 @cindex close bracket
1557 @cindex right bracket
1558 Close angle (@samp{>})
1561 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
1562 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
1563 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
1570 Note that this document refers to @key{SPC} as @dfn{space},
1571 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
1576 @cindex source file format
1577 @cindex source format
1578 @cindex file, source
1580 @cindex code, source
1584 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
1586 The way a Fortran compiler views source files depends entirely on the
1587 implementation choices made for the compiler, since those choices
1588 are explicitly left to the implementation by the published Fortran
1591 The GNU Fortran language mandates a view applicable to UNIX-like
1592 text files---files that are made up of an arbitrary number of lines,
1593 each with an arbitrary number of characters (sometimes called stream-based
1596 This view does not apply to types of files that are specified as
1597 having a particular number of characters on every single line (sometimes
1598 referred to as record-based files).
1600 Because a ``line in a program unit is a sequence of 72 characters'',
1601 to quote X3.9-1978, the GNU Fortran language specifies that a
1602 stream-based text file is translated to GNU Fortran lines as follows:
1606 A newline in the file is the character that represents the end of
1607 a line of text to the underlying system.
1608 For example, on ASCII-based systems, a newline is the @key{NL}
1609 character, which has ASCII value 10 (decimal).
1612 Each newline in the file serves to end the line of text that precedes
1613 it (and that does not contain a newline).
1616 The end-of-file marker (@code{EOF}) also serves to end the line
1617 of text that precedes it (and that does not contain a newline).
1623 Any line of text that is shorter than 72 characters is padded to that length
1624 with spaces (called ``blanks'' in the standard).
1627 Any line of text that is longer than 72 characters is truncated to that
1628 length, but the truncated remainder must consist entirely of spaces.
1631 Characters other than newline and the GNU Fortran character set
1635 For the purposes of the remainder of this description of the GNU
1636 Fortran language, the translation described above has already
1637 taken place, unless otherwise specified.
1639 The result of the above translation is that the source file appears,
1640 in terms of the remainder of this description of the GNU Fortran language,
1641 as if it had an arbitrary
1642 number of 72-character lines, each character being among the GNU Fortran
1645 For example, if the source file itself has two newlines in a row,
1646 the second newline becomes, after the above translation, a single
1647 line containing 72 spaces.
1649 @node Continuation Line
1650 @subsection Continuation Line
1651 @cindex continuation line, number of
1652 @cindex lines, continuation
1653 @cindex number of continuation lines
1654 @cindex limits, continuation lines
1656 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
1658 A continuation line is any line that both
1662 Contains a continuation character, and
1665 Contains only spaces in columns 1 through 5
1668 A continuation character is any character of the GNU Fortran character set
1669 other than space (@key{SPC}) or zero (@samp{0})
1670 in column 6, or a digit (@samp{0} through @samp{9}) in column
1671 7 through 72 of a line that has only spaces to the left of that
1674 The continuation character is ignored as far as the content of
1675 the statement is concerned.
1677 The GNU Fortran language places no limit on the number of
1678 continuation lines in a statement.
1679 In practice, the limit depends on a variety of factors, such as
1680 available memory, statement content, and so on, but no
1681 GNU Fortran system may impose an arbitrary limit.
1684 @subsection Statements
1686 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
1688 Statements may be written using an arbitrary number of continuation
1691 Statements may be separated using the semicolon (@samp{;}), except
1692 that the logical @code{IF} and non-construct @code{WHERE} statements
1693 may not be separated from subsequent statements using only a semicolon
1694 as statement separator.
1696 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
1697 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
1699 These alternatives may be written as normal statements---they are not
1700 subject to the restrictions of the @code{END} statement.
1702 However, no statement other than @code{END} may have an initial line
1703 that appears to be an @code{END} statement---even @code{END PROGRAM},
1704 for example, must not be written as:
1711 @node Statement Labels
1712 @subsection Statement Labels
1714 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
1716 A statement separated from its predecessor via a semicolon may be
1721 The semicolon is followed by the label for the statement,
1722 which in turn follows the label.
1725 The label must be no more than five digits in length.
1728 The first digit of the label for the statement is not
1729 the first non-space character on a line.
1730 Otherwise, that character is treated as a continuation
1734 A statement may have only one label defined for it.
1737 @subsection Order of Statements and Lines
1739 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
1741 Generally, @code{DATA} statements may precede executable statements.
1742 However, specification statements pertaining to any entities
1743 initialized by a @code{DATA} statement must precede that @code{DATA}
1746 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
1747 @samp{INTEGER J} is permitted.
1749 The last line of a program unit may be an @code{END} statement,
1754 An @code{END PROGRAM} statement, if the program unit is a main program.
1757 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
1760 An @code{END FUNCTION} statement, if the program unit is a function.
1763 An @code{END BLOCK DATA} statement, if the program unit is a block data.
1767 @subsection Including Source Text
1768 @cindex INCLUDE directive
1770 Additional source text may be included in the processing of
1771 the source file via the @code{INCLUDE} directive:
1774 INCLUDE @var{filename}
1778 The source text to be included is identified by @var{filename},
1779 which is a literal GNU Fortran character constant.
1780 The meaning and interpretation of @var{filename} depends on the
1781 implementation, but typically is a filename.
1783 (@command{g77} treats it as a filename that it searches for
1784 in the current directory and/or directories specified
1785 via the @option{-I} command-line option.)
1787 The effect of the @code{INCLUDE} directive is as if the
1788 included text directly replaced the directive in the source
1789 file prior to interpretation of the program.
1790 Included text may itself use @code{INCLUDE}.
1791 The depth of nested @code{INCLUDE} references depends on
1792 the implementation, but typically is a positive integer.
1794 This virtual replacement treats the statements and @code{INCLUDE}
1795 directives in the included text as syntactically distinct from
1796 those in the including text.
1798 Therefore, the first non-comment line of the included text
1799 must not be a continuation line.
1800 The included text must therefore have, after the non-comment
1801 lines, either an initial line (statement), an @code{INCLUDE}
1802 directive, or nothing (the end of the included text).
1804 Similarly, the including text may end the @code{INCLUDE}
1805 directive with a semicolon or the end of the line, but it
1806 cannot follow an @code{INCLUDE} directive at the end of its
1807 line with a continuation line.
1808 Thus, the last statement in an included text may not be
1811 Any statements between two @code{INCLUDE} directives on the
1812 same line are treated as if they appeared in between the
1813 respective included texts.
1817 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
1821 If the text included by @samp{INCLUDE 'A'} constitutes
1822 a @samp{PRINT *, 'A'} statement and the text included by
1823 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
1824 then the output of the above sample program would be
1833 (with suitable allowances for how an implementation defines
1834 its handling of output).
1836 Included text must not include itself directly or indirectly,
1837 regardless of whether the @var{filename} used to reference
1838 the text is the same.
1840 Note that @code{INCLUDE} is @emph{not} a statement.
1841 As such, it is neither a non-executable or executable
1843 However, if the text it includes constitutes one or more
1844 executable statements, then the placement of @code{INCLUDE}
1845 is subject to effectively the same restrictions as those
1846 on executable statements.
1848 An @code{INCLUDE} directive may be continued across multiple
1849 lines as if it were a statement.
1850 This permits long names to be used for @var{filename}.
1852 @node Cpp-style directives
1853 @subsection Cpp-style directives
1855 @cindex preprocessor
1857 @code{cpp} output-style @code{#} directives
1858 (@pxref{C Preprocessor Output,,, cpp, The C Preprocessor})
1859 are recognized by the compiler even
1860 when the preprocessor isn't run on the input (as it is when compiling
1861 @samp{.F} files). (Note the distinction between these @command{cpp}
1862 @code{#} @emph{output} directives and @code{#line} @emph{input}
1865 @node Data Types and Constants
1866 @section Data Types and Constants
1868 (The following information augments or overrides the information in
1869 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
1871 Chapter 4 of that document otherwise serves as the basis
1872 for the relevant aspects of GNU Fortran.)
1874 To more concisely express the appropriate types for
1875 entities, this document uses the more concise
1876 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
1877 instead of the more traditional, but less portably concise,
1878 byte-size-based nomenclature such as @code{INTEGER*4},
1879 wherever reasonable.
1881 When referring to generic types---in contexts where the
1882 specific precision and range of a type are not important---this
1883 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
1884 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
1886 In some cases, the context requires specification of a
1888 This document uses the @samp{KIND=} notation to accomplish
1889 this throughout, sometimes supplying the more traditional
1890 notation for clarification, though the traditional notation
1891 might not work the same way on all GNU Fortran implementations.
1893 Use of @samp{KIND=} makes this document more concise because
1894 @command{g77} is able to define values for @samp{KIND=} that
1895 have the same meanings on all systems, due to the way the
1896 Fortran 90 standard specifies these values are to be used.
1898 (In particular, that standard permits an implementation to
1899 arbitrarily assign nonnegative values.
1900 There are four distinct sets of assignments: one to the @code{CHARACTER}
1901 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
1902 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
1903 Implementations are free to assign these values in any order,
1904 leave gaps in the ordering of assignments, and assign more than
1905 one value to a representation.)
1907 This makes @samp{KIND=} values superior to the values used
1908 in non-standard statements such as @samp{INTEGER*4}, because
1909 the meanings of the values in those statements vary from machine
1910 to machine, compiler to compiler, even operating system to
1913 However, use of @samp{KIND=} is @emph{not} generally recommended
1914 when writing portable code (unless, for example, the code is
1915 going to be compiled only via @command{g77}, which is a widely
1917 GNU Fortran does not yet have adequate language constructs to
1918 permit use of @samp{KIND=} in a fashion that would make the
1919 code portable to Fortran 90 implementations; and, this construct
1920 is known to @emph{not} be accepted by many popular FORTRAN 77
1921 implementations, so it cannot be used in code that is to be ported
1924 The distinction here is that this document is able to use
1925 specific values for @samp{KIND=} to concisely document the
1926 types of various operations and operands.
1928 A Fortran program should use the FORTRAN 77 designations for the
1929 appropriate GNU Fortran types---such as @code{INTEGER} for
1930 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
1931 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
1932 where no such designations exist, make use of appropriate
1933 techniques (preprocessor macros, parameters, and so on)
1934 to specify the types in a fashion that may be easily adjusted
1935 to suit each particular implementation to which the program
1937 (These types generally won't need to be adjusted for ports of
1940 Further details regarding GNU Fortran data types and constants
1951 @subsection Data Types
1953 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
1955 GNU Fortran supports these types:
1959 Integer (generic type @code{INTEGER})
1962 Real (generic type @code{REAL})
1968 Complex (generic type @code{COMPLEX})
1971 Logical (generic type @code{LOGICAL})
1974 Character (generic type @code{CHARACTER})
1980 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
1982 The generic types shown above are referred to in this document
1983 using only their generic type names.
1984 Such references usually indicate that any specific type (kind)
1985 of that generic type is valid.
1987 For example, a context described in this document as accepting
1988 the @code{COMPLEX} type also is likely to accept the
1989 @code{DOUBLE COMPLEX} type.
1991 The GNU Fortran language supports three ways to specify
1992 a specific kind of a generic type.
1995 * Double Notation:: As in @code{DOUBLE COMPLEX}.
1996 * Star Notation:: As in @code{INTEGER*4}.
1997 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
2000 @node Double Notation
2001 @subsubsection Double Notation
2003 The GNU Fortran language supports two uses of the keyword
2004 @code{DOUBLE} to specify a specific kind of type:
2008 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
2011 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
2014 Use one of the above forms where a type name is valid.
2016 While use of this notation is popular, it doesn't scale
2017 well in a language or dialect rich in intrinsic types,
2018 as is the case for the GNU Fortran language (especially
2019 planned future versions of it).
2021 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
2022 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
2023 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
2024 often are substituted for these, respectively, even though they
2025 do not always have the same meanings on all systems.
2026 (And, the fact that @samp{DOUBLE REAL} does not exist as such
2027 is an inconsistency.)
2029 Therefore, this document uses ``double notation'' only on occasion
2030 for the benefit of those readers who are accustomed to it.
2033 @subsubsection Star Notation
2034 @cindex *@var{n} notation
2036 The following notation specifies the storage size for a type:
2039 @var{generic-type}*@var{n}
2043 @var{generic-type} must be a generic type---one of
2044 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
2045 or @code{CHARACTER}.
2046 @var{n} must be one or more digits comprising a decimal
2047 integer number greater than zero.
2049 Use the above form where a type name is valid.
2051 The @samp{*@var{n}} notation specifies that the amount of storage
2052 occupied by variables and array elements of that type is @var{n}
2053 times the storage occupied by a @code{CHARACTER*1} variable.
2055 This notation might indicate a different degree of precision and/or
2056 range for such variables and array elements, and the functions that
2057 return values of types using this notation.
2058 It does not limit the precision or range of values of that type
2059 in any particular way---use explicit code to do that.
2061 Further, the GNU Fortran language requires no particular values
2062 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
2064 @command{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
2065 on all systems, for example,
2066 but not all implementations are required to do so, and @command{g77}
2067 is known to not support @code{REAL*1} on most (or all) systems.
2069 As a result, except for @var{generic-type} of @code{CHARACTER},
2070 uses of this notation should be limited to isolated
2071 portions of a program that are intended to handle system-specific
2072 tasks and are expected to be non-portable.
2074 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
2075 only @code{CHARACTER}, where it signifies not only the amount
2076 of storage occupied, but the number of characters in entities
2078 However, almost all Fortran compilers have supported this
2079 notation for generic types, though with a variety of meanings
2082 Specifications of types using the @samp{*@var{n}} notation
2083 always are interpreted as specifications of the appropriate
2084 types described in this document using the @samp{KIND=@var{n}}
2085 notation, described below.
2087 While use of this notation is popular, it doesn't serve well
2088 in the context of a widely portable dialect of Fortran, such as
2089 the GNU Fortran language.
2091 For example, even on one particular machine, two or more popular
2092 Fortran compilers might well disagree on the size of a type
2093 declared @code{INTEGER*2} or @code{REAL*16}.
2095 is known to be disagreement over such things among Fortran
2096 compilers on @emph{different} systems.
2098 Further, this notation offers no elegant way to specify sizes
2099 that are not even multiples of the ``byte size'' typically
2100 designated by @code{INTEGER*1}.
2101 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
2102 certainly be possible, but would perhaps be stretching the original
2103 intent of this notation beyond the breaking point in terms
2104 of widespread readability of documentation and code making use
2107 Therefore, this document uses ``star notation'' only on occasion
2108 for the benefit of those readers who are accustomed to it.
2111 @subsubsection Kind Notation
2112 @cindex KIND= notation
2114 The following notation specifies the kind-type selector of a type:
2117 @var{generic-type}(KIND=@var{n})
2121 Use the above form where a type name is valid.
2123 @var{generic-type} must be a generic type---one of
2124 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
2125 or @code{CHARACTER}.
2126 @var{n} must be an integer initialization expression that
2127 is a positive, nonzero value.
2129 Programmers are discouraged from writing these values directly
2131 Future versions of the GNU Fortran language will offer
2132 facilities that will make the writing of code portable
2133 to @command{g77} @emph{and} Fortran 90 implementations simpler.
2135 However, writing code that ports to existing FORTRAN 77
2136 implementations depends on avoiding the @samp{KIND=} construct.
2138 The @samp{KIND=} construct is thus useful in the context
2139 of GNU Fortran for two reasons:
2143 It provides a means to specify a type in a fashion that
2144 is portable across all GNU Fortran implementations (though
2145 not other FORTRAN 77 and Fortran 90 implementations).
2148 It provides a sort of Rosetta stone for this document to use
2149 to concisely describe the types of various operations and
2153 The values of @var{n} in the GNU Fortran language are
2154 assigned using a scheme that:
2158 Attempts to maximize the ability of readers
2159 of this document to quickly familiarize themselves
2160 with assignments for popular types
2163 Provides a unique value for each specific desired
2167 Provides a means to automatically assign new values so
2168 they have a ``natural'' relationship to existing values,
2169 if appropriate, or, if no such relationship exists, will
2170 not interfere with future values assigned on the basis
2171 of such relationships
2174 Avoids using values that are similar to values used
2175 in the existing, popular @samp{*@var{n}} notation,
2176 to prevent readers from expecting that these implied
2177 correspondences work on all GNU Fortran implementations
2180 The assignment system accomplishes this by assigning
2181 to each ``fundamental meaning'' of a specific type a
2182 unique prime number.
2183 Combinations of fundamental meanings---for example, a type
2184 that is two times the size of some other type---are assigned
2185 values of @var{n} that are the products of the values for
2186 those fundamental meanings.
2188 A prime value of @var{n} is never given more than one fundamental
2189 meaning, to avoid situations where some code or system
2190 cannot reasonably provide those meanings in the form of a
2193 The values of @var{n} assigned so far are:
2197 This value is reserved for future use.
2199 The planned future use is for this value to designate,
2200 explicitly, context-sensitive kind-type selection.
2201 For example, the expression @samp{1D0 * 0.1_0} would
2202 be equivalent to @samp{1D0 * 0.1D0}.
2205 This corresponds to the default types for
2206 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
2207 and @code{CHARACTER}, as appropriate.
2209 These are the ``default'' types described in the Fortran 90 standard,
2210 though that standard does not assign any particular @samp{KIND=}
2211 value to these types.
2213 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
2214 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
2217 This corresponds to types that occupy twice as much
2218 storage as the default types.
2219 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
2220 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
2222 These are the ``double precision'' types described in the Fortran 90
2224 though that standard does not assign any particular @samp{KIND=}
2225 value to these types.
2227 @var{n} of 4 thus corresponds to types that occupy four times
2228 as much storage as the default types, @var{n} of 8 to types that
2229 occupy eight times as much storage, and so on.
2231 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
2232 are not necessarily supported by every GNU Fortran implementation.
2235 This corresponds to types that occupy as much
2236 storage as the default @code{CHARACTER} type,
2237 which is the same effective type as @code{CHARACTER(KIND=1)}
2238 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
2240 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
2242 @var{n} of 6 thus corresponds to types that occupy twice as
2243 much storage as the @var{n}=3 types, @var{n} of 12 to types
2244 that occupy four times as much storage, and so on.
2246 These are not necessarily supported by every GNU Fortran
2250 This corresponds to types that occupy half the
2251 storage as the default (@var{n}=1) types.
2253 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
2255 @var{n} of 25 thus corresponds to types that occupy one-quarter
2256 as much storage as the default types.
2258 These are not necessarily supported by every GNU Fortran
2263 This is valid only as @code{INTEGER(KIND=7)} and
2264 denotes the @code{INTEGER} type that has the smallest
2265 storage size that holds a pointer on the system.
2267 A pointer representable by this type is capable of uniquely
2268 addressing a @code{CHARACTER*1} variable, array, array element,
2271 (Typically this is equivalent to @code{INTEGER*4} or,
2272 on 64-bit systems, @code{INTEGER*8}.
2273 In a compatible C implementation, it typically would
2274 be the same size and semantics of the C type @code{void *}.)
2277 Note that these are @emph{proposed} correspondences and might change
2278 in future versions of @command{g77}---avoid writing code depending
2279 on them while @command{g77}, and therefore the GNU Fortran language
2280 it defines, is in beta testing.
2282 Values not specified in the above list are reserved to
2283 future versions of the GNU Fortran language.
2285 Implementation-dependent meanings will be assigned new,
2286 unique prime numbers so as to not interfere with other
2287 implementation-dependent meanings, and offer the possibility
2288 of increasing the portability of code depending on such
2289 types by offering support for them in other GNU Fortran
2292 Other meanings that might be given unique values are:
2296 Types that make use of only half their storage size for
2297 representing precision and range.
2299 For example, some compilers offer options that cause
2300 @code{INTEGER} types to occupy the amount of storage
2301 that would be needed for @code{INTEGER(KIND=2)} types, but the
2302 range remains that of @code{INTEGER(KIND=1)}.
2305 The IEEE single floating-point type.
2308 Types with a specific bit pattern (endianness), such as the
2309 little-endian form of @code{INTEGER(KIND=1)}.
2310 These could permit, conceptually, use of portable code and
2311 implementations on data files written by existing systems.
2314 Future @emph{prime} numbers should be given meanings in as incremental
2315 a fashion as possible, to allow for flexibility and
2316 expressiveness in combining types.
2318 For example, instead of defining a prime number for little-endian
2319 IEEE doubles, one prime number might be assigned the meaning
2320 ``little-endian'', another the meaning ``IEEE double'', and the
2321 value of @var{n} for a little-endian IEEE double would thus
2322 naturally be the product of those two respective assigned values.
2323 (It could even be reasonable to have IEEE values result from the
2324 products of prime values denoting exponent and fraction sizes
2325 and meanings, hidden bit usage, availability and representations
2326 of special values such as subnormals, infinities, and Not-A-Numbers
2329 This assignment mechanism, while not inherently required for
2330 future versions of the GNU Fortran language, is worth using
2331 because it could ease management of the ``space'' of supported
2332 types much easier in the long run.
2334 The above approach suggests a mechanism for specifying inheritance
2335 of intrinsic (built-in) types for an entire, widely portable
2337 It is certainly reasonable that, unlike programmers of other languages
2338 offering inheritance mechanisms that employ verbose names for classes
2339 and subclasses, along with graphical browsers to elucidate the
2340 relationships, Fortran programmers would employ
2341 a mechanism that works by multiplying prime numbers together
2342 and finding the prime factors of such products.
2344 Most of the advantages for the above scheme have been explained
2346 One disadvantage is that it could lead to the defining,
2347 by the GNU Fortran language, of some fairly large prime numbers.
2348 This could lead to the GNU Fortran language being declared
2349 ``munitions'' by the United States Department of Defense.
2352 @subsection Constants
2354 @cindex types, constants
2356 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
2358 A @dfn{typeless constant} has one of the following forms:
2361 '@var{binary-digits}'B
2362 '@var{octal-digits}'O
2363 '@var{hexadecimal-digits}'Z
2364 '@var{hexadecimal-digits}'X
2368 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
2369 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
2370 and @samp{0123456789ABCDEFabcdef}, respectively.
2371 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
2374 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
2375 treated as typeless. @xref{Fortran Dialect Options,, Options
2376 Controlling Fortran Dialect}, for information on the
2377 @option{-ftypeless-boz} option.
2379 Typeless constants have values that depend on the context in which
2382 All other constants, called @dfn{typed constants}, are interpreted---converted
2383 to internal form---according to their inherent type.
2384 Thus, context is @emph{never} a determining factor for the type, and hence
2385 the interpretation, of a typed constant.
2386 (All constants in the ANSI FORTRAN 77 language are typed constants.)
2388 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
2389 Fortran (called default INTEGER in Fortran 90),
2390 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
2391 additional precision specified is lost, and even when used in a
2392 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
2393 and @samp{1D0} is always type @code{REAL(KIND=2)}.
2396 @subsection Integer Type
2398 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
2400 An integer constant also may have one of the following forms:
2403 B'@var{binary-digits}'
2404 O'@var{octal-digits}'
2405 Z'@var{hexadecimal-digits}'
2406 X'@var{hexadecimal-digits}'
2410 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
2411 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
2412 and @samp{0123456789ABCDEFabcdef}, respectively.
2413 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
2416 @node Character Type
2417 @subsection Character Type
2419 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
2421 @cindex double quoted character constants
2422 A character constant may be delimited by a pair of double quotes
2423 (@samp{"}) instead of apostrophes.
2424 In this case, an apostrophe within the constant represents
2425 a single apostrophe, while a double quote is represented in
2426 the source text of the constant by two consecutive double
2427 quotes with no intervening spaces.
2429 @cindex zero-length CHARACTER
2430 @cindex null CHARACTER strings
2431 @cindex empty CHARACTER strings
2432 @cindex strings, empty
2433 @cindex CHARACTER, null
2434 A character constant may be empty (have a length of zero).
2436 A character constant may include a substring specification,
2437 The value of such a constant is the value of the substring---for
2438 example, the value of @samp{'hello'(3:5)} is the same
2439 as the value of @samp{'llo'}.
2442 @section Expressions
2444 (The following information augments or overrides the information in
2445 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2447 Chapter 6 of that document otherwise serves as the basis
2448 for the relevant aspects of GNU Fortran.)
2455 @subsection The @code{%LOC()} Construct
2456 @cindex %LOC() construct
2462 The @code{%LOC()} construct is an expression
2463 that yields the value of the location of its argument,
2464 @var{arg}, in memory.
2465 The size of the type of the expression depends on the system---typically,
2466 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
2467 though it is actually type @code{INTEGER(KIND=7)}.
2469 The argument to @code{%LOC()} must be suitable as the
2470 left-hand side of an assignment statement.
2471 That is, it may not be a general expression involving
2472 operators such as addition, subtraction, and so on,
2473 nor may it be a constant.
2475 Use of @code{%LOC()} is recommended only for code that
2476 is accessing facilities outside of GNU Fortran, such as
2477 operating system or windowing facilities.
2478 It is best to constrain such uses to isolated portions of
2479 a program---portions that deal specifically and exclusively
2480 with low-level, system-dependent facilities.
2481 Such portions might well provide a portable interface for
2482 use by the program as a whole, but are themselves not
2483 portable, and should be thoroughly tested each time they
2484 are rebuilt using a new compiler or version of a compiler.
2486 Do not depend on @code{%LOC()} returning a pointer that
2487 can be safely used to @emph{define} (change) the argument.
2488 While this might work in some circumstances, it is hard
2489 to predict whether it will continue to work when a program
2490 (that works using this unsafe behavior)
2491 is recompiled using different command-line options or
2492 a different version of @command{g77}.
2494 Generally, @code{%LOC()} is safe when used as an argument
2495 to a procedure that makes use of the value of the corresponding
2496 dummy argument only during its activation, and only when
2497 such use is restricted to referencing (reading) the value
2498 of the argument to @code{%LOC()}.
2500 @emph{Implementation Note:} Currently, @command{g77} passes
2501 arguments (those not passed using a construct such as @code{%VAL()})
2502 by reference or descriptor, depending on the type of
2503 the actual argument.
2504 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
2505 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
2506 in fact might compile to identical code.
2508 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
2509 ``pass, by value, the address of @samp{I} in memory''.
2510 While @samp{CALL FOO(I)} might use that same approach in a
2511 particular version of @command{g77}, another version or compiler
2512 might choose a different implementation, such as copy-in/copy-out,
2513 to effect the desired behavior---and which will therefore not
2514 necessarily compile to the same code as would
2515 @samp{CALL FOO(%VAL(%LOC(I)))}
2516 using the same version or compiler.
2518 @xref{Debugging and Interfacing}, for detailed information on
2519 how this particular version of @command{g77} implements various
2522 @node Specification Statements
2523 @section Specification Statements
2525 (The following information augments or overrides the information in
2526 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2528 Chapter 8 of that document otherwise serves as the basis
2529 for the relevant aspects of GNU Fortran.)
2537 @subsection @code{NAMELIST} Statement
2538 @cindex NAMELIST statement
2539 @cindex statements, NAMELIST
2541 The @code{NAMELIST} statement, and related I/O constructs, are
2542 supported by the GNU Fortran language in essentially the same
2543 way as they are by @command{f2c}.
2545 This follows Fortran 90 with the restriction that on @code{NAMELIST}
2546 input, subscripts must have the form
2548 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
2552 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
2554 is allowed, but not, say,
2556 &xx x(:3,8::2)=1,2,3,4,5,6/
2559 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
2560 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
2562 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
2564 could be used instead of the example above.
2566 @node DOUBLE COMPLEX
2567 @subsection @code{DOUBLE COMPLEX} Statement
2568 @cindex DOUBLE COMPLEX
2570 @code{DOUBLE COMPLEX} is a type-statement (and type) that
2571 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
2573 @node Control Statements
2574 @section Control Statements
2576 (The following information augments or overrides the information in
2577 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2579 Chapter 11 of that document otherwise serves as the basis
2580 for the relevant aspects of GNU Fortran.)
2590 @subsection DO WHILE
2593 @cindex MIL-STD 1753
2595 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
2596 Fortran 90 standards, is provided by the GNU Fortran language.
2597 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
2603 @cindex MIL-STD 1753
2605 The @code{END DO} statement is provided by the GNU Fortran language.
2607 This statement is used in one of two ways:
2611 The Fortran 90 meaning, in which it specifies the termination
2612 point of a single @code{DO} loop started with a @code{DO} statement
2613 that specifies no termination label.
2616 The MIL-STD 1753 meaning, in which it specifies the termination
2617 point of one or more @code{DO} loops, all of which start with a
2618 @code{DO} statement that specify the label defined for the
2619 @code{END DO} statement.
2621 This kind of @code{END DO} statement is merely a synonym for
2622 @code{CONTINUE}, except it is permitted only when the statement
2623 is labeled and a target of one or more labeled @code{DO} loops.
2625 It is expected that this use of @code{END DO} will be removed from
2626 the GNU Fortran language in the future, though it is likely that
2627 it will long be supported by @command{g77} as a dialect form.
2630 @node Construct Names
2631 @subsection Construct Names
2632 @cindex construct names
2634 The GNU Fortran language supports construct names as defined
2635 by the Fortran 90 standard.
2636 These names are local to the program unit and are defined
2640 @var{construct-name}: @var{block-statement}
2644 Here, @var{construct-name} is the construct name itself;
2645 its definition is connoted by the single colon (@samp{:}); and
2646 @var{block-statement} is an @code{IF}, @code{DO},
2647 or @code{SELECT CASE} statement that begins a block.
2649 A block that is given a construct name must also specify the
2650 same construct name in its termination statement:
2653 END @var{block} @var{construct-name}
2657 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
2660 @node CYCLE and EXIT
2661 @subsection The @code{CYCLE} and @code{EXIT} Statements
2663 @cindex CYCLE statement
2664 @cindex EXIT statement
2665 @cindex statements, CYCLE
2666 @cindex statements, EXIT
2667 The @code{CYCLE} and @code{EXIT} statements specify that
2668 the remaining statements in the current iteration of a
2669 particular active (enclosing) @code{DO} loop are to be skipped.
2671 @code{CYCLE} specifies that these statements are skipped,
2672 but the @code{END DO} statement that marks the end of the
2673 @code{DO} loop be executed---that is, the next iteration,
2674 if any, is to be started.
2675 If the statement marking the end of the @code{DO} loop is
2676 not @code{END DO}---in other words, if the loop is not
2677 a block @code{DO}---the @code{CYCLE} statement does not
2678 execute that statement, but does start the next iteration (if any).
2680 @code{EXIT} specifies that the loop specified by the
2681 @code{DO} construct is terminated.
2683 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
2684 is the innermost enclosing @code{DO} loop when the following
2692 Otherwise, the following forms specify the construct name
2693 of the pertinent @code{DO} loop:
2696 CYCLE @var{construct-name}
2697 EXIT @var{construct-name}
2700 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
2702 However, they cannot be easily thought of as @code{GO TO} statements
2703 in obscure cases involving FORTRAN 77 loops.
2712 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2717 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
2718 above are equivalent to a @code{GO TO} statement to either label
2719 @samp{10} or @samp{20}.
2721 To understand the effect of @code{CYCLE} and @code{EXIT} in the
2722 above fragment, it is helpful to first translate it to its equivalent
2723 using only block @code{DO} loops:
2731 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2738 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
2739 to @code{GO TO} so they may be more easily understood by programmers
2740 accustomed to FORTRAN coding:
2745 IF (J .EQ. 5) GOTO 18
2747 IF (K .EQ. 3) GO TO 12
2748 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
2756 Thus, the @code{CYCLE} statement in the innermost loop skips over
2757 the @code{PRINT} statement as it begins the next iteration of the
2758 loop, while the @code{EXIT} statement in the middle loop ends that
2759 loop but @emph{not} the outermost loop.
2761 @node Functions and Subroutines
2762 @section Functions and Subroutines
2764 (The following information augments or overrides the information in
2765 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
2767 Chapter 15 of that document otherwise serves as the basis
2768 for the relevant aspects of GNU Fortran.)
2774 * Generics and Specifics::
2775 * REAL() and AIMAG() of Complex::
2776 * CMPLX() of DOUBLE PRECISION::
2778 * f77/f2c Intrinsics::
2779 * Table of Intrinsic Functions::
2783 @subsection The @code{%VAL()} Construct
2784 @cindex %VAL() construct
2790 The @code{%VAL()} construct specifies that an argument,
2791 @var{arg}, is to be passed by value, instead of by reference
2794 @code{%VAL()} is restricted to actual arguments in
2795 invocations of external procedures.
2797 Use of @code{%VAL()} is recommended only for code that
2798 is accessing facilities outside of GNU Fortran, such as
2799 operating system or windowing facilities.
2800 It is best to constrain such uses to isolated portions of
2801 a program---portions the deal specifically and exclusively
2802 with low-level, system-dependent facilities.
2803 Such portions might well provide a portable interface for
2804 use by the program as a whole, but are themselves not
2805 portable, and should be thoroughly tested each time they
2806 are rebuilt using a new compiler or version of a compiler.
2808 @emph{Implementation Note:} Currently, @command{g77} passes
2809 all arguments either by reference or by descriptor.
2811 Thus, use of @code{%VAL()} tends to be restricted to cases
2812 where the called procedure is written in a language other
2813 than Fortran that supports call-by-value semantics.
2814 (C is an example of such a language.)
2816 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
2817 for detailed information on
2818 how this particular version of @command{g77} passes arguments
2822 @subsection The @code{%REF()} Construct
2823 @cindex %REF() construct
2829 The @code{%REF()} construct specifies that an argument,
2830 @var{arg}, is to be passed by reference, instead of by
2831 value or descriptor.
2833 @code{%REF()} is restricted to actual arguments in
2834 invocations of external procedures.
2836 Use of @code{%REF()} is recommended only for code that
2837 is accessing facilities outside of GNU Fortran, such as
2838 operating system or windowing facilities.
2839 It is best to constrain such uses to isolated portions of
2840 a program---portions the deal specifically and exclusively
2841 with low-level, system-dependent facilities.
2842 Such portions might well provide a portable interface for
2843 use by the program as a whole, but are themselves not
2844 portable, and should be thoroughly tested each time they
2845 are rebuilt using a new compiler or version of a compiler.
2847 Do not depend on @code{%REF()} supplying a pointer to the
2848 procedure being invoked.
2849 While that is a likely implementation choice, other
2850 implementation choices are available that preserve Fortran
2851 pass-by-reference semantics without passing a pointer to
2852 the argument, @var{arg}.
2853 (For example, a copy-in/copy-out implementation.)
2855 @emph{Implementation Note:} Currently, @command{g77} passes
2857 (other than variables and arrays of type @code{CHARACTER})
2859 Future versions of, or dialects supported by, @command{g77} might
2860 not pass @code{CHARACTER} functions by reference.
2862 Thus, use of @code{%REF()} tends to be restricted to cases
2863 where @var{arg} is type @code{CHARACTER} but the called
2864 procedure accesses it via a means other than the method
2865 used for Fortran @code{CHARACTER} arguments.
2867 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
2868 how this particular version of @command{g77} passes arguments
2872 @subsection The @code{%DESCR()} Construct
2873 @cindex %DESCR() construct
2879 The @code{%DESCR()} construct specifies that an argument,
2880 @var{arg}, is to be passed by descriptor, instead of by
2883 @code{%DESCR()} is restricted to actual arguments in
2884 invocations of external procedures.
2886 Use of @code{%DESCR()} is recommended only for code that
2887 is accessing facilities outside of GNU Fortran, such as
2888 operating system or windowing facilities.
2889 It is best to constrain such uses to isolated portions of
2890 a program---portions the deal specifically and exclusively
2891 with low-level, system-dependent facilities.
2892 Such portions might well provide a portable interface for
2893 use by the program as a whole, but are themselves not
2894 portable, and should be thoroughly tested each time they
2895 are rebuilt using a new compiler or version of a compiler.
2897 Do not depend on @code{%DESCR()} supplying a pointer
2898 and/or a length passed by value
2899 to the procedure being invoked.
2900 While that is a likely implementation choice, other
2901 implementation choices are available that preserve the
2902 pass-by-reference semantics without passing a pointer to
2903 the argument, @var{arg}.
2904 (For example, a copy-in/copy-out implementation.)
2905 And, future versions of @command{g77} might change the
2906 way descriptors are implemented, such as passing a
2907 single argument pointing to a record containing the
2908 pointer/length information instead of passing that same
2909 information via two arguments as it currently does.
2911 @emph{Implementation Note:} Currently, @command{g77} passes
2912 all variables and arrays of type @code{CHARACTER}
2914 Future versions of, or dialects supported by, @command{g77} might
2915 pass @code{CHARACTER} functions by descriptor as well.
2917 Thus, use of @code{%DESCR()} tends to be restricted to cases
2918 where @var{arg} is not type @code{CHARACTER} but the called
2919 procedure accesses it via a means similar to the method
2920 used for Fortran @code{CHARACTER} arguments.
2922 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
2923 how this particular version of @command{g77} passes arguments
2926 @node Generics and Specifics
2927 @subsection Generics and Specifics
2928 @cindex generic intrinsics
2929 @cindex intrinsics, generic
2931 The ANSI FORTRAN 77 language defines generic and specific
2933 In short, the distinctions are:
2937 @emph{Specific} intrinsics have
2938 specific types for their arguments and a specific return
2942 @emph{Generic} intrinsics are treated,
2943 on a case-by-case basis in the program's source code,
2944 as one of several possible specific intrinsics.
2946 Typically, a generic intrinsic has a return type that
2947 is determined by the type of one or more of its arguments.
2950 The GNU Fortran language generalizes these concepts somewhat,
2951 especially by providing intrinsic subroutines and generic
2952 intrinsics that are treated as either a specific intrinsic subroutine
2953 or a specific intrinsic function (e.g. @code{SECOND}).
2955 However, GNU Fortran avoids generalizing this concept to
2956 the point where existing code would be accepted as meaning
2957 something possibly different than what was intended.
2959 For example, @code{ABS} is a generic intrinsic, so all working
2960 code written using @code{ABS} of an @code{INTEGER} argument
2961 expects an @code{INTEGER} return value.
2962 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
2963 argument returns an @code{INTEGER*2} return value.
2965 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
2966 an @code{INTEGER(KIND=1)} argument.
2967 Code that passes something other than an @code{INTEGER(KIND=1)}
2968 argument to @code{IABS} is not valid GNU Fortran code, because
2969 it is not clear what the author intended.
2971 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
2972 is not defined by the GNU Fortran language, because the programmer
2973 might have used that construct to mean any of the following, subtly
2978 Convert @samp{J} to @code{INTEGER(KIND=1)} first
2979 (as if @samp{IABS(INT(J))} had been written).
2982 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
2983 (as if @samp{INT(ABS(J))} had been written).
2986 No conversion (as if @samp{ABS(J)} had been written).
2989 The distinctions matter especially when types and values wider than
2990 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
2991 operations performing more ``arithmetic'' than absolute-value, are involved.
2993 The following sample program is not a valid GNU Fortran program, but
2994 might be accepted by other compilers.
2995 If so, the output is likely to be revealing in terms of how a given
2996 compiler treats intrinsics (that normally are specific) when they
2997 are given arguments that do not conform to their stated requirements:
2999 @cindex JCB002 program
3003 C Modified 1999-02-15 (Burley) to delete my email address.
3004 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
3005 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
3008 C Written by James Craig Burley 1997-02-20.
3011 C Determine how compilers handle non-standard IDIM
3012 C on INTEGER*2 operands, which presumably can be
3013 C extrapolated into understanding how the compiler
3014 C generally treats specific intrinsics that are passed
3015 C arguments not of the correct types.
3017 C If your compiler implements INTEGER*2 and INTEGER
3018 C as the same type, change all INTEGER*2 below to
3023 INTEGER*2 ISMALL, ILARGE
3024 INTEGER*2 ITOOLG, ITWO
3028 C Find smallest INTEGER*2 number.
3032 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
3037 C Find largest INTEGER*2 number.
3041 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
3046 C Multiplying by two adds stress to the situation.
3050 C Need a number that, added to -2, is too wide to fit in I*2.
3054 C Use IDIM the straightforward way.
3056 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
3058 C Calculate result for first interpretation.
3060 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
3062 C Calculate result for second interpretation.
3064 ITMP = ILARGE - ISMALL
3065 I3 = (INT (ITMP)) * ITWO + ITOOLG
3067 C Calculate result for third interpretation.
3069 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
3073 PRINT *, 'ILARGE=', ILARGE
3074 PRINT *, 'ITWO=', ITWO
3075 PRINT *, 'ITOOLG=', ITOOLG
3076 PRINT *, 'ISMALL=', ISMALL
3085 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
3086 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
3089 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
3090 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
3093 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
3094 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
3097 PRINT *, 'Results need careful analysis.'
3101 No future version of the GNU Fortran language
3102 will likely permit specific intrinsic invocations with wrong-typed
3103 arguments (such as @code{IDIM} in the above example), since
3104 it has been determined that disagreements exist among
3105 many production compilers on the interpretation of
3107 These disagreements strongly suggest that Fortran programmers,
3108 and certainly existing Fortran programs, disagree about the
3109 meaning of such invocations.
3111 The first version of @code{JCB002} didn't accommodate some compilers'
3112 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
3114 In such a case, these compilers apparently convert both
3115 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
3116 instead of doing an @code{INTEGER*2} subtraction on the
3117 original values in @samp{I1} and @samp{I2}.
3119 However, the results of the careful analyses done on the outputs
3120 of programs compiled by these various compilers show that they
3121 all implement either @samp{Interp 1} or @samp{Interp 2} above.
3123 Specifically, it is believed that the new version of @code{JCB002}
3124 above will confirm that:
3128 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
3129 @command{f77} compilers all implement @samp{Interp 1}.
3132 IRIX 5.3 @command{f77} compiler implements @samp{Interp 2}.
3135 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
3136 and IRIX 6.1 @command{f77} compilers all implement @samp{Interp 3}.
3139 If you get different results than the above for the stated
3140 compilers, or have results for other compilers that might be
3141 worth adding to the above list, please let us know the details
3142 (compiler product, version, machine, results, and so on).
3144 @node REAL() and AIMAG() of Complex
3145 @subsection @code{REAL()} and @code{AIMAG()} of Complex
3146 @cindex @code{Real} intrinsic
3147 @cindex intrinsics, @code{Real}
3148 @cindex @code{AImag} intrinsic
3149 @cindex intrinsics, @code{AImag}
3151 The GNU Fortran language disallows @code{REAL(@var{expr})}
3152 and @code{AIMAG(@var{expr})},
3153 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
3154 except when they are used in the following way:
3157 REAL(REAL(@var{expr}))
3158 REAL(AIMAG(@var{expr}))
3162 The above forms explicitly specify that the desired effect
3163 is to convert the real or imaginary part of @var{expr}, which might
3164 be some @code{REAL} type other than @code{REAL(KIND=1)},
3165 to type @code{REAL(KIND=1)},
3166 and have that serve as the value of the expression.
3168 The GNU Fortran language offers clearly named intrinsics to extract the
3169 real and imaginary parts of a complex entity without any
3173 REALPART(@var{expr})
3174 IMAGPART(@var{expr})
3177 To express the above using typical extended FORTRAN 77,
3178 use the following constructs
3179 (when @var{expr} is @code{COMPLEX(KIND=2)}):
3186 The FORTRAN 77 language offers no way
3187 to explicitly specify the real and imaginary parts of a complex expression of
3188 arbitrary type, apparently as a result of requiring support for
3189 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
3190 The concepts of converting an expression to type @code{REAL(KIND=1)} and
3191 of extracting the real part of a complex expression were
3192 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
3193 they happened to have the exact same effect in that language
3194 (due to having only one @code{COMPLEX} type).
3196 @emph{Note:} When @option{-ff90} is in effect,
3197 @command{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
3198 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
3199 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
3200 treated as @samp{REAL(REALPART(@var{expr}))}.
3202 @xref{Ugly Complex Part Extraction}, for more information.
3204 @node CMPLX() of DOUBLE PRECISION
3205 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
3206 @cindex @code{Cmplx} intrinsic
3207 @cindex intrinsics, @code{Cmplx}
3209 In accordance with Fortran 90 and at least some (perhaps all)
3210 other compilers, the GNU Fortran language defines @code{CMPLX()}
3211 as always returning a result that is type @code{COMPLEX(KIND=1)}.
3213 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
3214 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
3217 CMPLX(SNGL(D1), SNGL(D2))
3220 (It was necessary for Fortran 90 to specify this behavior
3221 for @code{DOUBLE PRECISION} arguments, since that is
3222 the behavior mandated by FORTRAN 77.)
3224 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
3225 which is provided by some FORTRAN 77 compilers to construct
3226 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
3228 However, this solution does not scale well when more @code{COMPLEX} types
3229 (having various precisions and ranges) are offered by Fortran implementations.
3231 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
3232 an extra argument used to specify the desired kind of complex
3234 However, this solution is somewhat awkward to use, and
3235 @command{g77} currently does not support it.
3237 The GNU Fortran language provides a simple way to build a complex
3238 value out of two numbers, with the precise type of the value
3239 determined by the types of the two numbers (via the usual
3240 type-promotion mechanism):
3243 COMPLEX(@var{real}, @var{imag})
3246 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
3247 performs no conversion other than to put them together to form a
3248 complex result of the same (complex version of real) type.
3250 @xref{Complex Intrinsic}, for more information.
3253 @subsection MIL-STD 1753 Support
3254 @cindex MIL-STD 1753
3256 The GNU Fortran language includes the MIL-STD 1753 intrinsics
3257 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
3258 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
3259 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
3261 @node f77/f2c Intrinsics
3262 @subsection @command{f77}/@command{f2c} Intrinsics
3264 The bit-manipulation intrinsics supported by traditional
3265 @command{f77} and by @command{f2c} are available in the GNU Fortran language.
3266 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
3269 Also supported are the intrinsics @code{CDABS},
3270 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
3271 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
3272 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
3273 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
3276 @node Table of Intrinsic Functions
3277 @subsection Table of Intrinsic Functions
3278 @cindex intrinsics, table of
3279 @cindex table of intrinsics
3281 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
3283 The GNU Fortran language adds various functions, subroutines, types,
3284 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
3285 The complete set of intrinsics supported by the GNU Fortran language
3288 Note that a name is not treated as that of an intrinsic if it is
3289 specified in an @code{EXTERNAL} statement in the same program unit;
3290 if a command-line option is used to disable the groups to which
3291 the intrinsic belongs; or if the intrinsic is not named in an
3292 @code{INTRINSIC} statement and a command-line option is used to
3293 hide the groups to which the intrinsic belongs.
3295 So, it is recommended that any reference in a program unit to
3296 an intrinsic procedure that is not a standard FORTRAN 77
3297 intrinsic be accompanied by an appropriate @code{INTRINSIC}
3298 statement in that program unit.
3299 This sort of defensive programming makes it more
3300 likely that an implementation will issue a diagnostic rather
3301 than generate incorrect code for such a reference.
3303 The terminology used below is based on that of the Fortran 90
3304 standard, so that the text may be more concise and accurate:
3308 @code{OPTIONAL} means the argument may be omitted.
3311 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
3312 (generally named @samp{A}) may be specified.
3315 @samp{scalar} means the argument must not be an array (must
3316 be a variable or array element, or perhaps a constant if expressions
3320 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
3323 @code{INTENT(IN)} means the argument must be an expression
3324 (such as a constant or a variable that is defined upon invocation
3328 @code{INTENT(OUT)} means the argument must be definable by the
3329 invocation of the intrinsic (that is, must not be a constant nor
3330 an expression involving operators other than array reference and
3331 substring reference).
3334 @code{INTENT(INOUT)} means the argument must be defined prior to,
3335 and definable by, invocation of the intrinsic (a combination of
3336 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
3339 @xref{Kind Notation}, for an explanation of @code{KIND}.
3343 (Note that the empty lines appearing in the menu below
3344 are not intentional---they result from a bug in the
3345 GNU @command{makeinfo} program@dots{}a program that, if it
3346 did not exist, would leave this document in far worse shape!)
3349 @c The actual documentation for intrinsics comes from
3350 @c intdoc.texi, which in turn is automatically generated
3351 @c from the internal g77 tables in intrin.def _and_ the
3352 @c largely hand-written text in intdoc.h. So, if you want
3353 @c to change or add to existing documentation on intrinsics,
3354 @c you probably want to edit intdoc.h.
3366 @include intdoc.texi
3368 @node Scope and Classes of Names
3369 @section Scope and Classes of Symbolic Names
3370 @cindex symbol names, scope and classes
3373 (The following information augments or overrides the information in
3374 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3376 Chapter 18 of that document otherwise serves as the basis
3377 for the relevant aspects of GNU Fortran.)
3380 * Underscores in Symbol Names::
3383 @node Underscores in Symbol Names
3384 @subsection Underscores in Symbol Names
3387 Underscores (@samp{_}) are accepted in symbol names after the first
3388 character (which must be a letter).
3394 A dollar sign at the end of an output format specification suppresses
3395 the newline at the end of the output.
3397 @cindex <> edit descriptor
3398 @cindex edit descriptor, <>
3399 Edit descriptors in @code{FORMAT} statements may contain compile-time
3400 @code{INTEGER} constant expressions in angle brackets, such as
3402 10 FORMAT (I<WIDTH>)
3405 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
3407 These Fortran 90 features are supported:
3410 @cindex FORMAT descriptors
3411 @cindex Z edit descriptor
3412 @cindex edit descriptor, Z
3413 @cindex O edit descriptor
3414 @cindex edit descriptor, O
3415 The @code{O} and @code{Z} edit descriptors are supported for I/O of
3416 integers in octal and hexadecimal formats, respectively.
3418 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
3419 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
3420 specifier is supported.
3423 @node Fortran 90 Features
3424 @section Fortran 90 Features
3426 @cindex extensions, from Fortran 90
3428 For convenience this section collects a list (probably incomplete) of
3429 the Fortran 90 features supported by the GNU Fortran language, even if
3430 they are documented elsewhere.
3431 @xref{Characters Lines Sequence,,@asis{Characters, Lines, and Execution Sequence}},
3432 for information on additional fixed source form lexical issues.
3433 @cindex @option{-ffree-form}
3434 Further, the free source form is supported through the
3435 @option{-ffree-form} option.
3436 @cindex @option{-ff90}
3437 Other Fortran 90 features can be turned on by the @option{-ff90} option;
3438 see @ref{Fortran 90}.
3439 For information on the Fortran 90 intrinsics available,
3440 see @ref{Table of Intrinsic Functions}.
3443 @item Automatic arrays in procedures
3444 @item Character assignments
3445 @cindex character assignments
3446 In character assignments, the variable being assigned may occur on the
3447 right hand side of the assignment.
3448 @item Character strings
3449 @cindex double quoted character constants
3450 Strings may have zero length and substrings of character constants are
3451 permitted. Character constants may be enclosed in double quotes
3452 (@code{"}) as well as single quotes. @xref{Character Type}.
3453 @item Construct names
3454 (Symbolic tags on blocks.) @xref{Construct Names}.
3455 @item @code{CYCLE} and @code{EXIT}
3456 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
3457 @item @code{DOUBLE COMPLEX}
3458 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement}.
3459 @item @code{DO WHILE}
3461 @item @code{END} decoration
3466 @item @code{IMPLICIT NONE}
3467 @item @code{INCLUDE} statements
3469 @item List-directed and namelist I/O on internal files
3470 @item Binary, octal and hexadecimal constants
3471 These are supported more generally than required by Fortran 90.
3472 @xref{Integer Type}.
3473 @item @samp{O} and @samp{Z} edit descriptors
3474 @item @code{NAMELIST}
3476 @item @code{OPEN} specifiers
3477 @code{STATUS='REPLACE'} is supported.
3478 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
3479 @code{STATUS='SCRATCH'} is supplied.
3480 @item @code{FORMAT} edit descriptors
3481 @cindex FORMAT descriptors
3482 @cindex Z edit descriptor
3483 @cindex edit descriptor, Z
3484 The @code{Z} edit descriptor is supported.
3485 @item Relational operators
3486 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
3487 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
3488 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
3489 @item @code{SELECT CASE}
3490 Not fully implemented.
3491 @xref{SELECT CASE on CHARACTER Type,, @code{SELECT CASE} on @code{CHARACTER} Type}.
3492 @item Specification statements
3493 A limited subset of the Fortran 90 syntax and semantics for variable
3494 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
3495 (@code{KIND} is of limited usefulness in the absence of the
3496 @code{KIND}-related intrinsics, since these intrinsics permit writing
3497 more widely portable code.) An example of supported @code{KIND} usage
3500 INTEGER (KIND=1) :: FOO=1, BAR=2
3501 CHARACTER (LEN=3) FOO
3503 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
3506 @node Other Dialects
3507 @chapter Other Dialects
3509 GNU Fortran supports a variety of features that are not
3510 considered part of the GNU Fortran language itself, but
3511 are representative of various dialects of Fortran that
3512 @command{g77} supports in whole or in part.
3514 Any of the features listed below might be disallowed by
3515 @command{g77} unless some command-line option is specified.
3516 Currently, some of the features are accepted using the
3517 default invocation of @command{g77}, but that might change
3520 @emph{Note: This portion of the documentation definitely needs a lot
3524 * Source Form:: Details of fixed-form and free-form source.
3525 * Trailing Comment:: Use of @samp{/*} to start a comment.
3526 * Debug Line:: Use of @samp{D} in column 1.
3527 * Dollar Signs:: Use of @samp{$} in symbolic names.
3528 * Case Sensitivity:: Uppercase and lowercase in source files.
3529 * VXT Fortran:: @dots{}versus the GNU Fortran language.
3530 * Fortran 90:: @dots{}versus the GNU Fortran language.
3531 * Pedantic Compilation:: Enforcing the standard.
3532 * Distensions:: Misfeatures supported by GNU Fortran.
3536 @section Source Form
3537 @cindex source file format
3538 @cindex source format
3539 @cindex file, source
3541 @cindex code, source
3545 GNU Fortran accepts programs written in either fixed form or
3549 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
3550 allowing tabs) and Fortran 90's fixed form.
3552 Free form corresponds to
3553 Fortran 90's free form (though possibly not entirely up-to-date, and
3554 without complaining about some things that for which Fortran 90 requires
3555 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
3557 The way a Fortran compiler views source files depends entirely on the
3558 implementation choices made for the compiler, since those choices
3559 are explicitly left to the implementation by the published Fortran
3561 GNU Fortran currently tries to be somewhat like a few popular compilers
3562 (@command{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
3563 definition along with more
3564 flexibility offered by command-line options is likely to be offered
3567 This section describes how @command{g77} interprets source lines.
3570 * Carriage Returns:: Carriage returns ignored.
3571 * Tabs:: Tabs converted to spaces.
3572 * Short Lines:: Short lines padded with spaces (fixed-form only).
3573 * Long Lines:: Long lines truncated.
3574 * Ampersands:: Special Continuation Lines.
3577 @node Carriage Returns
3578 @subsection Carriage Returns
3579 @cindex carriage returns
3581 Carriage returns (@samp{\r}) in source lines are ignored.
3582 This is somewhat different from @command{f2c}, which seems to treat them as
3583 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
3584 inside such constants.
3588 @cindex tab character
3589 @cindex horizontal tab
3591 A source line with a @key{TAB} character anywhere in it is treated as
3592 entirely significant---however long it is---instead of ending in
3593 column 72 (for fixed-form source) or 132 (for free-form source).
3594 This also is different from @command{f2c}, which encodes tabs as
3595 @samp{\t} (the ASCII @key{TAB} character) inside character
3596 and Hollerith constants, but nevertheless seems to treat the column
3597 position as if it had been affected by the canonical tab positioning.
3599 @command{g77} effectively
3600 translates tabs to the appropriate number of spaces (a la the default
3601 for the UNIX @command{expand} command) before doing any other processing, other
3602 than (currently) noting whether a tab was found on a line and using this
3603 information to decide how to interpret the length of the line and continued
3606 Note that this default behavior probably will change for version 0.6,
3607 when it will presumably be available via a command-line option.
3608 The default as of version 0.6 is planned to be a ``pure visual''
3609 model, where tabs are immediately
3610 converted to spaces and otherwise have no effect, so the way a typical
3611 user sees source lines produces a consistent result no matter how the
3612 spacing in those source lines is actually implemented via tabs, spaces,
3613 and trailing tabs/spaces before newline.
3614 Command-line options are likely to be added to specify whether all or
3615 just-tabbed lines are to be extended to 132 or full input-line length,
3616 and perhaps even an option will be added to specify the truncated-line
3617 behavior to which some Digital compilers default (and which affects
3618 the way continued character/Hollerith constants are interpreted).
3621 @subsection Short Lines
3622 @cindex short source lines
3623 @cindex space, padding with
3624 @cindex source lines, short
3625 @cindex lines, short
3627 Source lines shorter than the applicable fixed-form length are treated as
3628 if they were padded with spaces to that length.
3629 (None of this is relevant to source files written in free form.)
3632 continued character and Hollerith constants, and is a different
3633 interpretation than provided by some other popular compilers
3634 (although a bit more consistent with the traditional punched-card
3635 basis of Fortran and the way the Fortran standard expressed fixed
3638 @command{g77} might someday offer an option to warn about cases where differences
3639 might be seen as a result of this treatment, and perhaps an option to
3640 specify the alternate behavior as well.
3642 Note that this padding cannot apply to lines that are effectively of
3643 infinite length---such lines are specified using command-line options
3644 like @option{-ffixed-line-length-none}, for example.
3647 @subsection Long Lines
3648 @cindex long source lines
3649 @cindex truncation, of long lines
3651 @cindex source lines, long
3653 Source lines longer than the applicable length are truncated to that
3655 Currently, @command{g77} does not warn if the truncated characters are
3656 not spaces, to accommodate existing code written for systems that
3657 treated truncated text as commentary (especially in columns 73 through 80).
3659 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
3660 for information on the @option{-ffixed-line-length-@var{n}} option,
3661 which can be used to set the line length applicable to fixed-form
3665 @subsection Ampersand Continuation Line
3666 @cindex ampersand continuation line
3667 @cindex continuation line, ampersand
3669 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
3670 continuation line, imitating the behavior of @command{f2c}.
3672 @node Trailing Comment
3673 @section Trailing Comment
3675 @cindex trailing comment
3677 @cindex characters, comment
3680 @cindex exclamation point
3681 @command{g77} supports use of @samp{/*} to start a trailing
3683 In the GNU Fortran language, @samp{!} is used for this purpose.
3685 @samp{/*} is not in the GNU Fortran language
3686 because the use of @samp{/*} in a program might
3687 suggest to some readers that a block, not trailing, comment is
3688 started (and thus ended by @samp{*/}, not end of line),
3689 since that is the meaning of @samp{/*} in C.
3691 Also, such readers might think they can use @samp{//} to start
3692 a trailing comment as an alternative to @samp{/*}, but
3693 @samp{//} already denotes concatenation, and such a ``comment''
3694 might actually result in a program that compiles without
3695 error (though it would likely behave incorrectly).
3700 @cindex comment line, debug
3702 Use of @samp{D} or @samp{d} as the first character (column 1) of
3703 a source line denotes a debug line.
3705 In turn, a debug line is treated as either a comment line
3706 or a normal line, depending on whether debug lines are enabled.
3708 When treated as a comment line, a line beginning with @samp{D} or
3709 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
3710 When treated as a normal line, such a line is treated as if
3711 the first character was @key{SPC} (space).
3713 (Currently, @command{g77} provides no means for treating debug
3714 lines as normal lines.)
3717 @section Dollar Signs in Symbol Names
3721 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
3722 when the @option{-fdollar-ok} option is specified.
3724 @node Case Sensitivity
3725 @section Case Sensitivity
3726 @cindex case sensitivity
3727 @cindex source file format
3728 @cindex code, source
3730 @cindex uppercase letters
3731 @cindex lowercase letters
3732 @cindex letters, uppercase
3733 @cindex letters, lowercase
3735 GNU Fortran offers the programmer way too much flexibility in deciding
3736 how source files are to be treated vis-a-vis uppercase and lowercase
3738 There are 66 useful settings that affect case sensitivity, plus 10
3739 settings that are nearly useless, with the remaining 116 settings
3740 being either redundant or useless.
3742 None of these settings have any effect on the contents of comments
3743 (the text after a @samp{c} or @samp{C} in Column 1, for example)
3744 or of character or Hollerith constants.
3745 Note that things like the @samp{E} in the statement
3746 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
3747 are considered built-in keywords, and so are affected by
3750 Low-level switches are identified in this section as follows:
3754 Source Case Conversion:
3758 Preserve (see Note 1)
3760 Convert to Upper Case
3762 Convert to Lower Case
3766 Built-in Keyword Matching:
3770 Match Any Case (per-character basis)
3772 Match Upper Case Only
3774 Match Lower Case Only
3776 Match InitialCaps Only (see tables for spellings)
3780 Built-in Intrinsic Matching:
3784 Match Any Case (per-character basis)
3786 Match Upper Case Only
3788 Match Lower Case Only
3790 Match InitialCaps Only (see tables for spellings)
3794 User-defined Symbol Possibilities (warnings only):
3798 Allow Any Case (per-character basis)
3800 Allow Upper Case Only
3802 Allow Lower Case Only
3804 Allow InitialCaps Only (see Note 2)
3808 Note 1: @command{g77} eventually will support @code{NAMELIST} in a manner that is
3809 consistent with these source switches---in the sense that input will be
3810 expected to meet the same requirements as source code in terms
3811 of matching symbol names and keywords (for the exponent letters).
3813 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
3814 which uppercases @code{NAMELIST} input and symbol names for matching.
3815 This means not only that @code{NAMELIST} output currently shows symbol
3816 (and keyword) names in uppercase even if lower-case source
3817 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
3818 adequately supported when source case preservation (option A0)
3821 If A0 is selected, a warning message will be
3822 output for each @code{NAMELIST} statement to this effect.
3824 of the program is undefined at run time if two or more symbol names
3825 appear in a given @code{NAMELIST} such that the names are identical
3826 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
3827 For complete and total elegance, perhaps there should be a warning
3828 when option A2 is selected, since the output of NAMELIST is currently
3829 in uppercase but will someday be lowercase (when a @code{libg77} is written),
3830 but that seems to be overkill for a product in beta test.
3832 Note 2: Rules for InitialCaps names are:
3836 Must be a single uppercase letter, @strong{or}
3838 Must start with an uppercase letter and contain at least one
3842 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
3843 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
3845 Note that most, but not all, built-in names meet these
3846 requirements---the exceptions are some of the two-letter format
3847 specifiers, such as @code{BN} and @code{BZ}.
3849 Here are the names of the corresponding command-line options:
3852 A0: -fsource-case-preserve
3853 A1: -fsource-case-upper
3854 A2: -fsource-case-lower
3856 B0: -fmatch-case-any
3857 B1: -fmatch-case-upper
3858 B2: -fmatch-case-lower
3859 B3: -fmatch-case-initcap
3861 C0: -fintrin-case-any
3862 C1: -fintrin-case-upper
3863 C2: -fintrin-case-lower
3864 C3: -fintrin-case-initcap
3866 D0: -fsymbol-case-any
3867 D1: -fsymbol-case-upper
3868 D2: -fsymbol-case-lower
3869 D3: -fsymbol-case-initcap
3872 Useful combinations of the above settings, along with abbreviated
3873 option names that set some of these combinations all at once:
3876 1: A0-- B0--- C0--- D0--- -fcase-preserve
3877 2: A0-- B0--- C0--- D-1--
3878 3: A0-- B0--- C0--- D--2-
3879 4: A0-- B0--- C0--- D---3
3880 5: A0-- B0--- C-1-- D0---
3881 6: A0-- B0--- C-1-- D-1--
3882 7: A0-- B0--- C-1-- D--2-
3883 8: A0-- B0--- C-1-- D---3
3884 9: A0-- B0--- C--2- D0---
3885 10: A0-- B0--- C--2- D-1--
3886 11: A0-- B0--- C--2- D--2-
3887 12: A0-- B0--- C--2- D---3
3888 13: A0-- B0--- C---3 D0---
3889 14: A0-- B0--- C---3 D-1--
3890 15: A0-- B0--- C---3 D--2-
3891 16: A0-- B0--- C---3 D---3
3892 17: A0-- B-1-- C0--- D0---
3893 18: A0-- B-1-- C0--- D-1--
3894 19: A0-- B-1-- C0--- D--2-
3895 20: A0-- B-1-- C0--- D---3
3896 21: A0-- B-1-- C-1-- D0---
3897 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
3898 23: A0-- B-1-- C-1-- D--2-
3899 24: A0-- B-1-- C-1-- D---3
3900 25: A0-- B-1-- C--2- D0---
3901 26: A0-- B-1-- C--2- D-1--
3902 27: A0-- B-1-- C--2- D--2-
3903 28: A0-- B-1-- C--2- D---3
3904 29: A0-- B-1-- C---3 D0---
3905 30: A0-- B-1-- C---3 D-1--
3906 31: A0-- B-1-- C---3 D--2-
3907 32: A0-- B-1-- C---3 D---3
3908 33: A0-- B--2- C0--- D0---
3909 34: A0-- B--2- C0--- D-1--
3910 35: A0-- B--2- C0--- D--2-
3911 36: A0-- B--2- C0--- D---3
3912 37: A0-- B--2- C-1-- D0---
3913 38: A0-- B--2- C-1-- D-1--
3914 39: A0-- B--2- C-1-- D--2-
3915 40: A0-- B--2- C-1-- D---3
3916 41: A0-- B--2- C--2- D0---
3917 42: A0-- B--2- C--2- D-1--
3918 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
3919 44: A0-- B--2- C--2- D---3
3920 45: A0-- B--2- C---3 D0---
3921 46: A0-- B--2- C---3 D-1--
3922 47: A0-- B--2- C---3 D--2-
3923 48: A0-- B--2- C---3 D---3
3924 49: A0-- B---3 C0--- D0---
3925 50: A0-- B---3 C0--- D-1--
3926 51: A0-- B---3 C0--- D--2-
3927 52: A0-- B---3 C0--- D---3
3928 53: A0-- B---3 C-1-- D0---
3929 54: A0-- B---3 C-1-- D-1--
3930 55: A0-- B---3 C-1-- D--2-
3931 56: A0-- B---3 C-1-- D---3
3932 57: A0-- B---3 C--2- D0---
3933 58: A0-- B---3 C--2- D-1--
3934 59: A0-- B---3 C--2- D--2-
3935 60: A0-- B---3 C--2- D---3
3936 61: A0-- B---3 C---3 D0---
3937 62: A0-- B---3 C---3 D-1--
3938 63: A0-- B---3 C---3 D--2-
3939 64: A0-- B---3 C---3 D---3 -fcase-initcap
3940 65: A-1- B01-- C01-- D01-- -fcase-upper
3941 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
3944 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
3945 (except comments, character constants, and Hollerith strings) must
3946 be entered in uppercase.
3947 Use @option{-fcase-strict-upper} to specify this
3950 Number 43 is like Number 22 except all input must be lowercase. Use
3951 @option{-fcase-strict-lower} to specify this combination.
3953 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
3954 non-UNIX machines whereby all the source is translated to uppercase.
3955 Use @option{-fcase-upper} to specify this combination.
3957 Number 66 is the ``canonical'' UNIX model whereby all the source is
3958 translated to lowercase.
3959 Use @option{-fcase-lower} to specify this combination.
3961 There are a few nearly useless combinations:
3964 67: A-1- B01-- C01-- D--2-
3965 68: A-1- B01-- C01-- D---3
3966 69: A-1- B01-- C--23 D01--
3967 70: A-1- B01-- C--23 D--2-
3968 71: A-1- B01-- C--23 D---3
3969 72: A--2 B01-- C0-2- D-1--
3970 73: A--2 B01-- C0-2- D---3
3971 74: A--2 B01-- C-1-3 D0-2-
3972 75: A--2 B01-- C-1-3 D-1--
3973 76: A--2 B01-- C-1-3 D---3
3976 The above allow some programs to be compiled but with restrictions that
3977 make most useful programs impossible: Numbers 67 and 72 warn about
3978 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
3980 68 and 73 warn about any user-defined symbol names longer than one
3981 character that don't have at least one non-alphabetic character after
3983 Numbers 69 and 74 disallow any references to intrinsics;
3984 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
3985 67+69, 68+69, 72+74, and 73+74, respectively.
3987 All redundant combinations are shown in the above tables anyplace
3988 where more than one setting is shown for a low-level switch.
3989 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
3990 The ``proper'' setting in such a case is the one that copies the setting
3991 of switch A---any other setting might slightly reduce the speed of
3992 the compiler, though possibly to an unmeasurable extent.
3994 All remaining combinations are useless in that they prevent successful
3995 compilation of non-null source files (source files with something other
3999 @section VXT Fortran
4001 @cindex VXT extensions
4002 @cindex extensions, VXT
4003 @command{g77} supports certain constructs that
4004 have different meanings in VXT Fortran than they
4005 do in the GNU Fortran language.
4007 Generally, this manual uses the invented term VXT Fortran to refer
4008 VAX FORTRAN (circa v4).
4009 That compiler offered many popular features, though not necessarily
4010 those that are specific to the VAX processor architecture,
4011 the VMS operating system,
4012 or Digital Equipment Corporation's Fortran product line.
4013 (VAX and VMS probably are trademarks of Digital Equipment
4016 An extension offered by a Digital Fortran product that also is
4017 offered by several other Fortran products for different kinds of
4018 systems is probably going to be considered for inclusion in @command{g77}
4019 someday, and is considered a VXT Fortran feature.
4021 The @option{-fvxt} option generally specifies that, where
4022 the meaning of a construct is ambiguous (means one thing
4023 in GNU Fortran and another in VXT Fortran), the VXT Fortran
4024 meaning is to be assumed.
4027 * Double Quote Meaning:: @samp{"2000} as octal constant.
4028 * Exclamation Point:: @samp{!} in column 6.
4031 @node Double Quote Meaning
4032 @subsection Meaning of Double Quote
4033 @cindex double quotes
4034 @cindex character constants
4035 @cindex constants, character
4036 @cindex octal constants
4037 @cindex constants, octal
4039 @command{g77} treats double-quote (@samp{"})
4040 as beginning an octal constant of @code{INTEGER(KIND=1)} type
4041 when the @option{-fvxt} option is specified.
4042 The form of this octal constant is
4049 where @var{octal-digits} is a nonempty string of characters in
4050 the set @samp{01234567}.
4052 For example, the @option{-fvxt} option permits this:
4060 The above program would print the value @samp{16}.
4062 @xref{Integer Type}, for information on the preferred construct
4063 for integer constants specified using GNU Fortran's octal notation.
4065 (In the GNU Fortran language, the double-quote character (@samp{"})
4066 delimits a character constant just as does apostrophe (@samp{'}).
4067 There is no way to allow
4068 both constructs in the general case, since statements like
4069 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
4071 @node Exclamation Point
4072 @subsection Meaning of Exclamation Point in Column 6
4074 @cindex exclamation point
4075 @cindex continuation character
4076 @cindex characters, continuation
4077 @cindex comment character
4078 @cindex characters, comment
4080 @command{g77} treats an exclamation point (@samp{!}) in column 6 of
4081 a fixed-form source file
4082 as a continuation character rather than
4083 as the beginning of a comment
4084 (as it does in any other column)
4085 when the @option{-fvxt} option is specified.
4087 The following program, when run, prints a message indicating
4088 whether it is interpreted according to GNU Fortran (and Fortran 90)
4089 rules or VXT Fortran rules:
4092 C234567 (This line begins in column 1.)
4095 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
4096 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
4097 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
4101 (In the GNU Fortran and Fortran 90 languages, exclamation point is
4102 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
4103 marks a line as a continuation line when it appears in column 6.)
4107 @cindex compatibility, Fortran 90
4108 @cindex Fortran 90, compatibility
4110 The GNU Fortran language includes a number of features that are
4111 part of Fortran 90, even when the @option{-ff90} option is not specified.
4112 The features enabled by @option{-ff90} are intended to be those that,
4113 when @option{-ff90} is not specified, would have another
4114 meaning to @command{g77}---usually meaning something invalid in the
4115 GNU Fortran language.
4117 So, the purpose of @option{-ff90} is not to specify whether @command{g77} is
4118 to gratuitously reject Fortran 90 constructs.
4119 The @option{-pedantic} option specified with @option{-fno-f90} is intended
4120 to do that, although its implementation is certainly incomplete at
4123 When @option{-ff90} is specified:
4127 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
4128 where @var{expr} is @code{COMPLEX} type,
4129 is the same type as the real part of @var{expr}.
4131 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
4132 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
4133 not of type @code{REAL(KIND=1)}, since @option{-ff90} is specified.
4136 @node Pedantic Compilation
4137 @section Pedantic Compilation
4138 @cindex pedantic compilation
4139 @cindex compilation, pedantic
4141 The @option{-fpedantic} command-line option specifies that @command{g77}
4142 is to warn about code that is not standard-conforming.
4143 This is useful for finding
4144 some extensions @command{g77} accepts that other compilers might not accept.
4145 (Note that the @option{-pedantic} and @option{-pedantic-errors} options
4146 always imply @option{-fpedantic}.)
4148 With @option{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
4149 for conforming code.
4150 With @option{-ff90} in force, Fortran 90 is used.
4152 The constructs for which @command{g77} issues diagnostics when @option{-fpedantic}
4153 and @option{-fno-f90} are in force are:
4157 Automatic arrays, as in
4166 where @samp{A} is not listed in any @code{ENTRY} statement,
4167 and thus is not a dummy argument.
4170 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
4172 These commas are disallowed by FORTRAN 77, but, while strictly
4173 superfluous, are syntactically elegant,
4174 especially given that commas are required in statements such
4175 as @samp{READ 99, I} and @samp{PRINT *, J}.
4176 Many compilers permit the superfluous commas for this reason.
4179 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
4181 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
4182 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
4184 An example of an implicit use is the expression @samp{C*D},
4185 where @samp{C} is @code{COMPLEX(KIND=1)}
4186 and @samp{D} is @code{DOUBLE PRECISION}.
4187 This expression is prohibited by ANSI FORTRAN 77
4188 because the rules of promotion would suggest that it
4189 produce a @code{DOUBLE COMPLEX} result---a type not
4190 provided for by that standard.
4193 Automatic conversion of numeric
4194 expressions to @code{INTEGER(KIND=1)} in contexts such as:
4198 Array-reference indexes.
4200 Alternate-return values.
4202 Computed @code{GOTO}.
4204 @code{FORMAT} run-time expressions (not yet supported).
4206 Dimension lists in specification statements.
4208 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
4210 Sizes of @code{CHARACTER} entities in specification statements.
4212 Kind types in specification entities (a Fortran 90 feature).
4214 Initial, terminal, and incrementation parameters for implied-@code{DO}
4215 constructs in @code{DATA} statements.
4219 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
4220 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
4221 expressions are disallowed anyway).
4224 Zero-size array dimensions, as in:
4227 INTEGER I(10,20,4:2)
4231 Zero-length @code{CHARACTER} entities, as in:
4238 Substring operators applied to character constants and named
4242 PRINT *, 'hello'(3:5)
4246 Null arguments passed to statement function, as in:
4253 Disagreement among program units regarding whether a given @code{COMMON}
4254 area is @code{SAVE}d (for targets where program units in a single source
4255 file are ``glued'' together as they typically are for UNIX development
4259 Disagreement among program units regarding the size of a
4260 named @code{COMMON} block.
4263 Specification statements following first @code{DATA} statement.
4265 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
4266 but not @samp{INTEGER I}.
4267 The @option{-fpedantic} option disallows both of these.)
4270 Semicolon as statement separator, as in:
4277 @c Comma before list of I/O items in @code{WRITE}
4278 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
4279 @c statements, as with @code{READ} (as explained above).
4282 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
4285 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
4289 Expressions having two arithmetic operators in a row, such
4293 If @option{-fpedantic} is specified along with @option{-ff90}, the
4294 following constructs result in diagnostics:
4298 Use of semicolon as a statement separator on a line
4299 that has an @code{INCLUDE} directive.
4303 @section Distensions
4305 @cindex ugly features
4306 @cindex features, ugly
4308 The @option{-fugly-*} command-line options determine whether certain
4309 features supported by VAX FORTRAN and other such compilers, but considered
4310 too ugly to be in code that can be changed to use safer and/or more
4311 portable constructs, are accepted.
4312 These are humorously referred to as ``distensions'',
4313 extensions that just plain look ugly in the harsh light of day.
4316 * Ugly Implicit Argument Conversion:: Disabled via @option{-fno-ugly-args}.
4317 * Ugly Assumed-Size Arrays:: Enabled via @option{-fugly-assumed}.
4318 * Ugly Null Arguments:: Enabled via @option{-fugly-comma}.
4319 * Ugly Complex Part Extraction:: Enabled via @option{-fugly-complex}.
4320 * Ugly Conversion of Initializers:: Disabled via @option{-fno-ugly-init}.
4321 * Ugly Integer Conversions:: Enabled via @option{-fugly-logint}.
4322 * Ugly Assigned Labels:: Enabled via @option{-fugly-assign}.
4325 @node Ugly Implicit Argument Conversion
4326 @subsection Implicit Argument Conversion
4327 @cindex Hollerith constants
4328 @cindex constants, Hollerith
4330 The @option{-fno-ugly-args} option disables
4331 passing typeless and Hollerith constants as actual arguments
4332 in procedure invocations.
4341 These constructs can be too easily used to create non-portable
4342 code, but are not considered as ``ugly'' as others.
4343 Further, they are widely used in existing Fortran source code
4344 in ways that often are quite portable.
4345 Therefore, they are enabled by default.
4347 @node Ugly Assumed-Size Arrays
4348 @subsection Ugly Assumed-Size Arrays
4349 @cindex arrays, assumed-size
4350 @cindex assumed-size arrays
4351 @cindex DIMENSION X(1)
4353 The @option{-fugly-assumed} option enables
4354 the treatment of any array with a final dimension specified as @samp{1}
4355 as an assumed-size array, as if @samp{*} had been specified
4358 For example, @samp{DIMENSION X(1)} is treated as if it
4359 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
4360 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
4361 or @code{ENTRY} statement in the same program unit.
4363 Use an explicit lower bound to avoid this interpretation.
4364 For example, @samp{DIMENSION X(1:1)} is never treated as if
4365 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
4366 Nor is @samp{DIMENSION X(2-1)} affected by this option,
4367 since that kind of expression is unlikely to have been
4368 intended to designate an assumed-size array.
4370 This option is used to prevent warnings being issued about apparent
4371 out-of-bounds reference such as @samp{X(2) = 99}.
4373 It also prevents the array from being used in contexts that
4374 disallow assumed-size arrays, such as @samp{PRINT *,X}.
4375 In such cases, a diagnostic is generated and the source file is
4378 The construct affected by this option is used only in old code
4379 that pre-exists the widespread acceptance of adjustable and assumed-size
4380 arrays in the Fortran community.
4382 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
4383 treated if @samp{X} is listed as a dummy argument only
4384 @emph{after} the @code{DIMENSION} statement (presumably in
4385 an @code{ENTRY} statement).
4386 For example, @option{-fugly-assumed} has no effect on the
4387 following program unit:
4398 @node Ugly Complex Part Extraction
4399 @subsection Ugly Complex Part Extraction
4400 @cindex complex values
4402 @cindex imaginary part
4404 The @option{-fugly-complex} option enables
4405 use of the @code{REAL()} and @code{AIMAG()}
4406 intrinsics with arguments that are
4407 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
4409 With @option{-ff90} in effect, these intrinsics return
4410 the unconverted real and imaginary parts (respectively)
4413 With @option{-fno-f90} in effect, these intrinsics convert
4414 the real and imaginary parts to @code{REAL(KIND=1)}, and return
4415 the result of that conversion.
4417 Due to this ambiguity, the GNU Fortran language defines
4418 these constructs as invalid, except in the specific
4419 case where they are entirely and solely passed as an
4420 argument to an invocation of the @code{REAL()} intrinsic.
4428 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
4429 and @option{-fno-ugly-complex} is in effect, because the
4432 @command{g77} enforces this restriction, unless @option{-fugly-complex}
4433 is specified, in which case the appropriate interpretation is
4434 chosen and no diagnostic is issued.
4436 @xref{CMPAMBIG}, for information on how to cope with existing
4437 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
4438 with @code{COMPLEX(KIND=2)} arguments.
4440 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
4441 intrinsic, used to extract the real part of a complex expression
4443 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
4444 intrinsic, used to extract the imaginary part of a complex expression
4447 @node Ugly Null Arguments
4448 @subsection Ugly Null Arguments
4449 @cindex trailing comma
4450 @cindex comma, trailing
4451 @cindex characters, comma
4452 @cindex null arguments
4453 @cindex arguments, null
4455 The @option{-fugly-comma} option enables use of a single trailing comma
4456 to mean ``pass an extra trailing null argument''
4457 in a list of actual arguments to an external procedure,
4458 and use of an empty list of arguments to such a procedure
4459 to mean ``pass a single null argument''.
4461 @cindex omitting arguments
4462 @cindex arguments, omitting
4463 (Null arguments often are used in some procedure-calling
4464 schemes to indicate omitted arguments.)
4466 For example, @samp{CALL FOO(,)} means ``pass
4467 two null arguments'', rather than ``pass one null argument''.
4468 Also, @samp{CALL BAR()} means ``pass one null argument''.
4470 This construct is considered ``ugly'' because it does not
4471 provide an elegant way to pass a single null argument
4472 that is syntactically distinct from passing no arguments.
4473 That is, this construct changes the meaning of code that
4474 makes no use of the construct.
4476 So, with @option{-fugly-comma} in force, @samp{CALL FOO()}
4477 and @samp{I = JFUNC()} pass a single null argument, instead
4478 of passing no arguments as required by the Fortran 77 and
4481 @emph{Note:} Many systems gracefully allow the case
4482 where a procedure call passes one extra argument that the
4483 called procedure does not expect.
4485 So, in practice, there might be no difference in
4486 the behavior of a program that does @samp{CALL FOO()}
4487 or @samp{I = JFUNC()} and is compiled with @option{-fugly-comma}
4488 in force as compared to its behavior when compiled
4489 with the default, @option{-fno-ugly-comma}, in force,
4490 assuming @samp{FOO} and @samp{JFUNC} do not expect any
4491 arguments to be passed.
4493 @node Ugly Conversion of Initializers
4494 @subsection Ugly Conversion of Initializers
4496 The constructs disabled by @option{-fno-ugly-init} are:
4499 @cindex Hollerith constants
4500 @cindex constants, Hollerith
4502 Use of Hollerith and typeless constants in contexts where they set
4503 initial (compile-time) values for variables, arrays, and named
4504 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
4505 type-declaration statements specifying initial values.
4507 Here are some sample initializations that are disabled by the
4508 @option{-fno-ugly-init} option:
4511 PARAMETER (VAL='9A304FFE'X)
4512 REAL*8 STRING/8HOUTPUT00/
4516 @cindex character constants
4517 @cindex constants, character
4519 In the same contexts as above, use of character constants to initialize
4520 numeric items and vice versa (one constant per item).
4522 Here are more sample initializations that are disabled by the
4523 @option{-fno-ugly-init} option:
4528 PARAMETER (IA = 'A')
4529 PARAMETER (BELL = 7)
4533 Use of Hollerith and typeless constants on the right-hand side
4534 of assignment statements to numeric types, and in other
4535 contexts (such as passing arguments in invocations of
4536 intrinsic procedures and statement functions) that
4537 are treated as assignments to known types (the dummy
4538 arguments, in these cases).
4540 Here are sample statements that are disabled by the
4541 @option{-fno-ugly-init} option:
4545 PRINT *, IMAX0(2HAB, 2HBA)
4549 The above constructs, when used,
4550 can tend to result in non-portable code.
4551 But, they are widely used in existing Fortran code in ways
4552 that often are quite portable.
4553 Therefore, they are enabled by default.
4555 @node Ugly Integer Conversions
4556 @subsection Ugly Integer Conversions
4558 The constructs enabled via @option{-fugly-logint} are:
4562 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
4564 context (typically implies nonportable dependencies on how a
4565 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
4568 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
4572 The above constructs are disabled by default because use
4573 of them tends to lead to non-portable code.
4574 Even existing Fortran code that uses that often turns out
4575 to be non-portable, if not outright buggy.
4577 Some of this is due to differences among implementations as
4578 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
4579 @code{INTEGER} values---Fortran code that assumes a particular
4580 coding is likely to use one of the above constructs, and is
4581 also likely to not work correctly on implementations using
4582 different encodings.
4584 @xref{Equivalence Versus Equality}, for more information.
4586 @node Ugly Assigned Labels
4587 @subsection Ugly Assigned Labels
4588 @cindex ASSIGN statement
4589 @cindex statements, ASSIGN
4590 @cindex assigned labels
4593 The @option{-fugly-assign} option forces @command{g77} to use the
4594 same storage for assigned labels as it would for a normal
4595 assignment to the same variable.
4597 For example, consider the following code fragment:
4605 Normally, for portability and improved diagnostics, @command{g77}
4606 reserves distinct storage for a ``sibling'' of @samp{I}, used
4607 only for @code{ASSIGN} statements to that variable (along with
4608 the corresponding assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O
4609 statements that reference the variable).
4611 However, some code (that violates the ANSI FORTRAN 77 standard)
4612 attempts to copy assigned labels among variables involved with
4613 @code{ASSIGN} statements, as in:
4624 Such code doesn't work under @command{g77} unless @option{-fugly-assign}
4625 is specified on the command-line, ensuring that the value of @code{I}
4626 referenced in the second line is whatever value @command{g77} uses
4627 to designate statement label @samp{10}, so the value may be
4628 copied into the @samp{ISTATE} array, later retrieved into a
4629 variable of the appropriate type (@samp{J}), and used as the target of
4630 an assigned-@code{GOTO} statement.
4632 @emph{Note:} To avoid subtle program bugs,
4633 when @option{-fugly-assign} is specified,
4634 @command{g77} requires the type of variables
4635 specified in assigned-label contexts
4636 @emph{must} be the same type returned by @code{%LOC()}.
4637 On many systems, this type is effectively the same
4638 as @code{INTEGER(KIND=1)}, while, on others, it is
4639 effectively the same as @code{INTEGER(KIND=2)}.
4641 Do @emph{not} depend on @command{g77} actually writing valid pointers
4642 to these variables, however.
4643 While @command{g77} currently chooses that implementation, it might
4644 be changed in the future.
4646 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
4647 for implementation details on assigned-statement labels.
4650 @chapter The GNU Fortran Compiler
4652 The GNU Fortran compiler, @command{g77}, supports programs written
4653 in the GNU Fortran language and in some other dialects of Fortran.
4655 Some aspects of how @command{g77} works are universal regardless
4656 of dialect, and yet are not properly part of the GNU Fortran
4658 These are described below.
4660 @emph{Note: This portion of the documentation definitely needs a lot
4665 * Run-time Environment Limits::
4667 * Compiler Constants::
4668 * Compiler Intrinsics::
4671 @node Compiler Limits
4672 @section Compiler Limits
4673 @cindex limits, compiler
4674 @cindex compiler limits
4676 @command{g77}, as with GNU tools in general, imposes few arbitrary restrictions
4677 on lengths of identifiers, number of continuation lines, number of external
4678 symbols in a program, and so on.
4680 @cindex options, -Nl
4682 @cindex options, -Nx
4684 @cindex limits, continuation lines
4685 @cindex limits, lengths of names
4686 For example, some other Fortran compiler have an option
4687 (such as @option{-Nl@var{x}}) to increase the limit on the
4688 number of continuation lines.
4689 Also, some Fortran compilation systems have an option
4690 (such as @option{-Nx@var{x}}) to increase the limit on the
4691 number of external symbols.
4693 @command{g77}, @command{gcc}, and GNU @command{ld} (the GNU linker) have
4694 no equivalent options, since they do not impose arbitrary
4695 limits in these areas.
4697 @cindex rank, maximum
4698 @cindex maximum rank
4699 @cindex number of dimensions, maximum
4700 @cindex maximum number of dimensions
4701 @cindex limits, rank
4702 @cindex limits, array dimensions
4703 @command{g77} does currently limit the number of dimensions in an array
4704 to the same degree as do the Fortran standards---seven (7).
4705 This restriction might be lifted in a future version.
4707 @node Run-time Environment Limits
4708 @section Run-time Environment Limits
4709 @cindex limits, run-time library
4712 As a portable Fortran implementation,
4713 @command{g77} offers its users direct access to,
4714 and otherwise depends upon,
4715 the underlying facilities of the system
4716 used to build @command{g77},
4717 the system on which @command{g77} itself is used to compile programs,
4718 and the system on which the @command{g77}-compiled program is actually run.
4719 (For most users, the three systems are of the same
4720 type---combination of operating environment and hardware---often
4721 the same physical system.)
4723 The run-time environment for a particular system
4724 inevitably imposes some limits on a program's use
4725 of various system facilities.
4726 These limits vary from system to system.
4728 Even when such limits might be well beyond the
4729 possibility of being encountered on a particular system,
4730 the @command{g77} run-time environment
4731 has certain built-in limits,
4732 usually, but not always, stemming from intrinsics
4733 with inherently limited interfaces.
4735 Currently, the @command{g77} run-time environment
4736 does not generally offer a less-limiting environment
4737 by augmenting the underlying system's own environment.
4739 Therefore, code written in the GNU Fortran language,
4740 while syntactically and semantically portable,
4741 might nevertheless make non-portable assumptions
4742 about the run-time environment---assumptions that
4743 prove to be false for some particular environments.
4745 The GNU Fortran language,
4746 the @command{g77} compiler and run-time environment,
4747 and the @command{g77} documentation
4748 do not yet offer comprehensive portable work-arounds for such limits,
4749 though programmers should be able to
4750 find their own in specific instances.
4752 Not all of the limitations are described in this document.
4753 Some of the known limitations include:
4756 * Timer Wraparounds::
4757 * Year 2000 (Y2K) Problems::
4759 * Character-variable Length::
4760 * Year 10000 (Y10K) Problems::
4763 @node Timer Wraparounds
4764 @subsection Timer Wraparounds
4766 Intrinsics that return values computed from system timers,
4767 whether elapsed (wall-clock) timers,
4769 or other kinds of timers,
4770 are prone to experiencing wrap-around errors
4771 (or returning wrapped-around values from successive calls)
4772 due to insufficient ranges
4773 offered by the underlying system's timers.
4775 @cindex negative time
4778 Some of the symptoms of such behaviors include
4779 apparently negative time being computed for a duration,
4780 an extremely short amount of time being computed for a long duration,
4781 and an extremely long amount of time being computed for a short duration.
4783 See the following for intrinsics
4784 known to have potential problems in these areas
4785 on at least some systems:
4786 @ref{CPU_Time Intrinsic},
4787 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
4788 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
4789 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
4790 @ref{Secnds Intrinsic},
4791 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
4792 @ref{System_Clock Intrinsic},
4793 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
4794 @ref{Time8 Intrinsic}.
4796 @node Year 2000 (Y2K) Problems
4797 @subsection Year 2000 (Y2K) Problems
4798 @cindex Y2K compliance
4799 @cindex Year 2000 compliance
4801 While the @command{g77} compiler itself is believed to
4802 be Year-2000 (Y2K) compliant,
4803 some intrinsics are not,
4804 and, potentially, some underlying systems are not,
4805 perhaps rendering some Y2K-compliant intrinsics
4806 non-compliant when used on those particular systems.
4808 Fortran code that uses non-Y2K-compliant intrinsics
4810 is, itself, almost certainly not compliant,
4811 and should be modified to use Y2K-compliant intrinsics instead.
4813 Fortran code that uses no non-Y2K-compliant intrinsics,
4814 but which currently is running on a non-Y2K-compliant system,
4815 can be made more Y2K compliant by compiling and
4816 linking it for use on a new Y2K-compliant system,
4817 such as a new version of an old, non-Y2K-compliant, system.
4819 Currently, information on Y2K and related issues
4820 is being maintained at
4821 @uref{http://www.gnu.org/software/year2000-list.html}.
4823 See the following for intrinsics
4824 known to have potential problems in these areas
4825 on at least some systems:
4826 @ref{Date Intrinsic},
4827 @ref{IDate Intrinsic (VXT)}.
4830 @cindex date_y2kbuggy_0
4831 @cindex vxtidate_y2kbuggy_0
4832 @cindex G77_date_y2kbuggy_0
4833 @cindex G77_vxtidate_y2kbuggy_0
4834 The @code{libg2c} library
4835 shipped with any @command{g77} that warns
4836 about invocation of a non-Y2K-compliant intrinsic
4837 has renamed the @code{EXTERNAL} procedure names
4838 of those intrinsics.
4839 This is done so that
4840 the @code{libg2c} implementations of these intrinsics
4841 cannot be directly linked to
4842 as @code{EXTERNAL} names
4843 (which normally would avoid the non-Y2K-intrinsic warning).
4845 The renamed forms of the @code{EXTERNAL} names
4846 of these renamed procedures
4848 by appending the string @samp{_y2kbug}
4849 to the name of the procedure
4856 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
4857 CALL DATE_Y2KBUG (STR)
4858 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
4861 (Note that the @code{EXTERNAL} statement
4862 is not actually required,
4863 since the modified names are not recognized as intrinsics
4864 by the current version of @command{g77}.
4865 But it is shown in this specific case,
4866 for purposes of illustration.)
4868 The renaming of @code{EXTERNAL} procedure names of these intrinsics
4869 causes unresolved references at link time.
4870 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
4871 is normally compiled by @command{g77}
4872 as, in C, @samp{date_(&str, 20);}.
4873 This, in turn, links to the @code{date_} procedure
4874 in the @code{libE77} portion of @code{libg2c},
4875 which purposely calls a nonexistent procedure
4876 named @code{G77_date_y2kbuggy_0}.
4877 The resulting link-time error is designed, via this name,
4878 to encourage the programmer to look up the
4879 index entries to this portion of the @command{g77} documentation.
4881 Generally, we recommend that the @code{EXTERNAL} method
4882 of invoking procedures in @code{libg2c}
4884 When used, some of the correctness checking
4885 normally performed by @command{g77}
4888 In particular, it is probably better to use the
4889 @code{INTRINSIC} method of invoking
4890 non-Y2K-compliant procedures,
4891 so anyone compiling the code
4892 can quickly notice the potential Y2K problems
4893 (via the warnings printing by @command{g77})
4894 without having to even look at the code itself.
4896 If there are problems linking @code{libg2c}
4897 to code compiled by @command{g77}
4898 that involve the string @samp{y2kbug},
4899 and these are not explained above,
4900 that probably indicates
4901 that a version of @code{libg2c}
4902 older than @command{g77}
4904 or that the new library is being linked
4905 to code compiled by an older version of @command{g77}.
4907 That's because, as of the version that warns about
4908 non-Y2K-compliant intrinsic invocation,
4909 @command{g77} references the @code{libg2c} implementations
4911 using new names, containing the string @samp{y2kbug}.
4913 So, linking newly-compiled code
4914 (invoking one of the intrinsics in question)
4916 might yield an unresolved reference
4917 to @code{G77_date_y2kbug_0}.
4918 (The old library calls it @code{G77_date_0}.)
4920 Similarly, linking previously-compiled code
4922 might yield an unresolved reference
4923 to @code{G77_vxtidate_0}.
4924 (The new library calls it @code{G77_vxtidate_y2kbug_0}.)
4926 The proper fix for the above problems
4927 is to obtain the latest release of @command{g77}
4928 and related products
4929 (including @code{libg2c})
4930 and install them on all systems,
4931 then recompile, relink, and install
4933 all existing Fortran programs.
4935 (Normally, this sort of renaming is steadfastly avoided.
4936 In this case, however, it seems more important to highlight
4937 potential Y2K problems
4938 than to ease the transition
4939 of potentially non-Y2K-compliant code
4940 to new versions of @command{g77} and @code{libg2c}.)
4943 @subsection Array Size
4944 @cindex limits, array size
4947 Currently, @command{g77} uses the default @code{INTEGER} type
4949 which limits the sizes of single-dimension arrays
4950 on systems offering a larger address space
4951 than can be addressed by that type.
4952 (That @command{g77} puts all arrays in memory
4953 could be considered another limitation---it
4954 could use large temporary files---but that decision
4955 is left to the programmer as an implementation choice
4956 by most Fortran implementations.)
4958 @c ??? Investigate this, to offer a more clear statement
4959 @c than the following paragraphs do. -- burley 1999-02-17
4960 It is not yet clear whether this limitation
4961 never, sometimes, or always applies to the
4962 sizes of multiple-dimension arrays as a whole.
4964 For example, on a system with 64-bit addresses
4965 and 32-bit default @code{INTEGER},
4966 an array with a size greater than can be addressed
4968 can be declared using multiple dimensions.
4969 Such an array is therefore larger
4970 than a single-dimension array can be,
4973 @cindex limits, multi-dimension arrays
4974 @cindex multi-dimension arrays
4975 @cindex arrays, dimensioning
4976 Whether large multiple-dimension arrays are reliably supported
4977 depends mostly on the @command{gcc} back end (code generator)
4978 used by @command{g77}, and has not yet been fully investigated.
4980 @node Character-variable Length
4981 @subsection Character-variable Length
4982 @cindex limits, on character-variable length
4983 @cindex character-variable length
4985 Currently, @command{g77} uses the default @code{INTEGER} type
4986 for the lengths of @code{CHARACTER} variables
4989 This means that, for example,
4990 a system with a 64-bit address space
4991 and a 32-bit default @code{INTEGER} type
4992 does not, under @command{g77},
4993 support a @code{CHARACTER*@var{n}} declaration
4994 where @var{n} is greater than 2147483647.
4996 @node Year 10000 (Y10K) Problems
4997 @subsection Year 10000 (Y10K) Problems
4998 @cindex Y10K compliance
4999 @cindex Year 10000 compliance
5001 Most intrinsics returning, or computing values based on,
5002 date information are prone to Year-10000 (Y10K) problems,
5003 due to supporting only 4 digits for the year.
5005 See the following for examples:
5006 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
5007 @ref{IDate Intrinsic (UNIX)},
5008 @ref{Time Intrinsic (VXT)},
5009 @ref{Date_and_Time Intrinsic}.
5011 @node Compiler Types
5012 @section Compiler Types
5013 @cindex types, of data
5016 Fortran implementations have a fair amount of freedom given them by the
5017 standard as far as how much storage space is used and how much precision
5018 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
5019 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
5020 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
5021 Further, many compilers offer so-called @samp{*@var{n}} notation, but
5022 the interpretation of @var{n} varies across compilers and target architectures.
5024 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
5025 and @code{REAL(KIND=1)}
5026 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
5027 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
5028 Further, it requires that @code{COMPLEX(KIND=1)}
5029 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
5030 storage-associated (such as via @code{EQUIVALENCE})
5031 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
5032 corresponds to the real element and @samp{R(2)} to the imaginary
5033 element of the @code{COMPLEX(KIND=1)} variable.
5035 (Few requirements as to precision or ranges of any of these are
5036 placed on the implementation, nor is the relationship of storage sizes of
5037 these types to the @code{CHARACTER} type specified, by the standard.)
5039 @command{g77} follows the above requirements, warning when compiling
5040 a program requires placement of items in memory that contradict the
5041 requirements of the target architecture.
5042 (For example, a program can require placement of a @code{REAL(KIND=2)}
5043 on a boundary that is not an even multiple of its size, but still an
5044 even multiple of the size of a @code{REAL(KIND=1)} variable.
5045 On some target architectures, using the canonical
5046 mapping of Fortran types to underlying architectural types, such
5047 placement is prohibited by the machine definition or
5048 the Application Binary Interface (ABI) in force for
5049 the configuration defined for building @command{gcc} and @command{g77}.
5050 @command{g77} warns about such
5051 situations when it encounters them.)
5053 @command{g77} follows consistent rules for configuring the mapping between Fortran
5054 types, including the @samp{*@var{n}} notation, and the underlying architectural
5055 types as accessed by a similarly-configured applicable version of the
5056 @command{gcc} compiler.
5057 These rules offer a widely portable, consistent Fortran/C
5058 environment, although they might well conflict with the expectations of
5059 users of Fortran compilers designed and written for particular
5062 These rules are based on the configuration that is in force for the
5063 version of @command{gcc} built in the same release as @command{g77} (and
5064 which was therefore used to build both the @command{g77} compiler
5065 components and the @code{libg2c} run-time library):
5068 @cindex REAL(KIND=1) type
5069 @cindex types, REAL(KIND=1)
5071 Same as @code{float} type.
5073 @cindex REAL(KIND=2) type
5074 @cindex types, REAL(KIND=2)
5076 Same as whatever floating-point type that is twice the size
5077 of a @code{float}---usually, this is a @code{double}.
5079 @cindex INTEGER(KIND=1) type
5080 @cindex types, INTEGER(KIND=1)
5081 @item INTEGER(KIND=1)
5082 Same as an integral type that is occupies the same amount
5083 of memory storage as @code{float}---usually, this is either
5084 an @code{int} or a @code{long int}.
5086 @cindex LOGICAL(KIND=1) type
5087 @cindex types, LOGICAL(KIND=1)
5088 @item LOGICAL(KIND=1)
5089 Same @command{gcc} type as @code{INTEGER(KIND=1)}.
5091 @cindex INTEGER(KIND=2) type
5092 @cindex types, INTEGER(KIND=2)
5093 @item INTEGER(KIND=2)
5094 Twice the size, and usually nearly twice the range,
5095 as @code{INTEGER(KIND=1)}---usually, this is either
5096 a @code{long int} or a @code{long long int}.
5098 @cindex LOGICAL(KIND=2) type
5099 @cindex types, LOGICAL(KIND=2)
5100 @item LOGICAL(KIND=2)
5101 Same @command{gcc} type as @code{INTEGER(KIND=2)}.
5103 @cindex INTEGER(KIND=3) type
5104 @cindex types, INTEGER(KIND=3)
5105 @item INTEGER(KIND=3)
5106 Same @command{gcc} type as signed @code{char}.
5108 @cindex LOGICAL(KIND=3) type
5109 @cindex types, LOGICAL(KIND=3)
5110 @item LOGICAL(KIND=3)
5111 Same @command{gcc} type as @code{INTEGER(KIND=3)}.
5113 @cindex INTEGER(KIND=6) type
5114 @cindex types, INTEGER(KIND=6)
5115 @item INTEGER(KIND=6)
5116 Twice the size, and usually nearly twice the range,
5117 as @code{INTEGER(KIND=3)}---usually, this is
5120 @cindex LOGICAL(KIND=6) type
5121 @cindex types, LOGICAL(KIND=6)
5122 @item LOGICAL(KIND=6)
5123 Same @command{gcc} type as @code{INTEGER(KIND=6)}.
5125 @cindex COMPLEX(KIND=1) type
5126 @cindex types, COMPLEX(KIND=1)
5127 @item COMPLEX(KIND=1)
5128 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
5129 one for the imaginary part).
5131 @cindex COMPLEX(KIND=2) type
5132 @cindex types, COMPLEX(KIND=2)
5133 @item COMPLEX(KIND=2)
5134 Two @code{REAL(KIND=2)} scalars.
5136 @cindex *@var{n} notation
5137 @item @var{numeric-type}*@var{n}
5138 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
5139 Same as whatever @command{gcc} type occupies @var{n} times the storage
5140 space of a @command{gcc} @code{char} item.
5142 @cindex DOUBLE PRECISION type
5143 @cindex types, DOUBLE PRECISION
5144 @item DOUBLE PRECISION
5145 Same as @code{REAL(KIND=2)}.
5147 @cindex DOUBLE COMPLEX type
5148 @cindex types, DOUBLE COMPLEX
5149 @item DOUBLE COMPLEX
5150 Same as @code{COMPLEX(KIND=2)}.
5153 Note that the above are proposed correspondences and might change
5154 in future versions of @command{g77}---avoid writing code depending
5157 Other types supported by @command{g77}
5158 are derived from gcc types such as @code{char}, @code{short},
5159 @code{int}, @code{long int}, @code{long long int}, @code{long double},
5161 That is, whatever types @command{gcc} already supports, @command{g77} supports
5162 now or probably will support in a future version.
5163 The rules for the @samp{@var{numeric-type}*@var{n}} notation
5164 apply to these types,
5165 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
5166 assigned in a way that encourages clarity, consistency, and portability.
5168 @node Compiler Constants
5169 @section Compiler Constants
5171 @cindex types, constants
5173 @command{g77} strictly assigns types to @emph{all} constants not
5174 documented as ``typeless'' (typeless constants including @samp{'1'Z},
5176 Many other Fortran compilers attempt to assign types to typed constants
5177 based on their context.
5178 This results in hard-to-find bugs, nonportable
5179 code, and is not in the spirit (though it strictly follows the letter)
5180 of the 77 and 90 standards.
5182 @command{g77} might offer, in a future release, explicit constructs by
5183 which a wider variety of typeless constants may be specified, and/or
5184 user-requested warnings indicating places where @command{g77} might differ
5185 from how other compilers assign types to constants.
5187 @xref{Context-Sensitive Constants}, for more information on this issue.
5189 @node Compiler Intrinsics
5190 @section Compiler Intrinsics
5192 @command{g77} offers an ever-widening set of intrinsics.
5193 Currently these all are procedures (functions and subroutines).
5195 Some of these intrinsics are unimplemented, but their names reserved
5196 to reduce future problems with existing code as they are implemented.
5197 Others are implemented as part of the GNU Fortran language, while
5198 yet others are provided for compatibility with other dialects of
5199 Fortran but are not part of the GNU Fortran language.
5201 To manage these distinctions, @command{g77} provides intrinsic @emph{groups},
5202 a facility that is simply an extension of the intrinsic groups provided
5203 by the GNU Fortran language.
5206 * Intrinsic Groups:: How intrinsics are grouped for easy management.
5207 * Other Intrinsics:: Intrinsics other than those in the GNU
5211 @node Intrinsic Groups
5212 @subsection Intrinsic Groups
5213 @cindex groups of intrinsics
5214 @cindex intrinsics, groups
5216 A given specific intrinsic belongs in one or more groups.
5217 Each group is deleted, disabled, hidden, or enabled
5218 by default or a command-line option.
5219 The meaning of each term follows.
5222 @cindex deleted intrinsics
5223 @cindex intrinsics, deleted
5225 No intrinsics are recognized as belonging to that group.
5227 @cindex disabled intrinsics
5228 @cindex intrinsics, disabled
5230 Intrinsics are recognized as belonging to the group, but
5231 references to them (other than via the @code{INTRINSIC} statement)
5232 are disallowed through that group.
5234 @cindex hidden intrinsics
5235 @cindex intrinsics, hidden
5237 Intrinsics in that group are recognized and enabled (if implemented)
5238 @emph{only} if the first mention of the actual name of an intrinsic
5239 in a program unit is in an @code{INTRINSIC} statement.
5241 @cindex enabled intrinsics
5242 @cindex intrinsics, enabled
5244 Intrinsics in that group are recognized and enabled (if implemented).
5247 The distinction between deleting and disabling a group is illustrated
5248 by the following example.
5249 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
5250 If group @samp{FGR} is deleted, the following program unit will
5251 successfully compile, because @samp{FOO()} will be seen as a
5252 reference to an external function named @samp{FOO}:
5260 If group @samp{FGR} is disabled, compiling the above program will produce
5261 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
5262 or, if properly invoked, it is not enabled.
5263 To change the above program so it references an external function @samp{FOO}
5264 instead of the disabled @samp{FOO} intrinsic,
5265 add the following line to the top:
5272 So, deleting a group tells @command{g77} to pretend as though the intrinsics in
5273 that group do not exist at all, whereas disabling it tells @command{g77} to
5274 recognize them as (disabled) intrinsics in intrinsic-like contexts.
5276 Hiding a group is like enabling it, but the intrinsic must be first
5277 named in an @code{INTRINSIC} statement to be considered a reference to the
5278 intrinsic rather than to an external procedure.
5279 This might be the ``safest'' way to treat a new group of intrinsics
5281 code, because it allows the old code to be generally written as if
5282 those new intrinsics never existed, but to be changed to use them
5283 by inserting @code{INTRINSIC} statements in the appropriate places.
5284 However, it should be the goal of development to use @code{EXTERNAL}
5285 for all names of external procedures that might be intrinsic names.
5287 If an intrinsic is in more than one group, it is enabled if any of its
5288 containing groups are enabled; if not so enabled, it is hidden if
5289 any of its containing groups are hidden; if not so hidden, it is disabled
5290 if any of its containing groups are disabled; if not so disabled, it is
5292 This extra complication is necessary because some intrinsics,
5293 such as @code{IBITS}, belong to more than one group, and hence should be
5294 enabled if any of the groups to which they belong are enabled, and so
5299 @cindex intrinsics, groups of
5300 @cindex groups of intrinsics
5302 @cindex @code{badu77} intrinsics group
5304 UNIX intrinsics having inappropriate forms (usually functions that
5305 have intended side effects).
5307 @cindex @code{gnu} intrinsics group
5309 Intrinsics the GNU Fortran language supports that are extensions to
5310 the Fortran standards (77 and 90).
5312 @cindex @command{f2c} intrinsics group
5314 Intrinsics supported by AT&T's @command{f2c} converter and/or @code{libf2c}.
5316 @cindex @code{f90} intrinsics group
5318 Fortran 90 intrinsics.
5320 @cindex @code{mil} intrinsics group
5322 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
5324 @cindex @code{mil} intrinsics group
5326 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
5328 @cindex @code{mil} intrinsics group
5330 VAX/VMS FORTRAN (current as of v4) intrinsics.
5333 @node Other Intrinsics
5334 @subsection Other Intrinsics
5335 @cindex intrinsics, others
5336 @cindex other intrinsics
5338 @command{g77} supports intrinsics other than those in the GNU Fortran
5340 This set of intrinsics is described below.
5343 (Note that the empty lines appearing in the menu below
5344 are not intentional---they result from a bug in the
5345 @code{makeinfo} program.)
5348 @c The actual documentation for intrinsics comes from
5349 @c intdoc.texi, which in turn is automatically generated
5350 @c from the internal g77 tables in intrin.def _and_ the
5351 @c largely hand-written text in intdoc.h. So, if you want
5352 @c to change or add to existing documentation on intrinsics,
5353 @c you probably want to edit intdoc.h.
5365 @include intdoc.texi
5367 @node Other Compilers
5368 @chapter Other Compilers
5370 An individual Fortran source file can be compiled to
5371 an object (@file{*.o}) file instead of to the final
5373 This allows several portions of a program to be compiled
5374 at different times and linked together whenever a new
5375 version of the program is needed.
5376 However, it introduces the issue of @dfn{object compatibility}
5377 across the various object files (and libraries, or @file{*.a}
5378 files) that are linked together to produce any particular
5381 Object compatibility is an issue when combining, in one
5382 program, Fortran code compiled by more than one compiler
5383 (or more than one configuration of a compiler).
5385 disagree on how to transform the names of procedures, there
5386 will normally be errors when linking such programs.
5387 Worse, if the compilers agree on naming, but disagree on issues
5388 like how to pass parameters, return arguments, and lay out
5389 @code{COMMON} areas, the earliest detected errors might be the
5390 incorrect results produced by the program (and that assumes
5391 these errors are detected, which is not always the case).
5393 Normally, @command{g77} generates code that is
5394 object-compatible with code generated by a version of
5395 @command{f2c} configured (with, for example, @file{f2c.h} definitions)
5396 to be generally compatible with @command{g77} as built by @command{gcc}.
5397 (Normally, @command{f2c} will, by default, conform to the appropriate
5398 configuration, but it is possible that older or perhaps even newer
5399 versions of @command{f2c}, or versions having certain configuration changes
5400 to @command{f2c} internals, will produce object files that are
5401 incompatible with @command{g77}.)
5403 For example, a Fortran string subroutine
5404 argument will become two arguments on the C side: a @code{char *}
5405 and an @code{int} length.
5407 Much of this compatibility results from the fact that
5408 @command{g77} uses the same run-time library,
5409 @code{libf2c}, used by @command{f2c},
5410 though @command{g77} gives its version the name @code{libg2c}
5411 so as to avoid conflicts when linking,
5412 installing them in the same directories,
5415 Other compilers might or might not generate code that
5416 is object-compatible with @code{libg2c} and current @command{g77},
5417 and some might offer such compatibility only when explicitly
5418 selected via a command-line option to the compiler.
5420 @emph{Note: This portion of the documentation definitely needs a lot
5424 * Dropping f2c Compatibility:: When speed is more important.
5425 * Compilers Other Than f2c:: Interoperation with code from other compilers.
5428 @node Dropping f2c Compatibility
5429 @section Dropping @command{f2c} Compatibility
5431 Specifying @option{-fno-f2c} allows @command{g77} to generate, in
5432 some cases, faster code, by not needing to allow to the possibility
5433 of linking with code compiled by @command{f2c}.
5435 For example, this affects how @code{REAL(KIND=1)},
5436 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
5437 With @option{-fno-f2c}, they are
5438 compiled as returning the appropriate @command{gcc} type
5439 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
5440 in many configurations).
5442 With @option{-ff2c} in force, they
5443 are compiled differently (with perhaps slower run-time performance)
5444 to accommodate the restrictions inherent in @command{f2c}'s use of K&R
5445 C as an intermediate language---@code{REAL(KIND=1)} functions
5446 return C's @code{double} type, while @code{COMPLEX} functions return
5447 @code{void} and use an extra argument pointing to a place for the functions to
5448 return their values.
5450 It is possible that, in some cases, leaving @option{-ff2c} in force
5451 might produce faster code than using @option{-fno-f2c}.
5452 Feel free to experiment, but remember to experiment with changing the way
5453 @emph{entire programs and their Fortran libraries are compiled} at
5454 a time, since this sort of experimentation affects the interface
5455 of code generated for a Fortran source file---that is, it affects
5456 object compatibility.
5458 Note that @command{f2c} compatibility is a fairly static target to achieve,
5459 though not necessarily perfectly so, since, like @command{g77}, it is
5460 still being improved.
5461 However, specifying @option{-fno-f2c} causes @command{g77}
5462 to generate code that will probably be incompatible with code
5463 generated by future versions of @command{g77} when the same option
5465 You should make sure you are always able to recompile complete
5466 programs from source code when upgrading to new versions of @command{g77}
5467 or @command{f2c}, especially when using options such as @option{-fno-f2c}.
5469 Therefore, if you are using @command{g77} to compile libraries and other
5470 object files for possible future use and you don't want to require
5471 recompilation for future use with subsequent versions of @command{g77},
5472 you might want to stick with @command{f2c} compatibility for now, and
5473 carefully watch for any announcements about changes to the
5474 @command{f2c}/@code{libf2c} interface that might affect existing programs
5475 (thus requiring recompilation).
5477 It is probable that a future version of @command{g77} will not,
5478 by default, generate object files compatible with @command{f2c},
5479 and that version probably would no longer use @code{libf2c}.
5480 If you expect to depend on this compatibility in the
5481 long term, use the options @samp{-ff2c -ff2c-library} when compiling
5482 all of the applicable code.
5483 This should cause future versions of @command{g77} either to produce
5484 compatible code (at the expense of the availability of some features and
5485 performance), or at the very least, to produce diagnostics.
5487 (The library @command{g77} produces will no longer be named @file{libg2c}
5488 when it is no longer generally compatible with @file{libf2c}.
5489 It will likely be referred to, and, if installed as a distinct
5490 library, named @code{libg77}, or some other as-yet-unused name.)
5492 @node Compilers Other Than f2c
5493 @section Compilers Other Than @command{f2c}
5495 On systems with Fortran compilers other than @command{f2c} and @command{g77},
5496 code compiled by @command{g77} is not expected to work
5497 well with code compiled by the native compiler.
5498 (This is true for @command{f2c}-compiled objects as well.)
5499 Libraries compiled with the native compiler probably will have
5500 to be recompiled with @command{g77} to be used with @command{g77}-compiled code.
5502 Reasons for such incompatibilities include:
5506 There might be differences in the way names of Fortran procedures
5507 are translated for use in the system's object-file format.
5508 For example, the statement @samp{CALL FOO} might be compiled
5509 by @command{g77} to call a procedure the linker @command{ld} sees
5510 given the name @samp{_foo_}, while the apparently corresponding
5511 statement @samp{SUBROUTINE FOO} might be compiled by the
5512 native compiler to define the linker-visible name @samp{_foo},
5513 or @samp{_FOO_}, and so on.
5516 There might be subtle type mismatches which cause subroutine arguments
5517 and function return values to get corrupted.
5519 This is why simply getting @command{g77} to
5520 transform procedure names the same way a native
5521 compiler does is not usually a good idea---unless
5522 some effort has been made to ensure that, aside
5523 from the way the two compilers transform procedure
5524 names, everything else about the way they generate
5525 code for procedure interfaces is identical.
5529 use libraries of private I/O routines which will not be available
5530 at link time unless you have the native compiler---and you would
5531 have to explicitly ask for them.
5533 For example, on the Sun you
5534 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
5538 @node Other Languages
5539 @chapter Other Languages
5541 @emph{Note: This portion of the documentation definitely needs a lot
5545 * Interoperating with C and C++::
5548 @node Interoperating with C and C++
5549 @section Tools and advice for interoperating with C and C++
5551 @cindex C, linking with
5552 @cindex C++, linking with
5553 @cindex linking with C
5554 The following discussion assumes that you are running @command{g77} in @command{f2c}
5555 compatibility mode, i.e.@: not using @option{-fno-f2c}.
5557 advice about quick and simple techniques for linking Fortran and C (or
5558 C++), the most common requirement.
5559 For the full story consult the
5560 description of code generation.
5561 @xref{Debugging and Interfacing}.
5563 When linking Fortran and C, it's usually best to use @command{g77} to do
5564 the linking so that the correct libraries are included (including the
5566 If you're linking with C++ you will want to add
5567 @option{-lstdc++}, @option{-lg++} or whatever.
5568 If you need to use another
5569 driver program (or @command{ld} directly),
5570 you can find out what linkage
5571 options @command{g77} passes by running @samp{g77 -v}.
5574 * C Interfacing Tools::
5575 * C Access to Type Information::
5576 * f2c Skeletons and Prototypes::
5577 * C++ Considerations::
5581 @node C Interfacing Tools
5582 @subsection C Interfacing Tools
5586 Even if you don't actually use it as a compiler, @command{f2c} from
5587 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
5588 interfacing (linking) Fortran and C@.
5589 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @command{f2c}}.
5591 To use @command{f2c} for this purpose you only need retrieve and
5592 build the @file{src} directory from the distribution, consult the
5593 @file{README} instructions there for machine-specifics, and install the
5594 @command{f2c} program on your path.
5596 Something else that might be useful is @samp{cfortran.h} from
5597 @uref{ftp://zebra.desy.de/cfortran}.
5598 This is a fairly general tool which
5599 can be used to generate interfaces for calling in both directions
5600 between Fortran and C@.
5601 It can be used in @command{f2c} mode with
5602 @command{g77}---consult its documentation for details.
5604 @node C Access to Type Information
5605 @subsection Accessing Type Information in C
5607 @cindex types, Fortran/C
5608 Generally, C code written to link with
5609 @command{g77} code---calling and/or being
5610 called from Fortran---should @samp{#include <g2c.h>} to define the C
5611 versions of the Fortran types.
5612 Don't assume Fortran @code{INTEGER} types
5613 correspond to C @code{int}s, for instance; instead, declare them as
5614 @code{integer}, a type defined by @file{g2c.h}.
5615 @file{g2c.h} is installed where @command{gcc} will find it by
5616 default, assuming you use a copy of @command{gcc} compatible with
5617 @command{g77}, probably built at the same time as @command{g77}.
5619 @node f2c Skeletons and Prototypes
5620 @subsection Generating Skeletons and Prototypes with @command{f2c}
5623 @cindex -fno-second-underscore
5624 A simple and foolproof way to write @command{g77}-callable C routines---e.g.@: to
5625 interface with an existing library---is to write a file (named, for
5626 example, @file{fred.f}) of dummy Fortran
5627 skeletons comprising just the declaration of the routine(s) and dummy
5628 arguments plus @code{END} statements.
5629 Then run @command{f2c} on file @file{fred.f} to produce @file{fred.c}
5630 into which you can edit
5631 useful code, confident the calling sequence is correct, at least.
5632 (There are some errors otherwise commonly made in generating C
5633 interfaces with @command{f2c} conventions,
5634 such as not using @code{doublereal}
5635 as the return type of a @code{REAL} @code{FUNCTION}.)
5638 @command{f2c} also can help with calling Fortran from C, using its
5639 @option{-P} option to generate C prototypes appropriate for calling the
5640 Fortran.@footnote{The files generated like this can also be used for
5641 inter-unit consistency checking of dummy and actual arguments, although
5642 the @command{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
5643 or @uref{ftp://ftp.dsm.fordham.edu} is
5644 probably better for this purpose.}
5645 If the Fortran code containing any
5646 routines to be called from C is in file @file{joe.f}, use the command
5647 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
5648 prototype information.
5649 @code{#include} this in the C which has to call
5650 the Fortran routines to make sure you get it right.
5652 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
5653 between the way Fortran (including compilers like @command{g77}) and
5656 @node C++ Considerations
5657 @subsection C++ Considerations
5660 @command{f2c} can be used to generate suitable code for compilation with a
5661 C++ system using the @option{-C++} option.
5662 The important thing about linking @command{g77}-compiled
5663 code with C++ is that the prototypes for the @command{g77}
5664 routines must specify C linkage to avoid name mangling.
5665 So, use an @samp{extern "C"} declaration.
5666 @command{f2c}'s @option{-C++} option will take care
5667 of this when generating skeletons or prototype files as above, and also
5668 avoid clashes with C++ reserved words in addition to those in C@.
5671 @subsection Startup Code
5673 @cindex startup code
5674 @cindex run-time, initialization
5675 @cindex initialization, run-time
5676 Unlike with some runtime systems,
5677 it shouldn't be necessary
5678 (unless there are bugs)
5679 to use a Fortran main program unit to ensure the
5680 runtime---specifically the I/O system---is initialized.
5682 However, to use the @command{g77} intrinsics @code{GETARG} and @code{IARGC},
5683 either the @code{main} routine from the @file{libg2c} library must be used,
5684 or the @code{f_setarg} routine
5685 (new as of @code{egcs} version 1.1 and @command{g77} version 0.5.23)
5686 must be called with the appropriate @code{argc} and @code{argv} arguments
5687 prior to the program calling @code{GETARG} or @code{IARGC}.
5689 To provide more flexibility for mixed-language programming
5690 involving @command{g77} while allowing for shared libraries,
5691 as of @code{egcs} version 1.1 and @command{g77} version 0.5.23,
5692 @command{g77}'s @code{main} routine in @code{libg2c}
5693 does the following, in order:
5697 Calls @code{f_setarg}
5698 with the incoming @code{argc} and @code{argv} arguments,
5699 in the same order as for @code{main} itself.
5701 This sets up the command-line environment
5702 for @code{GETARG} and @code{IARGC}.
5705 Calls @code{f_setsig} (with no arguments).
5707 This sets up the signaling and exception environment.
5710 Calls @code{f_init} (with no arguments).
5712 This initializes the I/O environment,
5713 though that should not be necessary,
5714 as all I/O functions in @code{libf2c}
5715 are believed to call @code{f_init} automatically,
5718 (A future version of @command{g77} might skip this explicit step,
5719 to speed up normal exit of a program.)
5722 Arranges for @code{f_exit} to be called (with no arguments)
5723 when the program exits.
5725 This ensures that the I/O environment is properly shut down
5726 before the program exits normally.
5727 Otherwise, output buffers might not be fully flushed,
5728 scratch files might not be deleted, and so on.
5730 The simple way @code{main} does this is
5731 to call @code{f_exit} itself after calling
5732 @code{MAIN__} (in the next step).
5734 However, this does not catch the cases where the program
5735 might call @code{exit} directly,
5736 instead of using the @code{EXIT} intrinsic
5737 (implemented as @code{exit_} in @code{libf2c}).
5739 So, @code{main} attempts to use
5740 the operating environment's @code{onexit} or @code{atexit}
5741 facility, if available,
5742 to cause @code{f_exit} to be called automatically
5743 upon any invocation of @code{exit}.
5746 Calls @code{MAIN__} (with no arguments).
5748 This starts executing the Fortran main program unit for
5750 (Both @command{g77} and @command{f2c} currently compile a main
5751 program unit so that its global name is @code{MAIN__}.)
5754 If no @code{onexit} or @code{atexit} is provided by the system,
5755 calls @code{f_exit}.
5758 Calls @code{exit} with a zero argument,
5759 to signal a successful program termination.
5762 Returns a zero value to the caller,
5763 to signal a successful program termination,
5764 in case @code{exit} doesn't exit on the system.
5767 All of the above names are C @code{extern} names,
5770 When using the @code{main} procedure provided by @command{g77}
5771 without a Fortran main program unit,
5772 you need to provide @code{MAIN__}
5773 as the entry point for your C code.
5774 (Make sure you link the object file that defines that
5775 entry point with the rest of your program.)
5777 To provide your own @code{main} procedure
5778 in place of @command{g77}'s,
5779 make sure you specify the object file defining that procedure
5780 @emph{before} @option{-lg2c} on the @command{g77} command line.
5781 Since the @option{-lg2c} option is implicitly provided,
5782 this is usually straightforward.
5783 (Use the @option{--verbose} option to see how and where
5784 @command{g77} implicitly adds @option{-lg2c} in a command line
5785 that will link the program.
5786 Feel free to specify @option{-lg2c} explicitly,
5789 However, when providing your own @code{main},
5790 make sure you perform the appropriate tasks in the
5792 For example, if your @code{main} does not call @code{f_setarg},
5793 make sure the rest of your application does not call
5794 @code{GETARG} or @code{IARGC}.
5796 And, if your @code{main} fails to ensure that @code{f_exit}
5797 is called upon program exit,
5798 some files might end up incompletely written,
5799 some scratch files might be left lying around,
5800 and some existing files being written might be left
5801 with old data not properly truncated at the end.
5803 Note that, generally, the @command{g77} operating environment
5804 does not depend on a procedure named @code{MAIN__} actually
5805 being called prior to any other @command{g77}-compiled code.
5806 That is, @code{MAIN__} does not, itself,
5807 set up any important operating-environment characteristics
5808 upon which other code might depend.
5809 This might change in future versions of @command{g77},
5810 with appropriate notification in the release notes.
5812 For more information, consult the source code for the above routines.
5813 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
5814 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
5816 Also, the file @file{@value{path-g77}/com.c} contains the code @command{g77}
5817 uses to open-code (inline) references to @code{IARGC}.
5819 @node Debugging and Interfacing
5820 @chapter Debugging and Interfacing
5823 @cindex calling C routines
5824 @cindex C routines calling Fortran
5825 @cindex f2c compatibility
5827 GNU Fortran currently generates code that is object-compatible with
5828 the @command{f2c} converter.
5829 Also, it avoids limitations in the current GBE, such as the
5830 inability to generate a procedure with
5831 multiple entry points, by generating code that is structured
5832 differently (in terms of procedure names, scopes, arguments, and
5833 so on) than might be expected.
5835 As a result, writing code in other languages that calls on, is
5836 called by, or shares in-memory data with @command{g77}-compiled code generally
5837 requires some understanding of the way @command{g77} compiles code for
5840 Similarly, using a debugger to debug @command{g77}-compiled
5841 code, even if that debugger supports native Fortran debugging, generally
5842 requires this sort of information.
5844 This section describes some of the basic information on how
5845 @command{g77} compiles code for constructs involving interfaces to other
5846 languages and to debuggers.
5848 @emph{Caution:} Much or all of this information pertains to only the current
5849 release of @command{g77}, sometimes even to using certain compiler options
5850 with @command{g77} (such as @option{-fno-f2c}).
5851 Do not write code that depends on this
5852 information without clearly marking said code as nonportable and
5853 subject to review for every new release of @command{g77}.
5855 is provided primarily to make debugging of code generated by this
5856 particular release of @command{g77} easier for the user, and partly to make
5857 writing (generally nonportable) interface code easier.
5859 activities require tracking changes in new version of @command{g77} as they
5860 are installed, because new versions can change the behaviors
5861 described in this section.
5864 * Main Program Unit:: How @command{g77} compiles a main program unit.
5865 * Procedures:: How @command{g77} constructs parameter lists
5867 * Functions:: Functions returning floating-point or character data.
5868 * Names:: Naming of user-defined variables, procedures, etc.
5869 * Common Blocks:: Accessing common variables while debugging.
5870 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
5871 * Complex Variables:: How @command{g77} performs complex arithmetic.
5872 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
5873 * Adjustable Arrays:: Special consideration for adjustable arrays.
5874 * Alternate Entry Points:: How @command{g77} implements alternate @code{ENTRY}.
5875 * Alternate Returns:: How @command{g77} handles alternate returns.
5876 * Assigned Statement Labels:: How @command{g77} handles @code{ASSIGN}.
5877 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
5880 @node Main Program Unit
5881 @section Main Program Unit (PROGRAM)
5882 @cindex PROGRAM statement
5883 @cindex statements, PROGRAM
5885 When @command{g77} compiles a main program unit, it gives it the public
5886 procedure name @code{MAIN__}.
5887 The @code{libg2c} library has the actual @code{main()} procedure
5888 as is typical of C-based environments, and
5889 it is this procedure that performs some initial start-up
5890 activity and then calls @code{MAIN__}.
5892 Generally, @command{g77} and @code{libg2c} are designed so that you need not
5893 include a main program unit written in Fortran in your program---it
5894 can be written in C or some other language.
5895 Especially for I/O handling, this is the case, although @command{g77} version 0.5.16
5896 includes a bug fix for @code{libg2c} that solved a problem with using the
5897 @code{OPEN} statement as the first Fortran I/O activity in a program
5898 without a Fortran main program unit.
5900 However, if you don't intend to use @command{g77} (or @command{f2c}) to compile
5901 your main program unit---that is, if you intend to compile a @code{main()}
5902 procedure using some other language---you should carefully
5903 examine the code for @code{main()} in @code{libg2c}, found in the source
5904 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
5905 might need to be done by your @code{main()} in order to provide the
5906 Fortran environment your Fortran code is expecting.
5908 @cindex @code{IArgC} intrinsic
5909 @cindex intrinsics, @code{IArgC}
5910 @cindex @code{GetArg} intrinsic
5911 @cindex intrinsics, @code{GetArg}
5912 For example, @code{libg2c}'s @code{main()} sets up the information used by
5913 the @code{IARGC} and @code{GETARG} intrinsics.
5914 Bypassing @code{libg2c}'s @code{main()}
5915 without providing a substitute for this activity would mean
5916 that invoking @code{IARGC} and @code{GETARG} would produce undefined
5920 @cindex main program unit, debugging
5924 When debugging, one implication of the fact that @code{main()}, which
5925 is the place where the debugged program ``starts'' from the
5926 debugger's point of view, is in @code{libg2c} is that you won't be
5927 starting your Fortran program at a point you recognize as your
5930 The standard way to get around this problem is to set a break
5931 point (a one-time, or temporary, break point will do) at
5932 the entrance to @code{MAIN__}, and then run the program.
5933 A convenient way to do so is to add the @command{gdb} command
5940 to the file @file{.gdbinit} in the directory in which you're debugging
5941 (using @command{gdb}).
5943 After doing this, the debugger will see the current execution
5944 point of the program as at the beginning of the main program
5945 unit of your program.
5947 Of course, if you really want to set a break point at some
5948 other place in your program and just start the program
5949 running, without first breaking at @code{MAIN__},
5950 that should work fine.
5953 @section Procedures (SUBROUTINE and FUNCTION)
5955 @cindex SUBROUTINE statement
5956 @cindex statements, SUBROUTINE
5957 @cindex FUNCTION statement
5958 @cindex statements, FUNCTION
5959 @cindex signature of procedures
5961 Currently, @command{g77} passes arguments via reference---specifically,
5962 by passing a pointer to the location in memory of a variable, array,
5963 array element, a temporary location that holds the result of evaluating an
5964 expression, or a temporary or permanent location that holds the value
5967 Procedures that accept @code{CHARACTER} arguments are implemented by
5968 @command{g77} so that each @code{CHARACTER} argument has two actual arguments.
5970 The first argument occupies the expected position in the
5971 argument list and has the user-specified name.
5973 is a pointer to an array of characters, passed by the caller.
5975 The second argument is appended to the end of the user-specified
5976 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
5977 is the user-specified name.
5978 This argument is of the C type @code{ftnlen}
5979 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
5980 is the number of characters the caller has allocated in the
5981 array pointed to by the first argument.
5983 A procedure will ignore the length argument if @samp{X} is not declared
5984 @code{CHARACTER*(*)}, because for other declarations, it knows the
5986 Not all callers necessarily ``know'' this, however, which
5987 is why they all pass the extra argument.
5989 The contents of the @code{CHARACTER} argument are specified by the
5990 address passed in the first argument (named after it).
5991 The procedure can read or write these contents as appropriate.
5993 When more than one @code{CHARACTER} argument is present in the argument
5994 list, the length arguments are appended in the order
5995 the original arguments appear.
5996 So @samp{CALL FOO('HI','THERE')} is implemented in
5997 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @command{g77}
5998 does not provide the trailing null bytes on the constant
5999 strings (@command{f2c} does provide them, but they are unnecessary in
6000 a Fortran environment, and you should not expect them to be
6003 Note that the above information applies to @code{CHARACTER} variables and
6004 arrays @strong{only}.
6005 It does @strong{not} apply to external @code{CHARACTER}
6006 functions or to intrinsic @code{CHARACTER} functions.
6007 That is, no second length argument is passed to @samp{FOO} in this case:
6016 Nor does @samp{FOO} expect such an argument in this case:
6024 Because of this implementation detail, if a program has a bug
6025 such that there is disagreement as to whether an argument is
6026 a procedure, and the type of the argument is @code{CHARACTER}, subtle
6027 symptoms might appear.
6030 @section Functions (FUNCTION and RETURN)
6032 @cindex FUNCTION statement
6033 @cindex statements, FUNCTION
6034 @cindex RETURN statement
6035 @cindex statements, RETURN
6036 @cindex return type of functions
6038 @command{g77} handles in a special way functions that return the following
6050 For @code{CHARACTER}, @command{g77} implements a subroutine (a C function
6051 returning @code{void})
6052 with two arguments prepended: @samp{__g77_result}, which the caller passes
6053 as a pointer to a @code{char} array expected to hold the return value,
6054 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
6055 specifying the length of the return value as declared in the calling
6057 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
6058 to determine the size of the array that @samp{__g77_result} points to;
6059 otherwise, it ignores that argument.
6061 For @code{COMPLEX}, when @option{-ff2c} is in
6062 force, @command{g77} implements
6063 a subroutine with one argument prepended: @samp{__g77_result}, which the
6064 caller passes as a pointer to a variable of the type of the function.
6065 The called function writes the return value into this variable instead
6066 of returning it as a function value.
6067 When @option{-fno-f2c} is in force,
6068 @command{g77} implements a @code{COMPLEX} function as @command{gcc}'s
6069 @samp{__complex__ float} or @samp{__complex__ double} function
6070 (or an emulation thereof, when @option{-femulate-complex} is in effect),
6071 returning the result of the function in the same way as @command{gcc} would.
6073 For @code{REAL(KIND=1)}, when @option{-ff2c} is in force, @command{g77} implements
6074 a function that actually returns @code{REAL(KIND=2)} (typically
6075 C's @code{double} type).
6076 When @option{-fno-f2c} is in force, @code{REAL(KIND=1)}
6077 functions return @code{float}.
6081 @cindex symbol names
6082 @cindex transforming symbol names
6084 Fortran permits each implementation to decide how to represent
6085 names as far as how they're seen in other contexts, such as debuggers
6086 and when interfacing to other languages, and especially as far
6087 as how casing is handled.
6089 External names---names of entities that are public, or ``accessible'',
6090 to all modules in a program---normally have an underscore (@samp{_})
6091 appended by @command{g77},
6092 to generate code that is compatible with @command{f2c}.
6093 External names include names of Fortran things like common blocks,
6094 external procedures (subroutines and functions, but not including
6095 statement functions, which are internal procedures), and entry point
6098 However, use of the @option{-fno-underscoring} option
6099 disables this kind of transformation of external names (though inhibiting
6100 the transformation certainly improves the chances of colliding with
6101 incompatible externals written in other languages---but that
6102 might be intentional.
6104 @cindex -fno-underscoring option
6105 @cindex options, -fno-underscoring
6106 @cindex -fno-second-underscore option
6107 @cindex options, -fno-underscoring
6108 When @option{-funderscoring} is in force, any name (external or local)
6109 that already has at least one underscore in it is
6110 implemented by @command{g77} by appending two underscores.
6111 (This second underscore can be disabled via the
6112 @option{-fno-second-underscore} option.)
6113 External names are changed this way for @command{f2c} compatibility.
6114 Local names are changed this way to avoid collisions with external names
6115 that are different in the source code---@command{f2c} does the same thing, but
6116 there's no compatibility issue there except for user expectations while
6127 Here, a user would, in the debugger, refer to this variable using the
6128 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
6129 as described below).
6130 (We hope to improve @command{g77} in this regard in the future---don't
6131 write scripts depending on this behavior!
6132 Also, consider experimenting with the @option{-fno-underscoring}
6133 option to try out debugging without having to massage names by
6136 @command{g77} provides a number of command-line options that allow the user
6137 to control how case mapping is handled for source files.
6138 The default is the traditional UNIX model for Fortran compilers---names
6139 are mapped to lower case.
6140 Other command-line options can be specified to map names to upper
6141 case, or to leave them exactly as written in the source file.
6150 Here, it is normally the case that the variable assigned will be named
6152 This would be the name to enter when using a debugger to
6153 access the variable.
6155 However, depending on the command-line options specified, the
6156 name implemented by @command{g77} might instead be @samp{FOO} or even
6157 @samp{Foo}, thus affecting how debugging is done.
6166 This would normally call a procedure that, if it were in a separate C program,
6167 be defined starting with the line:
6174 However, @command{g77} command-line options could be used to change the casing
6175 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
6176 procedure instead of @samp{foo_}, and the @option{-fno-underscoring} option
6177 could be used to inhibit the appending of the underscore to the name.
6180 @section Common Blocks (COMMON)
6181 @cindex common blocks
6182 @cindex @code{COMMON} statement
6183 @cindex statements, @code{COMMON}
6185 @command{g77} names and lays out @code{COMMON} areas
6186 the same way @command{f2c} does,
6187 for compatibility with @command{f2c}.
6189 @node Local Equivalence Areas
6190 @section Local Equivalence Areas (EQUIVALENCE)
6191 @cindex equivalence areas
6192 @cindex local equivalence areas
6193 @cindex EQUIVALENCE statement
6194 @cindex statements, EQUIVALENCE
6196 @command{g77} treats storage-associated areas involving a @code{COMMON}
6197 block as explained in the section on common blocks.
6199 A local @code{EQUIVALENCE} area is a collection of variables and arrays
6200 connected to each other in any way via @code{EQUIVALENCE}, none of which are
6201 listed in a @code{COMMON} statement.
6203 (@emph{Note:} @command{g77} version 0.5.18 and earlier chose the name
6204 for @var{x} using a different method when more than one name was
6205 in the list of names of entities placed at the beginning of the
6207 Though the documentation specified that the first name listed in
6208 the @code{EQUIVALENCE} statements was chosen for @var{x}, @command{g77}
6209 in fact chose the name using a method that was so complicated,
6210 it seemed easier to change it to an alphabetical sort than to describe the
6211 previous method in the documentation.)
6213 @node Complex Variables
6214 @section Complex Variables (COMPLEX)
6215 @cindex complex variables
6216 @cindex imaginary part
6217 @cindex COMPLEX statement
6218 @cindex statements, COMPLEX
6220 As of 0.5.20, @command{g77} defaults to handling @code{COMPLEX} types
6221 (and related intrinsics, constants, functions, and so on)
6223 makes direct debugging involving these types in Fortran
6224 language mode difficult.
6226 Essentially, @command{g77} implements these types using an
6227 internal construct similar to C's @code{struct}, at least
6228 as seen by the @command{gcc} back end.
6230 Currently, the back end, when outputting debugging info with
6231 the compiled code for the assembler to digest, does not detect
6232 these @code{struct} types as being substitutes for Fortran
6234 As a result, the Fortran language modes of debuggers such as
6235 @command{gdb} see these types as C @code{struct} types, which
6236 they might or might not support.
6238 Until this is fixed, switch to C language mode to work with
6239 entities of @code{COMPLEX} type and then switch back to Fortran language
6241 (In @command{gdb}, this is accomplished via @samp{set lang c} and
6242 either @samp{set lang fortran} or @samp{set lang auto}.)
6245 @section Arrays (DIMENSION)
6246 @cindex DIMENSION statement
6247 @cindex statements, DIMENSION
6248 @cindex array ordering
6249 @cindex ordering, array
6250 @cindex column-major ordering
6251 @cindex row-major ordering
6254 Fortran uses ``column-major ordering'' in its arrays.
6255 This differs from other languages, such as C, which use ``row-major ordering''.
6256 The difference is that, with Fortran, array elements adjacent to
6257 each other in memory differ in the @emph{first} subscript instead of
6258 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
6259 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
6262 affects not only interfacing with and debugging Fortran code,
6263 it can greatly affect how code is designed and written, especially
6264 when code speed and size is a concern.
6266 Fortran also differs from C, a popular language for interfacing and
6267 to support directly in debuggers, in the way arrays are treated.
6268 In C, arrays are single-dimensional and have interesting relationships
6269 to pointers, neither of which is true for Fortran.
6270 As a result, dealing with Fortran arrays from within
6271 an environment limited to C concepts can be challenging.
6273 For example, accessing the array element @samp{A(5,10,20)} is easy enough
6274 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
6276 First, C would treat the A array as a single-dimension array.
6277 Second, C does not understand low bounds for arrays as does Fortran.
6278 Third, C assumes a low bound of zero (0), while Fortran defaults to a
6279 low bound of one (1) and can supports an arbitrary low bound.
6280 Therefore, calculations must be done
6281 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
6282 calculations require knowing the dimensions of @samp{A}.
6284 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
6285 @samp{A(5,10,20)} would be:
6290 + (20-0)*(11-2+1)*(21-1+1)
6295 So the C equivalent in this case would be @samp{a[4293]}.
6297 When using a debugger directly on Fortran code, the C equivalent
6298 might not work, because some debuggers cannot understand the notion
6299 of low bounds other than zero. However, unlike @command{f2c}, @command{g77}
6300 does inform the GBE that a multi-dimensional array (like @samp{A}
6301 in the above example) is really multi-dimensional, rather than a
6302 single-dimensional array, so at least the dimensionality of the array
6305 Debuggers that understand Fortran should have no trouble with
6306 non-zero low bounds, but for non-Fortran debuggers, especially
6307 C debuggers, the above example might have a C equivalent of
6309 This calculation is arrived at by eliminating the subtraction
6310 of the lower bound in the first parenthesized expression on each
6311 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
6312 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
6313 Actually, the implication of
6314 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
6315 but that @samp{a[20][10][5]} produces the equivalent of
6316 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
6318 Come to think of it, perhaps
6319 the behavior is due to the debugger internally compensating for
6320 the lower bounds by offsetting the base address of @samp{a}, leaving
6321 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
6322 its first element as identified by subscripts equal to the
6323 corresponding lower bounds).
6325 You know, maybe nobody really needs to use arrays.
6327 @node Adjustable Arrays
6328 @section Adjustable Arrays (DIMENSION)
6329 @cindex arrays, adjustable
6330 @cindex adjustable arrays
6331 @cindex arrays, automatic
6332 @cindex automatic arrays
6333 @cindex DIMENSION statement
6334 @cindex statements, DIMENSION
6335 @cindex dimensioning arrays
6336 @cindex arrays, dimensioning
6338 Adjustable and automatic arrays in Fortran require the implementation
6340 case, the @command{g77} compiler) to ``memorize'' the expressions that
6341 dimension the arrays each time the procedure is invoked.
6342 This is so that subsequent changes to variables used in those
6343 expressions, made during execution of the procedure, do not
6344 have any effect on the dimensions of those arrays.
6361 Here, the implementation should, when running the program, print something
6369 Note that this shows that while the value of @samp{N} was successfully
6370 changed, the size of the @samp{A} array remained at 5 elements.
6372 To support this, @command{g77} generates code that executes before any user
6373 code (and before the internally generated computed @code{GOTO} to handle
6374 alternate entry points, as described below) that evaluates each
6375 (nonconstant) expression in the list of subscripts for an
6376 array, and saves the result of each such evaluation to be used when
6377 determining the size of the array (instead of re-evaluating the
6380 So, in the above example, when @samp{X} is first invoked, code is
6381 executed that copies the value of @samp{N} to a temporary.
6382 And that same temporary serves as the actual high bound for the single
6383 dimension of the @samp{A} array (the low bound being the constant 1).
6384 Since the user program cannot (legitimately) change the value
6385 of the temporary during execution of the procedure, the size
6386 of the array remains constant during each invocation.
6388 For alternate entry points, the code @command{g77} generates takes into
6389 account the possibility that a dummy adjustable array is not actually
6390 passed to the actual entry point being invoked at that time.
6391 In that case, the public procedure implementing the entry point
6392 passes to the master private procedure implementing all the
6393 code for the entry points a @code{NULL} pointer where a pointer to that
6394 adjustable array would be expected.
6395 The @command{g77}-generated code
6396 doesn't attempt to evaluate any of the expressions in the subscripts
6397 for an array if the pointer to that array is @code{NULL} at run time in
6399 (Don't depend on this particular implementation
6400 by writing code that purposely passes @code{NULL} pointers where the
6401 callee expects adjustable arrays, even if you know the callee
6402 won't reference the arrays---nor should you pass @code{NULL} pointers
6403 for any dummy arguments used in calculating the bounds of such
6404 arrays or leave undefined any values used for that purpose in
6405 COMMON---because the way @command{g77} implements these things might
6406 change in the future!)
6408 @node Alternate Entry Points
6409 @section Alternate Entry Points (ENTRY)
6410 @cindex alternate entry points
6411 @cindex entry points
6412 @cindex ENTRY statement
6413 @cindex statements, ENTRY
6415 The GBE does not understand the general concept of
6416 alternate entry points as Fortran provides via the ENTRY statement.
6417 @command{g77} gets around this by using an approach to compiling procedures
6418 having at least one @code{ENTRY} statement that is almost identical to the
6419 approach used by @command{f2c}.
6420 (An alternate approach could be used that
6421 would probably generate faster, but larger, code that would also
6422 be a bit easier to debug.)
6424 Information on how @command{g77} implements @code{ENTRY} is provided for those
6425 trying to debug such code.
6426 The choice of implementation seems
6427 unlikely to affect code (compiled in other languages) that interfaces
6430 @command{g77} compiles exactly one public procedure for the primary entry
6431 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
6432 That is, in terms of the public interface, there is no difference
6451 The difference between the above two cases lies in the code compiled
6452 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
6453 for the second case, an extra internal procedure is compiled.
6455 For every Fortran procedure with at least one @code{ENTRY}
6456 statement, @command{g77} compiles an extra procedure
6457 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
6458 the name of the primary entry point (which, in the above case,
6459 using the standard compiler options, would be @samp{x_} in C).
6461 This extra procedure is compiled as a private procedure---that is,
6462 a procedure not accessible by name to separately compiled modules.
6463 It contains all the code in the program unit, including the code
6464 for the primary entry point plus for every entry point.
6465 (The code for each public procedure is quite short, and explained later.)
6467 The extra procedure has some other interesting characteristics.
6469 The argument list for this procedure is invented by @command{g77}.
6471 a single integer argument named @samp{__g77_which_entrypoint},
6472 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
6473 entry point index---0 for the primary entry point, 1 for the
6474 first entry point (the first @code{ENTRY} statement encountered), 2 for
6475 the second entry point, and so on.
6477 It also contains, for functions returning @code{CHARACTER} and
6478 (when @option{-ff2c} is in effect) @code{COMPLEX} functions,
6479 and for functions returning different types among the
6480 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
6481 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
6482 is expected at run time to contain a pointer to where to store
6483 the result of the entry point.
6484 For @code{CHARACTER} functions, this
6485 storage area is an array of the appropriate number of characters;
6486 for @code{COMPLEX} functions, it is the appropriate area for the return
6487 type; for multiple-return-type functions, it is a union of all the supported return
6488 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
6489 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
6490 is not supported by @command{g77}).
6492 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
6493 by yet another argument named @samp{__g77_length} that, at run time,
6494 specifies the caller's expected length of the returned value.
6495 Note that only @code{CHARACTER*(*)} functions and entry points actually
6496 make use of this argument, even though it is always passed by
6497 all callers of public @code{CHARACTER} functions (since the caller does not
6498 generally know whether such a function is @code{CHARACTER*(*)} or whether
6499 there are any other callers that don't have that information).
6501 The rest of the argument list is the union of all the arguments
6502 specified for all the entry points (in their usual forms, e.g.
6503 @code{CHARACTER} arguments have extra length arguments, all appended at
6504 the end of this list).
6505 This is considered the ``master list'' of
6508 The code for this procedure has, before the code for the first
6509 executable statement, code much like that for the following Fortran
6513 GOTO (100000,100001,100002), __g77_which_entrypoint
6514 100000 @dots{}code for primary entry point@dots{}
6515 100001 @dots{}code immediately following first ENTRY statement@dots{}
6516 100002 @dots{}code immediately following second ENTRY statement@dots{}
6520 (Note that invalid Fortran statement labels and variable names
6521 are used in the above example to highlight the fact that it
6522 represents code generated by the @command{g77} internals, not code to be
6523 written by the user.)
6525 It is this code that, when the procedure is called, picks which
6526 entry point to start executing.
6528 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
6529 example), those procedures are fairly simple.
6531 are just like they would be if they were self-contained procedures
6532 (without @code{ENTRY}), of course, since that is what the callers
6534 Their code consists of simply calling the private
6535 procedure, described above, with the appropriate extra arguments
6536 (the entry point index, and perhaps a pointer to a multiple-type-
6537 return variable, local to the public procedure, that contains
6538 all the supported returnable non-character types).
6540 that are not listed for a given entry point that are listed for
6541 other entry points, and therefore that are in the ``master list''
6542 for the private procedure, null pointers (in C, the @code{NULL} macro)
6544 Also, for entry points that are part of a multiple-type-
6545 returning function, code is compiled after the call of the private
6546 procedure to extract from the multi-type union the appropriate result,
6547 depending on the type of the entry point in question, returning
6548 that result to the original caller.
6550 When debugging a procedure containing alternate entry points, you
6551 can either set a break point on the public procedure itself (e.g.
6552 a break point on @samp{X} or @samp{Y}) or on the private procedure that
6553 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
6554 If you do the former, you should use the debugger's command to
6555 ``step into'' the called procedure to get to the actual code; with
6556 the latter approach, the break point leaves you right at the
6557 actual code, skipping over the public entry point and its call
6558 to the private procedure (unless you have set a break point there
6559 as well, of course).
6561 Further, the list of dummy arguments that is visible when the
6562 private procedure is active is going to be the expanded version
6563 of the list for whichever particular entry point is active,
6564 as explained above, and the way in which return values are
6565 handled might well be different from how they would be handled
6566 for an equivalent single-entry function.
6568 @node Alternate Returns
6569 @section Alternate Returns (SUBROUTINE and RETURN)
6571 @cindex alternate returns
6572 @cindex SUBROUTINE statement
6573 @cindex statements, SUBROUTINE
6574 @cindex RETURN statement
6575 @cindex statements, RETURN
6577 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
6578 @samp{CALL X(*50)}) are implemented by @command{g77} as functions returning
6579 the C @code{int} type.
6580 The actual alternate-return arguments are omitted from the calling sequence.
6581 Instead, the caller uses
6582 the return value to do a rough equivalent of the Fortran
6583 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
6584 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
6585 function), and the callee just returns whatever integer
6586 is specified in the @code{RETURN} statement for the subroutine
6587 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
6589 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
6591 @node Assigned Statement Labels
6592 @section Assigned Statement Labels (ASSIGN and GOTO)
6593 @cindex assigned statement labels
6594 @cindex statement labels, assigned
6595 @cindex ASSIGN statement
6596 @cindex statements, ASSIGN
6597 @cindex GOTO statement
6598 @cindex statements, GOTO
6600 For portability to machines where a pointer (such as to a label,
6601 which is how @command{g77} implements @code{ASSIGN} and its relatives,
6602 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
6603 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @command{g77}
6604 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
6605 than it does the numerical value in that variable, unless the
6606 variable is wide enough (can hold enough bits).
6608 In particular, while @command{g77} implements
6615 as, in C notation, @samp{i = 10;}, it implements
6622 as, in GNU's extended C notation (for the label syntax),
6623 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
6624 of the Fortran label @samp{10} to make the syntax C-like; @command{g77} doesn't
6625 actually generate the name @samp{L10} or any other name like that,
6626 since debuggers cannot access labels anyway).
6628 While this currently means that an @code{ASSIGN} statement does not
6629 overwrite the numeric contents of its target variable, @emph{do not}
6630 write any code depending on this feature.
6631 @command{g77} has already changed this implementation across
6632 versions and might do so in the future.
6633 This information is provided only to make debugging Fortran programs
6634 compiled with the current version of @command{g77} somewhat easier.
6635 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
6636 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
6637 means @command{g77} has decided it can store the pointer to the label directly
6638 into @samp{I} itself.
6640 @xref{Ugly Assigned Labels}, for information on a command-line option
6641 to force @command{g77} to use the same storage for both normal and
6642 assigned-label uses of a variable.
6644 @node Run-time Library Errors
6645 @section Run-time Library Errors
6647 @cindex error values
6648 @cindex error messages
6649 @cindex messages, run-time
6652 The @code{libg2c} library currently has the following table to relate
6653 error code numbers, returned in @code{IOSTAT=} variables, to messages.
6654 This information should, in future versions of this document, be
6655 expanded upon to include detailed descriptions of each message.
6657 In line with good coding practices, any of the numbers in the
6658 list below should @emph{not} be directly written into Fortran
6660 Instead, make a separate @code{INCLUDE} file that defines
6661 @code{PARAMETER} names for them, and use those in your code,
6662 so you can more easily change the actual numbers in the future.
6664 The information below is culled from the definition
6665 of @code{F_err} in @file{f/runtime/libI77/err.c} in the
6666 @command{g77} source tree.
6669 100: "error in format"
6670 101: "illegal unit number"
6671 102: "formatted io not allowed"
6672 103: "unformatted io not allowed"
6673 104: "direct io not allowed"
6674 105: "sequential io not allowed"
6675 106: "can't backspace file"
6676 107: "null file name"
6677 108: "can't stat file"
6678 109: "unit not connected"
6679 110: "off end of record"
6680 111: "truncation failed in endfile"
6681 112: "incomprehensible list input"
6682 113: "out of free space"
6683 114: "unit not connected"
6684 115: "read unexpected character"
6685 116: "bad logical input field"
6686 117: "bad variable type"
6687 118: "bad namelist name"
6688 119: "variable not in namelist"
6689 120: "no end record"
6690 121: "variable count incorrect"
6691 122: "subscript for scalar variable"
6692 123: "invalid array section"
6693 124: "substring out of bounds"
6694 125: "subscript out of bounds"
6695 126: "can't read file"
6696 127: "can't write file"
6697 128: "'new' file exists"
6698 129: "can't append to file"
6699 130: "non-positive record number"
6700 131: "I/O started while already doing I/O"
6703 @node Collected Fortran Wisdom
6704 @chapter Collected Fortran Wisdom
6707 @cindex code, legacy
6708 @cindex writing code
6709 @cindex code, writing
6711 Most users of @command{g77} can be divided into two camps:
6715 Those writing new Fortran code to be compiled by @command{g77}.
6718 Those using @command{g77} to compile existing, ``legacy'' code.
6721 Users writing new code generally understand most of the necessary
6722 aspects of Fortran to write ``mainstream'' code, but often need
6723 help deciding how to handle problems, such as the construction
6724 of libraries containing @code{BLOCK DATA}.
6726 Users dealing with ``legacy'' code sometimes don't have much
6727 experience with Fortran, but believe that the code they're compiling
6728 already works when compiled by other compilers (and might
6729 not understand why, as is sometimes the case, it doesn't work
6730 when compiled by @command{g77}).
6732 The following information is designed to help users do a better job
6733 coping with existing, ``legacy'' Fortran code, and with writing
6737 * Advantages Over f2c:: If @command{f2c} is so great, why @command{g77}?
6738 * Block Data and Libraries:: How @command{g77} solves a common problem.
6739 * Loops:: Fortran @code{DO} loops surprise many people.
6740 * Working Programs:: Getting programs to work should be done first.
6741 * Overly Convenient Options:: Temptations to avoid, habits to not form.
6742 * Faster Programs:: Everybody wants these, but at what cost?
6745 @node Advantages Over f2c
6746 @section Advantages Over f2c
6748 Without @command{f2c}, @command{g77} would have taken much longer to
6749 do and probably not been as good for quite a while.
6750 Sometimes people who notice how much @command{g77} depends on, and
6751 documents encouragement to use, @command{f2c} ask why @command{g77}
6752 was created if @command{f2c} already existed.
6754 This section gives some basic answers to these questions, though it
6755 is not intended to be comprehensive.
6758 * Language Extensions:: Features used by Fortran code.
6759 * Diagnostic Abilities:: Abilities to spot problems early.
6760 * Compiler Options:: Features helpful to accommodate legacy code, etc.
6761 * Compiler Speed:: Speed of the compilation process.
6762 * Program Speed:: Speed of the generated, optimized code.
6763 * Ease of Debugging:: Debugging ease-of-use at the source level.
6764 * Character and Hollerith Constants:: A byte saved is a byte earned.
6767 @node Language Extensions
6768 @subsection Language Extensions
6770 @command{g77} offers several extensions to FORTRAN 77 language that @command{f2c}
6778 @code{CYCLE} and @code{EXIT}
6787 @code{KIND=} and @code{LEN=} notation
6790 Semicolon as statement separator
6793 Constant expressions in @code{FORMAT} statements
6794 (such as @samp{FORMAT(I<J>)},
6795 where @samp{J} is a @code{PARAMETER} named constant)
6798 @code{MvBits} intrinsic
6801 @code{libU77} (Unix-compatibility) library,
6802 with routines known to compiler as intrinsics
6803 (so they work even when compiler options are used
6804 to change the interfaces used by Fortran routines)
6807 @command{g77} also implements iterative @code{DO} loops
6808 so that they work even in the presence of certain ``extreme'' inputs,
6809 unlike @command{f2c}.
6812 However, @command{f2c} offers a few that @command{g77} doesn't, such as:
6816 Intrinsics in @code{PARAMETER} statements
6819 Array bounds expressions (such as @samp{REAL M(N(2))})
6822 @code{AUTOMATIC} statement
6825 It is expected that @command{g77} will offer some or all of these missing
6826 features at some time in the future.
6828 @node Diagnostic Abilities
6829 @subsection Diagnostic Abilities
6831 @command{g77} offers better diagnosis of problems in @code{FORMAT} statements.
6832 @command{f2c} doesn't, for example, emit any diagnostic for
6833 @samp{FORMAT(XZFAJG10324)},
6834 leaving that to be diagnosed, at run time, by
6835 the @code{libf2c} run-time library.
6837 @node Compiler Options
6838 @subsection Compiler Options
6840 @command{g77} offers compiler options that @command{f2c} doesn't,
6841 most of which are designed to more easily accommodate
6846 Two that control the automatic appending of extra
6847 underscores to external names
6850 One that allows dollar signs (@samp{$}) in symbol names
6853 A variety that control acceptance of various
6857 Several that specify acceptable use of upper and lower case
6861 Many that enable, disable, delete, or hide
6862 groups of intrinsics
6865 One to specify the length of fixed-form source lines
6869 One to specify the the source code is written in
6870 Fortran-90-style free-form
6873 However, @command{f2c} offers a few that @command{g77} doesn't,
6874 like an option to have @code{REAL} default to @code{REAL*8}.
6875 It is expected that @command{g77} will offer all of the
6876 missing options pertinent to being a Fortran compiler
6877 at some time in the future.
6879 @node Compiler Speed
6880 @subsection Compiler Speed
6882 Saving the steps of writing and then rereading C code is a big reason
6883 why @command{g77} should be able to compile code much faster than using
6884 @command{f2c} in conjunction with the equivalent invocation of @command{gcc}.
6886 However, due to @command{g77}'s youth, lots of self-checking is still being
6888 As a result, this improvement is as yet unrealized
6889 (though the potential seems to be there for quite a big speedup
6891 It is possible that, as of version 0.5.18, @command{g77}
6892 is noticeably faster compiling many Fortran source files than using
6893 @command{f2c} in conjunction with @command{gcc}.
6896 @subsection Program Speed
6898 @command{g77} has the potential to better optimize code than @command{f2c},
6899 even when @command{gcc} is used to compile the output of @command{f2c},
6900 because @command{f2c} must necessarily
6901 translate Fortran into a somewhat lower-level language (C) that cannot
6902 preserve all the information that is potentially useful for optimization,
6903 while @command{g77} can gather, preserve, and transmit that information directly
6906 For example, @command{g77} implements @code{ASSIGN} and assigned
6907 @code{GOTO} using direct assignment of pointers to labels and direct
6908 jumps to labels, whereas @command{f2c} maps the assigned labels to
6909 integer values and then uses a C @code{switch} statement to encode
6910 the assigned @code{GOTO} statements.
6912 However, as is typical, theory and reality don't quite match, at least
6913 not in all cases, so it is still the case that @command{f2c} plus @command{gcc}
6914 can generate code that is faster than @command{g77}.
6916 Version 0.5.18 of @command{g77} offered default
6917 settings and options, via patches to the @command{gcc}
6918 back end, that allow for better program speed, though
6919 some of these improvements also affected the performance
6920 of programs translated by @command{f2c} and then compiled
6921 by @command{g77}'s version of @command{gcc}.
6923 Version 0.5.20 of @command{g77} offers further performance
6924 improvements, at least one of which (alias analysis) is
6925 not generally applicable to @command{f2c} (though @command{f2c}
6926 could presumably be changed to also take advantage of
6927 this new capability of the @command{gcc} back end, assuming
6928 this is made available in an upcoming release of @command{gcc}).
6930 @node Ease of Debugging
6931 @subsection Ease of Debugging
6933 Because @command{g77} compiles directly to assembler code like @command{gcc},
6934 instead of translating to an intermediate language (C) as does @command{f2c},
6935 support for debugging can be better for @command{g77} than @command{f2c}.
6937 However, although @command{g77} might be somewhat more ``native'' in terms of
6938 debugging support than @command{f2c} plus @command{gcc}, there still are a lot
6939 of things ``not quite right''.
6940 Many of the important ones should be resolved in the near future.
6942 For example, @command{g77} doesn't have to worry about reserved names
6943 like @command{f2c} does.
6944 Given @samp{FOR = WHILE}, @command{f2c} must necessarily
6945 translate this to something @emph{other} than
6946 @samp{for = while;}, because C reserves those words.
6948 However, @command{g77} does still uses things like an extra level of indirection
6949 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
6950 yet support multiple entry points.
6952 Another example is that, given
6960 the @command{g77} user should be able to access the variables directly, by name,
6961 without having to traverse C-like structures and unions, while @command{f2c}
6962 is unlikely to ever offer this ability (due to limitations in the
6965 However, due to apparent bugs in the back end, @command{g77} currently doesn't
6966 take advantage of this facility at all---it doesn't emit any debugging
6967 information for @code{COMMON} and @code{EQUIVALENCE} areas,
6968 other than information
6969 on the array of @code{char} it creates (and, in the case
6970 of local @code{EQUIVALENCE}, names) for each such area.
6972 Yet another example is arrays.
6973 @command{g77} represents them to the debugger
6974 using the same ``dimensionality'' as in the source code, while @command{f2c}
6975 must necessarily convert them all to one-dimensional arrays to fit
6976 into the confines of the C language.
6977 However, the level of support
6978 offered by debuggers for interactive Fortran-style access to arrays
6979 as compiled by @command{g77} can vary widely.
6980 In some cases, it can actually
6981 be an advantage that @command{f2c} converts everything to widely supported
6984 In fairness, @command{g77} could do many of the things @command{f2c} does
6985 to get things working at least as well as @command{f2c}---for now,
6986 the developers prefer making @command{g77} work the
6987 way they think it is supposed to, and finding help improving the
6988 other products (the back end of @command{gcc}; @command{gdb}; and so on)
6989 to get things working properly.
6991 @node Character and Hollerith Constants
6992 @subsection Character and Hollerith Constants
6993 @cindex character constants
6994 @cindex constants, character
6995 @cindex Hollerith constants
6996 @cindex constants, Hollerith
6997 @cindex trailing null byte
6998 @cindex null byte, trailing
6999 @cindex zero byte, trailing
7001 To avoid the extensive hassle that would be needed to avoid this,
7002 @command{f2c} uses C character constants to encode character and Hollerith
7004 That means a constant like @samp{'HELLO'} is translated to
7005 @samp{"hello"} in C, which further means that an extra null byte is
7006 present at the end of the constant.
7007 This null byte is superfluous.
7009 @command{g77} does not generate such null bytes.
7010 This represents significant
7011 savings of resources, such as on systems where @file{/dev/null} or
7012 @file{/dev/zero} represent bottlenecks in the systems' performance,
7013 because @command{g77} simply asks for fewer zeros from the operating
7014 system than @command{f2c}.
7015 (Avoiding spurious use of zero bytes, each byte typically have
7016 eight zero bits, also reduces the liabilities in case
7017 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
7019 @node Block Data and Libraries
7020 @section Block Data and Libraries
7021 @cindex block data and libraries
7022 @cindex BLOCK DATA statement
7023 @cindex statements, BLOCK DATA
7024 @cindex libraries, containing BLOCK DATA
7025 @cindex f2c compatibility
7026 @cindex compatibility, f2c
7028 To ensure that block data program units are linked, especially a concern
7029 when they are put into libraries, give each one a name (as in
7030 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
7031 statement in every program unit that uses any common block
7032 initialized by the corresponding @code{BLOCK DATA}.
7033 @command{g77} currently compiles a @code{BLOCK DATA} as if it were a
7035 that is, it generates an actual procedure having the appropriate name.
7036 The procedure does nothing but return immediately if it happens to be
7038 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
7039 same program unit, @command{g77} assumes there exists a @samp{BLOCK DATA FOO}
7040 in the program and ensures that by generating a
7041 reference to it so the linker will make sure it is present.
7042 (Specifically, @command{g77} outputs in the data section a static pointer to the
7043 external name @samp{FOO}.)
7045 The implementation @command{g77} currently uses to make this work is
7046 one of the few things not compatible with @command{f2c} as currently
7048 @command{f2c} currently does nothing with @samp{EXTERNAL FOO} except
7049 issue a warning that @samp{FOO} is not otherwise referenced,
7050 and, for @samp{BLOCK DATA FOO},
7051 @command{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
7052 The upshot is that you shouldn't mix @command{f2c} and @command{g77} in
7053 this particular case.
7054 If you use @command{f2c} to compile @samp{BLOCK DATA FOO},
7055 then any @command{g77}-compiled program unit that says @samp{EXTERNAL FOO}
7056 will result in an unresolved reference when linked.
7058 opposite, then @samp{FOO} might not be linked in under various
7059 circumstances (such as when @samp{FOO} is in a library, or you're
7060 using a ``clever'' linker---so clever, it produces a broken program
7061 with little or no warning by omitting initializations of global data
7062 because they are contained in unreferenced procedures).
7064 The changes you make to your code to make @command{g77} handle this situation,
7065 however, appear to be a widely portable way to handle it.
7066 That is, many systems permit it (as they should, since the
7067 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
7068 is a block data program unit), and of the ones
7069 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
7070 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
7073 Here is the recommended approach to modifying a program containing
7074 a program unit such as the following:
7078 COMMON /VARS/ X, Y, Z
7079 DATA X, Y, Z / 3., 4., 5. /
7084 If the above program unit might be placed in a library module, then
7085 ensure that every program unit in every program that references that
7086 particular @code{COMMON} area uses the @code{EXTERNAL} statement
7087 to force the area to be initialized.
7089 For example, change a program unit that starts with
7092 INTEGER FUNCTION CURX()
7093 COMMON /VARS/ X, Y, Z
7099 so that it uses the @code{EXTERNAL} statement, as in:
7102 INTEGER FUNCTION CURX()
7103 COMMON /VARS/ X, Y, Z
7110 That way, @samp{CURX} is compiled by @command{g77} (and many other
7111 compilers) so that the linker knows it must include @samp{FOO},
7112 the @code{BLOCK DATA} program unit that sets the initial values
7113 for the variables in @samp{VAR}, in the executable program.
7117 @cindex DO statement
7118 @cindex statements, DO
7119 @cindex trips, number of
7120 @cindex number of trips
7122 The meaning of a @code{DO} loop in Fortran is precisely specified
7123 in the Fortran standard@dots{}and is quite different from what
7124 many programmers might expect.
7126 In particular, Fortran iterative @code{DO} loops are implemented as if
7127 the number of trips through the loop is calculated @emph{before}
7128 the loop is entered.
7130 The number of trips for a loop is calculated from the @var{start},
7131 @var{end}, and @var{increment} values specified in a statement such as:
7134 DO @var{iter} = @var{start}, @var{end}, @var{increment}
7138 The trip count is evaluated using a fairly simple formula
7139 based on the three values following the @samp{=} in the
7140 statement, and it is that trip count that is effectively
7141 decremented during each iteration of the loop.
7142 If, at the beginning of an iteration of the loop, the
7143 trip count is zero or negative, the loop terminates.
7144 The per-loop-iteration modifications to @var{iter} are not
7145 related to determining whether to terminate the loop.
7147 There are two important things to remember about the trip
7152 It can be @emph{negative}, in which case it is
7153 treated as if it was zero---meaning the loop is
7154 not executed at all.
7157 The type used to @emph{calculate} the trip count
7158 is the same type as @var{iter}, but the final
7159 calculation, and thus the type of the trip
7160 count itself, always is @code{INTEGER(KIND=1)}.
7163 These two items mean that there are loops that cannot
7164 be written in straightforward fashion using the Fortran @code{DO}.
7166 For example, on a system with the canonical 32-bit two's-complement
7167 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
7170 DO I = -2000000000, 2000000000
7174 Although the @var{start} and @var{end} values are well within
7175 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
7176 The expected trip count is 40000000001, which is outside
7177 the range of @code{INTEGER(KIND=1)} on many systems.
7179 Instead, the above loop should be constructed this way:
7184 IF (I .GT. 2000000000) EXIT
7191 The simple @code{DO} construct and the @code{EXIT} statement
7192 (used to leave the innermost loop)
7193 are F90 features that @command{g77} supports.
7195 Some Fortran compilers have buggy implementations of @code{DO},
7196 in that they don't follow the standard.
7197 They implement @code{DO} as a straightforward translation
7198 to what, in C, would be a @code{for} statement.
7199 Instead of creating a temporary variable to hold the trip count
7200 as calculated at run time, these compilers
7201 use the iteration variable @var{iter} to control
7202 whether the loop continues at each iteration.
7204 The bug in such an implementation shows up when the
7205 trip count is within the range of the type of @var{iter},
7206 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
7207 exceeds that range. For example:
7210 DO I = 2147483600, 2147483647
7214 A loop started by the above statement will work as implemented
7215 by @command{g77}, but the use, by some compilers, of a
7216 more C-like implementation akin to
7219 for (i = 2147483600; i <= 2147483647; ++i)
7223 produces a loop that does not terminate, because @samp{i}
7224 can never be greater than 2147483647, since incrementing it
7225 beyond that value overflows @samp{i}, setting it to -2147483648.
7226 This is a large, negative number that still is less than 2147483647.
7228 Another example of unexpected behavior of @code{DO} involves
7229 using a nonintegral iteration variable @var{iter}, that is,
7230 a @code{REAL} variable.
7231 Consider the following program:
7234 DATA BEGIN, END, STEP /.1, .31, .007/
7235 DO 10 R = BEGIN, END, STEP
7236 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
7240 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
7245 A C-like view of @code{DO} would hold that the two ``exclamatory''
7246 @code{PRINT} statements are never executed.
7247 However, this is the output of running the above program
7248 as compiled by @command{g77} on a GNU/Linux ix86 system:
7260 .310000002 .LE. .310000002!!
7263 Note that one of the two checks in the program turned up
7264 an apparent violation of the programmer's expectation---yet,
7265 the loop is correctly implemented by @command{g77}, in that
7266 it has 30 iterations.
7267 This trip count of 30 is correct when evaluated using
7268 the floating-point representations for the @var{begin},
7269 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
7271 On other systems, an apparently more accurate trip count
7272 of 31 might result, but, nevertheless, @command{g77} is
7273 faithfully following the Fortran standard, and the result
7274 is not what the author of the sample program above
7275 apparently expected.
7276 (Such other systems might, for different values in the @code{DATA}
7277 statement, violate the other programmer's expectation,
7280 Due to this combination of imprecise representation
7281 of floating-point values and the often-misunderstood
7282 interpretation of @code{DO} by standard-conforming
7283 compilers such as @command{g77}, use of @code{DO} loops
7284 with @code{REAL} iteration
7285 variables is not recommended.
7286 Such use can be caught by specifying @option{-Wsurprising}.
7287 @xref{Warning Options}, for more information on this
7290 @node Working Programs
7291 @section Working Programs
7293 Getting Fortran programs to work in the first place can be
7294 quite a challenge---even when the programs already work on
7295 other systems, or when using other compilers.
7297 @command{g77} offers some facilities that might be useful for
7298 tracking down bugs in such programs.
7302 * Variables Assumed To Be Zero::
7303 * Variables Assumed To Be Saved::
7304 * Unwanted Variables::
7305 * Unused Arguments::
7306 * Surprising Interpretations of Code::
7307 * Aliasing Assumed To Work::
7308 * Output Assumed To Flush::
7309 * Large File Unit Numbers::
7310 * Floating-point precision::
7311 * Inconsistent Calling Sequences::
7315 @subsection Not My Type
7316 @cindex mistyped variables
7317 @cindex variables, mistyped
7318 @cindex mistyped functions
7319 @cindex functions, mistyped
7320 @cindex implicit typing
7322 A fruitful source of bugs in Fortran source code is use, or
7323 mis-use, of Fortran's implicit-typing feature, whereby the
7324 type of a variable, array, or function is determined by the
7325 first character of its name.
7327 Simple cases of this include statements like @samp{LOGX=9.227},
7328 without a statement such as @samp{REAL LOGX}.
7329 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
7330 type, with the result of the assignment being that it is given
7333 More involved cases include a function that is defined starting
7334 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
7335 Any caller of this function that does not also declare @samp{IPS}
7336 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
7337 is likely to assume it returns
7338 @code{INTEGER}, or some other type, leading to invalid results
7339 or even program crashes.
7341 The @option{-Wimplicit} option might catch failures to
7342 properly specify the types of
7343 variables, arrays, and functions in the code.
7345 However, in code that makes heavy use of Fortran's
7346 implicit-typing facility, this option might produce so
7347 many warnings about cases that are working, it would be
7348 hard to find the one or two that represent bugs.
7349 This is why so many experienced Fortran programmers strongly
7350 recommend widespread use of the @code{IMPLICIT NONE} statement,
7351 despite it not being standard FORTRAN 77, to completely turn
7352 off implicit typing.
7353 (@command{g77} supports @code{IMPLICIT NONE}, as do almost all
7354 FORTRAN 77 compilers.)
7356 Note that @option{-Wimplicit} catches only implicit typing of
7358 It does not catch implicit typing of expressions such
7360 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
7361 is equivalent to @samp{X**0}, due to the way Fortran expressions
7362 are given types and then evaluated.
7363 (In this particular case, the programmer probably wanted
7366 @node Variables Assumed To Be Zero
7367 @subsection Variables Assumed To Be Zero
7368 @cindex zero-initialized variables
7369 @cindex variables, assumed to be zero
7370 @cindex uninitialized variables
7372 Many Fortran programs were developed on systems that provided
7373 automatic initialization of all, or some, variables and arrays
7375 As a result, many of these programs depend, sometimes
7376 inadvertently, on this behavior, though to do so violates
7377 the Fortran standards.
7379 You can ask @command{g77} for this behavior by specifying the
7380 @option{-finit-local-zero} option when compiling Fortran code.
7381 (You might want to specify @option{-fno-automatic} as well,
7382 to avoid code-size inflation for non-optimized compilations.)
7384 Note that a program that works better when compiled with the
7385 @option{-finit-local-zero} option
7386 is almost certainly depending on a particular system's,
7387 or compiler's, tendency to initialize some variables to zero.
7388 It might be worthwhile finding such cases and fixing them,
7389 using techniques such as compiling with the @option{-O -Wuninitialized}
7390 options using @command{g77}.
7392 @node Variables Assumed To Be Saved
7393 @subsection Variables Assumed To Be Saved
7394 @cindex variables, retaining values across calls
7395 @cindex saved variables
7396 @cindex static variables
7398 Many Fortran programs were developed on systems that
7399 saved the values of all, or some, variables and arrays
7400 across procedure calls.
7401 As a result, many of these programs depend, sometimes
7402 inadvertently, on being able to assign a value to a
7403 variable, perform a @code{RETURN} to a calling procedure,
7404 and, upon subsequent invocation, reference the previously
7405 assigned variable to obtain the value.
7407 They expect this despite not using the @code{SAVE} statement
7408 to specify that the value in a variable is expected to survive
7409 procedure returns and calls.
7410 Depending on variables and arrays to retain values across
7411 procedure calls without using @code{SAVE} to require it violates
7412 the Fortran standards.
7414 You can ask @command{g77} to assume @code{SAVE} is specified for all
7415 relevant (local) variables and arrays by using the
7416 @option{-fno-automatic} option.
7418 Note that a program that works better when compiled with the
7419 @option{-fno-automatic} option
7420 is almost certainly depending on not having to use
7421 the @code{SAVE} statement as required by the Fortran standard.
7422 It might be worthwhile finding such cases and fixing them,
7423 using techniques such as compiling with the @samp{-O -Wuninitialized}
7424 options using @command{g77}.
7426 @node Unwanted Variables
7427 @subsection Unwanted Variables
7429 The @option{-Wunused} option can find bugs involving
7430 implicit typing, sometimes
7431 more easily than using @option{-Wimplicit} in code that makes
7432 heavy use of implicit typing.
7433 An unused variable or array might indicate that the
7434 spelling for its declaration is different from that of
7437 Other than cases involving typos, unused variables rarely
7438 indicate actual bugs in a program.
7439 However, investigating such cases thoroughly has, on occasion,
7440 led to the discovery of code that had not been completely
7441 written---where the programmer wrote declarations as needed
7442 for the whole algorithm, wrote some or even most of the code
7443 for that algorithm, then got distracted and forgot that the
7444 job was not complete.
7446 @node Unused Arguments
7447 @subsection Unused Arguments
7448 @cindex unused arguments
7449 @cindex arguments, unused
7451 As with unused variables, It is possible that unused arguments
7452 to a procedure might indicate a bug.
7453 Compile with @samp{-W -Wunused} option to catch cases of
7456 Note that @option{-W} also enables warnings regarding overflow
7457 of floating-point constants under certain circumstances.
7459 @node Surprising Interpretations of Code
7460 @subsection Surprising Interpretations of Code
7462 The @option{-Wsurprising} option can help find bugs involving
7463 expression evaluation or in
7464 the way @code{DO} loops with non-integral iteration variables
7466 Cases found by this option might indicate a difference of
7467 interpretation between the author of the code involved, and
7468 a standard-conforming compiler such as @command{g77}.
7469 Such a difference might produce actual bugs.
7471 In any case, changing the code to explicitly do what the
7472 programmer might have expected it to do, so @command{g77} and
7473 other compilers are more likely to follow the programmer's
7474 expectations, might be worthwhile, especially if such changes
7475 make the program work better.
7477 @node Aliasing Assumed To Work
7478 @subsection Aliasing Assumed To Work
7479 @cindex -falias-check option
7480 @cindex options, -falias-check
7481 @cindex -fargument-alias option
7482 @cindex options, -fargument-alias
7483 @cindex -fargument-noalias option
7484 @cindex options, -fargument-noalias
7485 @cindex -fno-argument-noalias-global option
7486 @cindex options, -fno-argument-noalias-global
7488 @cindex anti-aliasing
7489 @cindex overlapping arguments
7491 @cindex association, storage
7492 @cindex storage association
7493 @cindex scheduling of reads and writes
7494 @cindex reads and writes, scheduling
7496 The @option{-falias-check}, @option{-fargument-alias},
7497 @option{-fargument-noalias},
7498 and @option{-fno-argument-noalias-global} options,
7499 introduced in version 0.5.20 and
7500 @command{g77}'s version 2.7.2.2.f.2 of @command{gcc},
7501 were withdrawn as of @command{g77} version 0.5.23
7502 due to their not being supported by @command{gcc} version 2.8.
7504 These options control the assumptions regarding aliasing
7505 (overlapping) of writes and reads to main memory (core) made
7506 by the @command{gcc} back end.
7508 The information below still is useful, but applies to
7509 only those versions of @command{g77} that support the
7510 alias analysis implied by support for these options.
7512 These options are effective only when compiling with @option{-O}
7513 (specifying any level other than @option{-O0})
7514 or with @option{-falias-check}.
7516 The default for Fortran code is @option{-fargument-noalias-global}.
7517 (The default for C code and code written in other C-based languages
7518 is @option{-fargument-alias}.
7519 These defaults apply regardless of whether you use @command{g77} or
7520 @command{gcc} to compile your code.)
7522 Note that, on some systems, compiling with @option{-fforce-addr} in
7523 effect can produce more optimal code when the default aliasing
7524 options are in effect (and when optimization is enabled).
7526 If your program is not working when compiled with optimization,
7527 it is possible it is violating the Fortran standards (77 and 90)
7528 by relying on the ability to ``safely'' modify variables and
7529 arrays that are aliased, via procedure calls, to other variables
7530 and arrays, without using @code{EQUIVALENCE} to explicitly
7531 set up this kind of aliasing.
7533 (The FORTRAN 77 standard's prohibition of this sort of
7534 overlap, generally referred to therein as ``storage
7535 assocation'', appears in Sections 15.9.3.6.
7536 This prohibition allows implementations, such as @command{g77},
7537 to, for example, implement the passing of procedures and
7538 even values in @code{COMMON} via copy operations into local,
7539 perhaps more efficiently accessed temporaries at entry to a
7540 procedure, and, where appropriate, via copy operations back
7541 out to their original locations in memory at exit from that
7542 procedure, without having to take into consideration the
7543 order in which the local copies are updated by the code,
7544 among other things.)
7546 To test this hypothesis, try compiling your program with
7547 the @option{-fargument-alias} option, which causes the
7548 compiler to revert to assumptions essentially the same as
7549 made by versions of @command{g77} prior to 0.5.20.
7551 If the program works using this option, that strongly suggests
7552 that the bug is in your program.
7553 Finding and fixing the bug(s) should result in a program that
7554 is more standard-conforming and that can be compiled by @command{g77}
7555 in a way that results in a faster executable.
7557 (You might want to try compiling with @option{-fargument-noalias},
7558 a kind of half-way point, to see if the problem is limited to
7559 aliasing between dummy arguments and @code{COMMON} variables---this
7560 option assumes that such aliasing is not done, while still allowing
7561 aliasing among dummy arguments.)
7563 An example of aliasing that is invalid according to the standards
7564 is shown in the following program, which might @emph{not} produce
7565 the expected results when executed:
7573 SUBROUTINE FOO(J, K)
7580 The above program attempts to use the temporary aliasing of the
7581 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
7582 pathological behavior---the simultaneous changing of the values
7583 of @emph{both} @samp{J} and @samp{K} when either one of them
7586 The programmer likely expects the program to print these values:
7593 However, since the program is not standard-conforming, an
7594 implementation's behavior when running it is undefined, because
7595 subroutine @samp{FOO} modifies at least one of the arguments,
7596 and they are aliased with each other.
7597 (Even if one of the assignment statements was deleted, the
7598 program would still violate these rules.
7599 This kind of on-the-fly aliasing is permitted by the standard
7600 only when none of the aliased items are defined, or written,
7601 while the aliasing is in effect.)
7603 As a practical example, an optimizing compiler might schedule
7604 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
7605 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
7606 resulting in the following output:
7613 Essentially, compilers are promised (by the standard and, therefore,
7614 by programmers who write code they claim to be standard-conforming)
7615 that if they cannot detect aliasing via static analysis of a single
7616 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
7617 such aliasing exists.
7618 In such cases, compilers are free to assume that an assignment to
7619 one variable will not change the value of another variable, allowing
7620 it to avoid generating code to re-read the value of the other
7621 variable, to re-schedule reads and writes, and so on, to produce
7622 a faster executable.
7624 The same promise holds true for arrays (as seen by the called
7625 procedure)---an element of one dummy array cannot be aliased
7626 with, or overlap, any element of another dummy array or be
7627 in a @code{COMMON} area known to the procedure.
7629 (These restrictions apply only when the procedure defines, or
7630 writes to, one of the aliased variables or arrays.)
7632 Unfortunately, there is no way to find @emph{all} possible cases of
7633 violations of the prohibitions against aliasing in Fortran code.
7634 Static analysis is certainly imperfect, as is run-time analysis,
7635 since neither can catch all violations.
7636 (Static analysis can catch all likely violations, and some that
7637 might never actually happen, while run-time analysis can catch
7638 only those violations that actually happen during a particular run.
7639 Neither approach can cope with programs mixing Fortran code with
7640 routines written in other languages, however.)
7642 Currently, @command{g77} provides neither static nor run-time facilities
7643 to detect any cases of this problem, although other products might.
7644 Run-time facilities are more likely to be offered by future
7645 versions of @command{g77}, though patches improving @command{g77} so that
7646 it provides either form of detection are welcome.
7648 @node Output Assumed To Flush
7649 @subsection Output Assumed To Flush
7650 @cindex ALWAYS_FLUSH
7651 @cindex synchronous write errors
7653 @cindex flushing output
7655 @cindex I/O, flushing
7656 @cindex output, flushing
7657 @cindex writes, flushing
7659 @cindex network file system
7661 For several versions prior to 0.5.20, @command{g77} configured its
7662 version of the @code{libf2c} run-time library so that one of
7663 its configuration macros, @code{ALWAYS_FLUSH}, was defined.
7665 This was done as a result of a belief that many programs expected
7666 output to be flushed to the operating system (under UNIX, via
7667 the @code{fflush()} library call) with the result that errors,
7668 such as disk full, would be immediately flagged via the
7669 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
7671 Because of the adverse effects this approach had on the performance
7672 of many programs, @command{g77} no longer configures @code{libf2c}
7673 (now named @code{libg2c} in its @command{g77} incarnation)
7674 to always flush output.
7676 If your program depends on this behavior, either insert the
7677 appropriate @samp{CALL FLUSH} statements, or modify the sources
7678 to the @code{libg2c}, rebuild and reinstall @command{g77}, and
7679 relink your programs with the modified library.
7681 (Ideally, @code{libg2c} would offer the choice at run-time, so
7682 that a compile-time option to @command{g77} or @command{f2c} could
7683 result in generating the appropriate calls to flushing or
7684 non-flushing library routines.)
7686 Some Fortran programs require output
7687 (writes) to be flushed to the operating system (under UNIX,
7688 via the @code{fflush()} library call) so that errors,
7689 such as disk full, are immediately flagged via the relevant
7690 @code{ERR=} and @code{IOSTAT=} mechanism, instead of such
7691 errors being flagged later as subsequent writes occur, forcing
7692 the previously written data to disk, or when the file is
7695 Essentially, the difference can be viewed as synchronous error
7696 reporting (immediate flagging of errors during writes) versus
7697 asynchronous, or, more precisely, buffered error reporting
7698 (detection of errors might be delayed).
7700 @code{libg2c} supports flagging write errors immediately when
7701 it is built with the @code{ALWAYS_FLUSH} macro defined.
7702 This results in a @code{libg2c} that runs slower, sometimes
7703 quite a bit slower, under certain circumstances---for example,
7704 accessing files via the networked file system NFS---but the
7705 effect can be more reliable, robust file I/O.
7707 If you know that Fortran programs requiring this level of precision
7708 of error reporting are to be compiled using the
7709 version of @command{g77} you are building, you might wish to
7710 modify the @command{g77} source tree so that the version of
7711 @code{libg2c} is built with the @code{ALWAYS_FLUSH} macro
7712 defined, enabling this behavior.
7714 To do this, find this line in @file{@value{path-libf2c}/f2c.h} in
7715 your @command{g77} source tree:
7718 /* #define ALWAYS_FLUSH */
7721 Remove the leading @samp{/*@w{ }},
7722 so the line begins with @samp{#define},
7723 and the trailing @samp{@w{ }*/}.
7725 Then build or rebuild @command{g77} as appropriate.
7727 @node Large File Unit Numbers
7728 @subsection Large File Unit Numbers
7730 @cindex unit numbers
7731 @cindex maximum unit number
7732 @cindex illegal unit number
7733 @cindex increasing maximum unit number
7735 If your program crashes at run time with a message including
7736 the text @samp{illegal unit number}, that probably is
7737 a message from the run-time library, @code{libg2c}.
7739 The message means that your program has attempted to use a
7740 file unit number that is out of the range accepted by
7742 Normally, this range is 0 through 99, and the high end
7743 of the range is controlled by a @code{libg2c} source-file
7744 macro named @code{MXUNIT}.
7746 If you can easily change your program to use unit numbers
7747 in the range 0 through 99, you should do so.
7749 As distributed, whether as part of @command{f2c} or @command{g77},
7750 @code{libf2c} accepts file unit numbers only in the range
7752 For example, a statement such as @samp{WRITE (UNIT=100)} causes
7753 a run-time crash in @code{libf2c}, because the unit number,
7754 100, is out of range.
7756 If you know that Fortran programs at your installation require
7757 the use of unit numbers higher than 99, you can change the
7758 value of the @code{MXUNIT} macro, which represents the maximum unit
7759 number, to an appropriately higher value.
7761 To do this, edit the file @file{@value{path-libf2c}/libI77/fio.h} in your
7762 @command{g77} source tree, changing the following line:
7768 Change the line so that the value of @code{MXUNIT} is defined to be
7769 at least one @emph{greater} than the maximum unit number used by
7770 the Fortran programs on your system.
7772 (For example, a program that does @samp{WRITE (UNIT=255)} would require
7773 @code{MXUNIT} set to at least 256 to avoid crashing.)
7775 Then build or rebuild @command{g77} as appropriate.
7777 @emph{Note:} Changing this macro has @emph{no} effect on other limits
7778 your system might place on the number of files open at the same time.
7779 That is, the macro might allow a program to do @samp{WRITE (UNIT=100)},
7780 but the library and operating system underlying @code{libf2c} might
7781 disallow it if many other files have already been opened (via @code{OPEN} or
7782 implicitly via @code{READ}, @code{WRITE}, and so on).
7783 Information on how to increase these other limits should be found
7784 in your system's documentation.
7786 @node Floating-point precision
7787 @subsection Floating-point precision
7789 @cindex IEEE 754 conformance
7790 @cindex conformance, IEEE 754
7791 @cindex floating-point, precision
7792 @cindex ix86 floating-point
7793 @cindex x86 floating-point
7794 If your program depends on exact IEEE 754 floating-point handling it may
7795 help on some systems---specifically x86 or m68k hardware---to use
7796 the @option{-ffloat-store} option or to reset the precision flag on the
7797 floating-point unit.
7798 @xref{Optimize Options}.
7800 However, it might be better simply to put the FPU into double precision
7801 mode and not take the performance hit of @option{-ffloat-store}. On x86
7802 and m68k GNU systems you can do this with a technique similar to that
7803 for turning on floating-point exceptions
7804 (@pxref{Floating-point Exception Handling}).
7805 The control word could be set to double precision by some code like this
7808 #include <fpu_control.h>
7810 fpu_control_t cw = (_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE;
7814 (It is not clear whether this has any effect on the operation of the GNU
7815 maths library, but we have no evidence of it causing trouble.)
7817 Some targets (such as the Alpha) may need special options for full IEEE
7819 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and Porting GNU CC}.
7821 @node Inconsistent Calling Sequences
7822 @subsection Inconsistent Calling Sequences
7825 @cindex floating-point, errors
7826 @cindex ix86 FPU stack
7827 @cindex x86 FPU stack
7828 Code containing inconsistent calling sequences in the same file is
7829 normally rejected---see @ref{GLOBALS}.
7830 (Use, say, @command{ftnchek} to ensure
7831 consistency across source files.
7832 @xref{f2c Skeletons and Prototypes,,
7833 Generating Skeletons and Prototypes with @command{f2c}}.)
7835 Mysterious errors, which may appear to be code generation problems, can
7836 appear specifically on the x86 architecture with some such
7837 inconsistencies. On x86 hardware, floating-point return values of
7838 functions are placed on the floating-point unit's register stack, not
7839 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
7840 @code{FUNCTION} as some other sort of procedure, or vice versa,
7841 scrambles the floating-point stack. This may break unrelated code
7842 executed later. Similarly if, say, external C routines are written
7845 @node Overly Convenient Options
7846 @section Overly Convenient Command-line Options
7847 @cindex overly convenient options
7848 @cindex options, overly convenient
7850 These options should be used only as a quick-and-dirty way to determine
7851 how well your program will run under different compilation models
7852 without having to change the source.
7853 Some are more problematic
7854 than others, depending on how portable and maintainable you want the
7855 program to be (and, of course, whether you are allowed to change it
7858 You should not continue to use these command-line options to compile
7859 a given program, but rather should make changes to the source code:
7862 @cindex -finit-local-zero option
7863 @cindex options, -finit-local-zero
7864 @item -finit-local-zero
7865 (This option specifies that any uninitialized local variables
7866 and arrays have default initialization to binary zeros.)
7868 Many other compilers do this automatically, which means lots of
7869 Fortran code developed with those compilers depends on it.
7871 It is safer (and probably
7872 would produce a faster program) to find the variables and arrays that
7873 need such initialization and provide it explicitly via @code{DATA}, so that
7874 @option{-finit-local-zero} is not needed.
7876 Consider using @option{-Wuninitialized} (which requires @option{-O}) to
7877 find likely candidates, but
7878 do not specify @option{-finit-local-zero} or @option{-fno-automatic},
7879 or this technique won't work.
7881 @cindex -fno-automatic option
7882 @cindex options, -fno-automatic
7883 @item -fno-automatic
7884 (This option specifies that all local variables and arrays
7885 are to be treated as if they were named in @code{SAVE} statements.)
7887 Many other compilers do this automatically, which means lots of
7888 Fortran code developed with those compilers depends on it.
7890 The effect of this is that all non-automatic variables and arrays
7891 are made static, that is, not placed on the stack or in heap storage.
7892 This might cause a buggy program to appear to work better.
7893 If so, rather than relying on this command-line option (and hoping all
7894 compilers provide the equivalent one), add @code{SAVE}
7895 statements to some or all program unit sources, as appropriate.
7896 Consider using @option{-Wuninitialized} (which requires @option{-O})
7897 to find likely candidates, but
7898 do not specify @option{-finit-local-zero} or @option{-fno-automatic},
7899 or this technique won't work.
7901 The default is @option{-fautomatic}, which tells @command{g77} to try
7902 and put variables and arrays on the stack (or in fast registers)
7903 where possible and reasonable.
7904 This tends to make programs faster.
7906 @cindex automatic arrays
7907 @cindex arrays, automatic
7908 @emph{Note:} Automatic variables and arrays are not affected
7910 These are variables and arrays that are @emph{necessarily} automatic,
7911 either due to explicit statements, or due to the way they are
7913 Examples include local variables and arrays not given the
7914 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
7915 and local arrays declared with non-constant bounds (automatic
7917 Currently, @command{g77} supports only automatic arrays, not
7918 @code{RECURSIVE} procedures or other means of explicitly
7919 specifying that variables or arrays are automatic.
7921 @cindex -f@var{group}-intrinsics-hide option
7922 @cindex options, -f@var{group}-intrinsics-hide
7923 @item -f@var{group}-intrinsics-hide
7924 Change the source code to use @code{EXTERNAL} for any external procedure
7925 that might be the name of an intrinsic.
7926 It is easy to find these using @option{-f@var{group}-intrinsics-disable}.
7929 @node Faster Programs
7930 @section Faster Programs
7931 @cindex speed, of programs
7932 @cindex programs, speeding up
7934 Aside from the usual @command{gcc} options, such as @option{-O},
7935 @option{-ffast-math}, and so on, consider trying some of the
7936 following approaches to speed up your program (once you get
7941 * Prefer Automatic Uninitialized Variables::
7942 * Avoid f2c Compatibility::
7943 * Use Submodel Options::
7947 @subsection Aligned Data
7949 @cindex data, aligned
7950 @cindex stack, aligned
7951 @cindex aligned data
7952 @cindex aligned stack
7953 @cindex Pentium optimizations
7954 @cindex optimization, for Pentium
7956 On some systems, such as those with Pentium Pro CPUs, programs
7957 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
7958 might run much slower
7959 than possible due to the compiler not aligning these 64-bit
7960 values to 64-bit boundaries in memory.
7961 (The effect also is present, though
7962 to a lesser extent, on the 586 (Pentium) architecture.)
7964 The Intel x86 architecture generally ensures that these programs will
7965 work on all its implementations,
7966 but particular implementations (such as Pentium Pro)
7967 perform better with more strict alignment.
7968 (Such behavior isn't unique to the Intel x86 architecture.)
7969 Other architectures might @emph{demand} 64-bit alignment
7972 There are a variety of approaches to use to address this problem:
7976 @cindex @code{COMMON} layout
7977 @cindex layout of @code{COMMON} blocks
7978 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
7979 that the variables and arrays with the widest alignment
7980 guidelines come first.
7982 For example, on most systems, this would mean placing
7983 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
7984 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
7985 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
7986 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
7987 and @code{INTEGER(KIND=3)} entities.
7989 The reason to use such placement is it makes it more likely
7990 that your data will be aligned properly, without requiring
7991 you to do detailed analysis of each aggregate (@code{COMMON}
7992 and @code{EQUIVALENCE}) area.
7994 Specifically, on systems where the above guidelines are
7995 appropriate, placing @code{CHARACTER} entities before
7996 @code{REAL(KIND=2)} entities can work just as well,
7997 but only if the number of bytes occupied by the @code{CHARACTER}
7998 entities is divisible by the recommended alignment for
7999 @code{REAL(KIND=2)}.
8001 By ordering the placement of entities in aggregate
8002 areas according to the simple guidelines above, you
8003 avoid having to carefully count the number of bytes
8004 occupied by each entity to determine whether the
8005 actual alignment of each subsequent entity meets the
8006 alignment guidelines for the type of that entity.
8008 If you don't ensure correct alignment of @code{COMMON} elements, the
8009 compiler may be forced by some systems to violate the Fortran semantics by
8010 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
8011 If the unfortunate practice is employed of overlaying different types of
8012 data in the @code{COMMON} block, the different variants
8013 of this block may become misaligned with respect to each other.
8014 Even if your platform doesn't require strict alignment,
8015 @code{COMMON} should be laid out as above for portability.
8016 (Unfortunately the FORTRAN 77 standard didn't anticipate this
8017 possible requirement, which is compiler-independent on a given platform.)
8020 @cindex -malign-double option
8021 @cindex options, -malign-double
8022 Use the (x86-specific) @option{-malign-double} option when compiling
8023 programs for the Pentium and Pentium Pro architectures (called 586
8024 and 686 in the @command{gcc} configuration subsystem).
8025 The warning about this in the @command{gcc} manual isn't
8026 generally relevant to Fortran,
8027 but using it will force @code{COMMON} to be padded if necessary to align
8028 @code{DOUBLE PRECISION} data.
8030 When @code{DOUBLE PRECISION} data is forcibly aligned
8031 in @code{COMMON} by @command{g77} due to specifying @option{-malign-double},
8032 @command{g77} issues a warning about the need to
8035 In this case, each and every program unit that uses
8036 the same @code{COMMON} area
8037 must specify the same layout of variables and their types
8039 and be compiled with @option{-malign-double} as well.
8040 @command{g77} will issue warnings in each case,
8041 but as long as every program unit using that area
8042 is compiled with the same warnings,
8043 the resulting object files should work when linked together
8044 unless the program makes additional assumptions about
8045 @code{COMMON} area layouts that are outside the scope
8046 of the FORTRAN 77 standard,
8047 or uses @code{EQUIVALENCE} or different layouts
8048 in ways that assume no padding is ever inserted by the compiler.
8051 Ensure that @file{crt0.o} or @file{crt1.o}
8052 on your system guarantees a 64-bit
8053 aligned stack for @code{main()}.
8054 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
8055 but we don't know of any other x86 setups where it will be right.
8056 Read your system's documentation to determine if
8057 it is appropriate to upgrade to a more recent version
8058 to obtain the optimal alignment.
8061 Progress is being made on making this work
8062 ``out of the box'' on future versions of @command{g77},
8063 @command{gcc}, and some of the relevant operating systems
8064 (such as GNU/Linux).
8066 @cindex alignment testing
8067 @cindex testing alignment
8068 A package that tests the degree to which a Fortran compiler
8069 (such as @command{g77})
8070 aligns 64-bit floating-point variables and arrays
8071 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
8073 @node Prefer Automatic Uninitialized Variables
8074 @subsection Prefer Automatic Uninitialized Variables
8076 If you're using @option{-fno-automatic} already, you probably
8077 should change your code to allow compilation with @option{-fautomatic}
8078 (the default), to allow the program to run faster.
8080 Similarly, you should be able to use @option{-fno-init-local-zero}
8081 (the default) instead of @option{-finit-local-zero}.
8082 This is because it is rare that every variable affected by these
8083 options in a given program actually needs to
8086 For example, @option{-fno-automatic}, which effectively @code{SAVE}s
8087 every local non-automatic variable and array, affects even things like
8089 variables, which rarely need to be @code{SAVE}d, and this often reduces
8090 run-time performances.
8091 Similarly, @option{-fno-init-local-zero} forces such
8092 variables to be initialized to zero---when @code{SAVE}d (such as when
8093 @option{-fno-automatic}), this by itself generally affects only
8094 startup time for a program, but when not @code{SAVE}d,
8095 it can slow down the procedure every time it is called.
8097 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
8098 for information on the @option{-fno-automatic} and
8099 @option{-finit-local-zero} options and how to convert
8100 their use into selective changes in your own code.
8102 @node Avoid f2c Compatibility
8103 @subsection Avoid f2c Compatibility
8104 @cindex -fno-f2c option
8105 @cindex options, -fno-f2c
8106 @cindex @command{f2c} compatibility
8107 @cindex compatibility, @command{f2c}
8109 If you aren't linking with any code compiled using
8110 @command{f2c}, try using the @option{-fno-f2c} option when
8111 compiling @emph{all} the code in your program.
8112 (Note that @code{libf2c} is @emph{not} an example of code
8113 that is compiled using @command{f2c}---it is compiled by a C
8114 compiler, typically @command{gcc}.)
8116 @node Use Submodel Options
8117 @subsection Use Submodel Options
8120 Using an appropriate @option{-m} option to generate specific code for your
8121 CPU may be worthwhile, though it may mean the executable won't run on
8122 other versions of the CPU that don't support the same instruction set.
8123 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
8124 Porting GNU CC}. For instance on an x86 system the compiler might have
8125 been built---as shown by @samp{g77 -v}---for the target
8126 @samp{i386-pc-linux-gnu}, i.e.@: an @samp{i386} CPU@. In that case to
8127 generate code best optimized for a Pentium you could use the option
8128 @option{-march=pentium}.
8130 For recent CPUs that don't have explicit support in the released version
8131 of @command{gcc}, it @emph{might} still be possible to get improvements
8132 with certain @option{-m} options.
8134 @option{-fomit-frame-pointer} can help performance on x86 systems and
8135 others. It will, however, inhibit debugging on the systems on which it
8136 is not turned on anyway by @option{-O}.
8139 @chapter Known Causes of Trouble with GNU Fortran
8141 @cindex installation trouble
8142 @cindex known causes of trouble
8144 This section describes known problems that affect users of GNU Fortran.
8145 Most of these are not GNU Fortran bugs per se---if they were, we would
8147 But the result for a user might be like the result of a bug.
8149 Some of these problems are due to bugs in other software, some are
8150 missing features that are too much work to add, and some are places
8151 where people's opinions differ as to what is best.
8153 To find out about major bugs discovered in the current release and
8154 possible workarounds for them, see
8155 @uref{ftp://alpha.gnu.org/g77.plan}.
8157 (Note that some of this portion of the manual is lifted
8158 directly from the @command{gcc} manual, with minor modifications
8159 to tailor it to users of @command{g77}.
8160 Anytime a bug seems to have more to do with the @command{gcc}
8161 portion of @command{g77}, see
8162 @ref{Trouble,,Known Causes of Trouble with GNU CC,
8163 gcc,Using and Porting GNU CC}.)
8166 * But-bugs:: Bugs really in other programs or elsewhere.
8167 * Known Bugs:: Bugs known to be in this version of @command{g77}.
8168 * Missing Features:: Features we already know we want to add later.
8169 * Disappointments:: Regrettable things we can't change.
8170 * Non-bugs:: Things we think are right, but some others disagree.
8171 * Warnings and Errors:: Which problems in your code get warnings,
8172 and which get errors.
8176 @section Bugs Not In GNU Fortran
8179 These are bugs to which the maintainers often have to reply,
8180 ``but that isn't a bug in @command{g77}@dots{}''.
8181 Some of these already are fixed in new versions of other
8182 software; some still need to be fixed; some are problems
8183 with how @command{g77} is installed or is being used;
8184 some are the result of bad hardware that causes software
8185 to misbehave in sometimes bizarre ways;
8186 some just cannot be addressed at this time until more
8187 is known about the problem.
8189 Please don't re-report these bugs to the @command{g77} maintainers---if
8190 you must remind someone how important it is to you that the problem
8191 be fixed, talk to the people responsible for the other products
8192 identified below, but preferably only after you've tried the
8193 latest versions of those products.
8194 The @command{g77} maintainers have their hands full working on
8195 just fixing and improving @command{g77}, without serving as a
8196 clearinghouse for all bugs that happen to affect @command{g77}
8199 @xref{Collected Fortran Wisdom}, for information on behavior
8200 of Fortran programs, and the programs that compile them, that
8201 might be @emph{thought} to indicate bugs.
8204 * Signal 11 and Friends:: Strange behavior by any software.
8205 * Cannot Link Fortran Programs:: Unresolved references.
8206 * Large Common Blocks:: Problems on older GNU/Linux systems.
8207 * Debugger Problems:: When the debugger crashes.
8208 * NeXTStep Problems:: Misbehaving executables.
8209 * Stack Overflow:: More misbehaving executables.
8210 * Nothing Happens:: Less behaving executables.
8211 * Strange Behavior at Run Time:: Executables misbehaving due to
8212 bugs in your program.
8213 * Floating-point Errors:: The results look wrong, but@dots{}.
8216 @node Signal 11 and Friends
8217 @subsection Signal 11 and Friends
8219 @cindex hardware errors
8221 A whole variety of strange behaviors can occur when the
8222 software, or the way you are using the software,
8223 stresses the hardware in a way that triggers hardware bugs.
8224 This might seem hard to believe, but it happens frequently
8225 enough that there exist documents explaining in detail
8226 what the various causes of the problems are, what
8227 typical symptoms look like, and so on.
8229 Generally these problems are referred to in this document
8230 as ``signal 11'' crashes, because the Linux kernel, running
8231 on the most popular hardware (the Intel x86 line), often
8232 stresses the hardware more than other popular operating
8234 When hardware problems do occur under GNU/Linux on x86
8235 systems, these often manifest themselves as ``signal 11''
8236 problems, as illustrated by the following diagnostic:
8239 sh# @kbd{g77 myprog.f}
8240 gcc: Internal compiler error: program f771 got fatal signal 11
8244 It is @emph{very} important to remember that the above
8245 message is @emph{not} the only one that indicates a
8246 hardware problem, nor does it always indicate a hardware
8249 In particular, on systems other than those running the Linux
8250 kernel, the message might appear somewhat or very different,
8251 as it will if the error manifests itself while running a
8252 program other than the @command{g77} compiler.
8254 it will appear somewhat different when running your program,
8255 when running Emacs, and so on.
8257 How to cope with such problems is well beyond the scope
8260 However, users of Linux-based systems (such as GNU/Linux)
8261 should review @uref{http://www.bitwizard.nl/sig11/}, a source
8262 of detailed information on diagnosing hardware problems,
8263 by recognizing their common symptoms.
8265 Users of other operating systems and hardware might
8266 find this reference useful as well.
8267 If you know of similar material for another hardware/software
8268 combination, please let us know so we can consider including
8269 a reference to it in future versions of this manual.
8271 @node Cannot Link Fortran Programs
8272 @subsection Cannot Link Fortran Programs
8273 @cindex unresolved reference (various)
8274 @cindex linking error for user code
8276 @cindex @command{ld}, error linking user code
8277 @cindex @command{ld}, can't find strange names
8278 On some systems, perhaps just those with out-of-date (shared?)
8279 libraries, unresolved-reference errors happen when linking @command{g77}-compiled
8280 programs (which should be done using @command{g77}).
8282 If this happens to you, try appending @option{-lc} to the command you
8283 use to link the program, e.g. @samp{g77 foo.f -lc}.
8284 @command{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
8285 but it cannot also specify @option{-lc} because not all systems have a
8286 file named @file{libc.a}.
8288 It is unclear at this point whether there are legitimately installed
8289 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
8292 @cindex undefined reference (_main)
8293 @cindex linking error, user code
8294 @cindex @command{ld}, error linking user code
8296 @cindex @command{ld}, can't find @samp{_main}
8297 If your program doesn't link due to unresolved references to names
8298 like @samp{_main}, make sure you're using the @command{g77} command to do the
8299 link, since this command ensures that the necessary libraries are
8300 loaded by specifying @samp{-lg2c -lm} when it invokes the @command{gcc}
8301 command to do the actual link.
8302 (Use the @option{-v} option to discover
8303 more about what actually happens when you use the @command{g77} and @command{gcc}
8306 Also, try specifying @option{-lc} as the last item on the @command{g77}
8307 command line, in case that helps.
8309 @node Large Common Blocks
8310 @subsection Large Common Blocks
8311 @cindex common blocks, large
8312 @cindex large common blocks
8313 @cindex linking, errors
8314 @cindex @command{ld}, errors
8315 @cindex errors, linker
8316 On some older GNU/Linux systems, programs with common blocks larger
8317 than 16MB cannot be linked without some kind of error
8318 message being produced.
8320 This is a bug in older versions of @command{ld}, fixed in
8321 more recent versions of @code{binutils}, such as version 2.6.
8323 @node Debugger Problems
8324 @subsection Debugger Problems
8325 @cindex @command{gdb}, support
8326 @cindex support, @command{gdb}
8327 There are some known problems when using @command{gdb} on code
8328 compiled by @command{g77}.
8329 Inadequate investigation as of the release of 0.5.16 results in not
8330 knowing which products are the culprit, but @file{gdb-4.14} definitely
8331 crashes when, for example, an attempt is made to print the contents
8332 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
8333 machines, plus some others.
8334 Attempts to access assumed-size arrays are
8335 also known to crash recent versions of @command{gdb}.
8336 (@command{gdb}'s Fortran support was done for a different compiler
8337 and isn't properly compatible with @command{g77}.)
8339 @node NeXTStep Problems
8340 @subsection NeXTStep Problems
8341 @cindex NeXTStep problems
8343 @cindex segmentation violation
8344 Developers of Fortran code on NeXTStep (all architectures) have to
8345 watch out for the following problem when writing programs with
8346 large, statically allocated (i.e. non-stack based) data structures
8347 (common blocks, saved arrays).
8349 Due to the way the native loader (@file{/bin/ld}) lays out
8350 data structures in virtual memory, it is very easy to create an
8351 executable wherein the @samp{__DATA} segment overlaps (has addresses in
8352 common) with the @samp{UNIX STACK} segment.
8354 This leads to all sorts of trouble, from the executable simply not
8355 executing, to bus errors.
8356 The NeXTStep command line tool @command{ebadexec} points to
8357 the problem as follows:
8360 % @kbd{/bin/ebadexec a.out}
8361 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
8362 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
8363 STACK segment (truncated address = 0x400000 rounded size =
8364 0x3c00000) of executable file: a.out
8367 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
8370 This can be cured by assigning the @samp{__DATA} segment
8371 (virtual) addresses beyond the stack segment.
8373 estimate for this is from address 6000000 (hexadecimal) onwards---this
8374 has always worked for me [Toon Moene]:
8377 % @kbd{g77 -segaddr __DATA 6000000 test.f}
8378 % @kbd{ebadexec a.out}
8379 ebadexec: file: a.out appears to be executable
8383 Browsing through @file{@value{path-g77}/Makefile.in},
8384 you will find that the @code{f771} program itself also has to be
8385 linked with these flags---it has large statically allocated
8387 (Version 0.5.18 reduces this somewhat, but probably
8390 (The above item was contributed by Toon Moene
8391 (@email{toon@@moene.indiv.nluug.nl}).)
8393 @node Stack Overflow
8394 @subsection Stack Overflow
8395 @cindex stack, overflow
8396 @cindex segmentation violation
8397 @command{g77} code might fail at runtime (probably with a ``segmentation
8398 violation'') due to overflowing the stack.
8399 This happens most often on systems with an environment
8400 that provides substantially more heap space (for use
8401 when arbitrarily allocating and freeing memory) than stack
8404 Often this can be cured by
8405 increasing or removing your shell's limit on stack usage, typically
8406 using @kbd{limit stacksize} (in @command{csh} and derivatives) or
8407 @kbd{ulimit -s} (in @command{sh} and derivatives).
8409 Increasing the allowed stack size might, however, require
8410 changing some operating system or system configuration parameters.
8412 You might be able to work around the problem by compiling with the
8413 @option{-fno-automatic} option to reduce stack usage, probably at the
8416 @command{g77}, on most machines, puts many variables and arrays on the stack
8417 where possible, and can be configured (by changing
8418 @code{FFECOM_sizeMAXSTACKITEM} in @file{@value{path-g77}/com.c}) to force
8419 smaller-sized entities into static storage (saving
8420 on stack space) or permit larger-sized entities to be put on the
8421 stack (which can improve run-time performance, as it presents
8422 more opportunities for the GBE to optimize the generated code).
8424 @emph{Note:} Putting more variables and arrays on the stack
8425 might cause problems due to system-dependent limits on stack size.
8426 Also, the value of @code{FFECOM_sizeMAXSTACKITEM} has no
8427 effect on automatic variables and arrays.
8428 @xref{But-bugs}, for more information.
8429 @emph{Note:} While @code{libg2c} places a limit on the range
8430 of Fortran file-unit numbers, the underlying library and operating
8431 system might impose different kinds of limits.
8432 For example, some systems limit the number of files simultaneously
8433 open by a running program.
8434 Information on how to increase these limits should be found
8435 in your system's documentation.
8437 @cindex automatic arrays
8438 @cindex arrays, automatic
8439 However, if your program uses large automatic arrays
8440 (for example, has declarations like @samp{REAL A(N)} where
8441 @samp{A} is a local array and @samp{N} is a dummy or
8442 @code{COMMON} variable that can have a large value),
8443 neither use of @option{-fno-automatic},
8444 nor changing the cut-off point for @command{g77} for using the stack,
8445 will solve the problem by changing the placement of these
8446 large arrays, as they are @emph{necessarily} automatic.
8448 @command{g77} currently provides no means to specify that
8449 automatic arrays are to be allocated on the heap instead
8451 So, other than increasing the stack size, your best bet is to
8452 change your source code to avoid large automatic arrays.
8453 Methods for doing this currently are outside the scope of
8456 (@emph{Note:} If your system puts stack and heap space in the
8457 same memory area, such that they are effectively combined, then
8458 a stack overflow probably indicates a program that is either
8459 simply too large for the system, or buggy.)
8461 @node Nothing Happens
8462 @subsection Nothing Happens
8463 @cindex nothing happens
8464 @cindex naming programs
8465 @cindex @command{test} programs
8466 @cindex programs, @command{test}
8467 It is occasionally reported that a ``simple'' program,
8468 such as a ``Hello, World!'' program, does nothing when
8469 it is run, even though the compiler reported no errors,
8470 despite the program containing nothing other than a
8471 simple @code{PRINT} statement.
8473 This most often happens because the program has been
8474 compiled and linked on a UNIX system and named @command{test},
8475 though other names can lead to similarly unexpected
8476 run-time behavior on various systems.
8478 Essentially this problem boils down to giving
8479 your program a name that is already known to
8480 the shell you are using to identify some other program,
8481 which the shell continues to execute instead of your
8482 program when you invoke it via, for example:
8489 Under UNIX and many other system, a simple command name
8490 invokes a searching mechanism that might well not choose
8491 the program located in the current working directory if
8492 there is another alternative (such as the @command{test}
8493 command commonly installed on UNIX systems).
8495 The reliable way to invoke a program you just linked in
8496 the current directory under UNIX is to specify it using
8497 an explicit pathname, as in:
8505 Users who encounter this problem should take the time to
8506 read up on how their shell searches for commands, how to
8507 set their search path, and so on.
8508 The relevant UNIX commands to learn about include
8509 @command{man}, @command{info} (on GNU systems), @command{setenv} (or
8510 @command{set} and @command{env}), @command{which}, and @command{find}.
8512 @node Strange Behavior at Run Time
8513 @subsection Strange Behavior at Run Time
8514 @cindex segmentation violation
8516 @cindex overwritten data
8517 @cindex data, overwritten
8518 @command{g77} code might fail at runtime with ``segmentation violation'',
8519 ``bus error'', or even something as subtle as a procedure call
8520 overwriting a variable or array element that it is not supposed
8523 These can be symptoms of a wide variety of actual bugs that
8524 occurred earlier during the program's run, but manifested
8525 themselves as @emph{visible} problems some time later.
8527 Overflowing the bounds of an array---usually by writing beyond
8528 the end of it---is one of two kinds of bug that often occurs
8530 (Compile your code with the @option{-fbounds-check} option
8531 to catch many of these kinds of errors at program run time.)
8533 The other kind of bug is a mismatch between the actual arguments
8534 passed to a procedure and the dummy arguments as declared by that
8537 Both of these kinds of bugs, and some others as well, can be
8538 difficult to track down, because the bug can change its behavior,
8539 or even appear to not occur, when using a debugger.
8541 That is, these bugs can be quite sensitive to data, including
8542 data representing the placement of other data in memory (that is,
8543 pointers, such as the placement of stack frames in memory).
8545 @command{g77} now offers the
8546 ability to catch and report some of these problems at compile, link, or
8547 run time, such as by generating code to detect references to
8548 beyond the bounds of most arrays (except assumed-size arrays),
8549 and checking for agreement between calling and called procedures.
8550 Future improvements are likely to be made in the procedure-mismatch area,
8553 In the meantime, finding and fixing the programming
8554 bugs that lead to these behaviors is, ultimately, the user's
8555 responsibility, as difficult as that task can sometimes be.
8557 @cindex infinite spaces printed
8558 @cindex space, endless printing of
8559 @cindex libc, non-ANSI or non-default
8561 @cindex linking against non-standard library
8563 One runtime problem that has been observed might have a simple solution.
8564 If a formatted @code{WRITE} produces an endless stream of spaces, check
8565 that your program is linked against the correct version of the C library.
8566 The configuration process takes care to account for your
8567 system's normal @file{libc} not being ANSI-standard, which will
8568 otherwise cause this behaviour.
8569 If your system's default library is
8570 ANSI-standard and you subsequently link against a non-ANSI one, there
8571 might be problems such as this one.
8573 Specifically, on Solaris2 systems,
8574 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
8576 @node Floating-point Errors
8577 @subsection Floating-point Errors
8578 @cindex floating-point errors
8579 @cindex rounding errors
8580 @cindex inconsistent floating-point results
8581 @cindex results, inconsistent
8582 Some programs appear to produce inconsistent floating-point
8583 results compiled by @command{g77} versus by other compilers.
8585 Often the reason for this behavior is the fact that floating-point
8586 values are represented on almost all Fortran systems by
8587 @emph{approximations}, and these approximations are inexact
8588 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
8589 0.7, 0.8, 0.9, 1.1, and so on.
8590 Most Fortran systems, including all current ports of @command{g77},
8591 use binary arithmetic to represent these approximations.
8593 Therefore, the exact value of any floating-point approximation
8594 as manipulated by @command{g77}-compiled code is representable by
8595 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
8596 so on (just keep dividing by two) through the precision of the
8597 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
8598 @code{REAL(KIND=2)}), then multiplying the sum by a integral
8599 power of two (in Fortran, by @samp{2**N}) that typically is between
8600 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
8601 @code{REAL(KIND=2)}, then multiplying by -1 if the number
8604 So, a value like 0.2 is exactly represented in decimal---since
8605 it is a fraction, @samp{2/10}, with a denominator that is compatible
8606 with the base of the number system (base 10).
8607 However, @samp{2/10} cannot be represented by any finite number
8608 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
8609 be exactly represented in binary notation.
8611 (On the other hand, decimal notation can represent any binary
8612 number in a finite number of digits.
8613 Decimal notation cannot do so with ternary, or base-3,
8614 notation, which would represent floating-point numbers as
8615 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
8616 After all, no finite number of decimal digits can exactly
8617 represent @samp{1/3}.
8618 Fortunately, few systems use ternary notation.)
8620 Moreover, differences in the way run-time I/O libraries convert
8621 between these approximations and the decimal representation often
8622 used by programmers and the programs they write can result in
8623 apparent differences between results that do not actually exist,
8624 or exist to such a small degree that they usually are not worth
8627 For example, consider the following program:
8634 When compiled by @command{g77}, the above program might output
8635 @samp{0.20000003}, while another compiler might produce a
8636 executable that outputs @samp{0.2}.
8638 This particular difference is due to the fact that, currently,
8639 conversion of floating-point values by the @code{libg2c} library,
8640 used by @command{g77}, handles only double-precision values.
8642 Since @samp{0.2} in the program is a single-precision value, it
8643 is converted to double precision (still in binary notation)
8644 before being converted back to decimal.
8645 The conversion to binary appends @emph{binary} zero digits to the
8646 original value---which, again, is an inexact approximation of
8647 0.2---resulting in an approximation that is much less exact
8648 than is connoted by the use of double precision.
8650 (The appending of binary zero digits has essentially the same
8651 effect as taking a particular decimal approximation of
8652 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
8653 zeros to it, producing @samp{0.33333330000000000}.
8654 Treating the resulting decimal approximation as if it really
8655 had 18 or so digits of valid precision would make it seem
8656 a very poor approximation of @samp{1/3}.)
8658 As a result of converting the single-precision approximation
8659 to double precision by appending binary zeros, the conversion
8660 of the resulting double-precision
8661 value to decimal produces what looks like an incorrect
8662 result, when in fact the result is @emph{inexact}, and
8663 is probably no less inaccurate or imprecise an approximation
8664 of 0.2 than is produced by other compilers that happen to output
8665 the converted value as ``exactly'' @samp{0.2}.
8666 (Some compilers behave in a way that can make them appear
8667 to retain more accuracy across a conversion of a single-precision
8668 constant to double precision.
8669 @xref{Context-Sensitive Constants}, to see why
8670 this practice is illusory and even dangerous.)
8672 Note that a more exact approximation of the constant is
8673 computed when the program is changed to specify a
8674 double-precision constant:
8681 Future versions of @command{g77} and/or @code{libg2c} might convert
8682 single-precision values directly to decimal,
8683 instead of converting them to double precision first.
8684 This would tend to result in output that is more consistent
8685 with that produced by some other Fortran implementations.
8687 A useful source of information on floating-point computation is David
8688 Goldberg, `What Every Computer Scientist Should Know About
8689 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
8691 An online version is available at
8692 @uref{http://docs.sun.com/},
8693 and there is a supplemented version, in PostScript form, at
8694 @uref{http://www.validgh.com/goldberg/paper.ps}.
8696 Information related to the IEEE 754
8697 floating-point standard by a leading light can be found at
8698 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status/};
8699 see also slides from the short course referenced from
8700 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
8701 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
8702 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
8703 and library code for GNU/Linux x86 systems.
8705 The supplement to the PostScript-formatted Goldberg document,
8706 referenced above, is available in HTML format.
8707 See `Differences Among IEEE 754 Implementations' by Doug Priest,
8709 @uref{http://www.validgh.com/goldberg/addendum.html}.
8710 This document explores some of the issues surrounding computing
8711 of extended (80-bit) results on processors such as the x86,
8712 especially when those results are arbitrarily truncated
8713 to 32-bit or 64-bit values by the compiler
8716 @cindex spills of floating-point results
8717 @cindex 80-bit spills
8718 @cindex truncation, of floating-point values
8719 (@emph{Note:} @command{g77} specifically, and @command{gcc} generally,
8720 does arbitrarily truncate 80-bit results during spills
8722 It is not yet clear whether a future version of
8723 the GNU compiler suite will offer 80-bit spills
8724 as an option, or perhaps even as the default behavior.)
8726 @c xref would be different between editions:
8727 The GNU C library provides routines for controlling the FPU, and other
8728 documentation about this.
8730 @xref{Floating-point precision}, regarding IEEE 754 conformance.
8734 @node Missing Features
8735 @section Missing Features
8737 This section lists features we know are missing from @command{g77},
8738 and which we want to add someday.
8739 (There is no priority implied in the ordering below.)
8742 GNU Fortran language:
8743 * Better Source Model::
8744 * Fortran 90 Support::
8745 * Intrinsics in PARAMETER Statements::
8746 * Arbitrary Concatenation::
8747 * SELECT CASE on CHARACTER Type::
8748 * RECURSIVE Keyword::
8749 * Popular Non-standard Types::
8750 * Full Support for Compiler Types::
8751 * Array Bounds Expressions::
8752 * POINTER Statements::
8753 * Sensible Non-standard Constructs::
8754 * READONLY Keyword::
8756 * Expressions in FORMAT Statements::
8757 * Explicit Assembler Code::
8758 * Q Edit Descriptor::
8760 GNU Fortran dialects:
8761 * Old-style PARAMETER Statements::
8762 * TYPE and ACCEPT I/O Statements::
8763 * STRUCTURE UNION RECORD MAP::
8764 * OPEN CLOSE and INQUIRE Keywords::
8765 * ENCODE and DECODE::
8766 * AUTOMATIC Statement::
8767 * Suppressing Space Padding::
8768 * Fortran Preprocessor::
8769 * Bit Operations on Floating-point Data::
8770 * Really Ugly Character Assignments::
8774 * Floating-point Exception Handling::
8775 * Nonportable Conversions::
8776 * Large Automatic Arrays::
8777 * Support for Threads::
8778 * Increasing Precision/Range::
8779 * Enabling Debug Lines::
8783 * Gracefully Handle Sensible Bad Code::
8784 * Non-standard Conversions::
8785 * Non-standard Intrinsics::
8786 * Modifying DO Variable::
8787 * Better Pedantic Compilation::
8788 * Warn About Implicit Conversions::
8789 * Invalid Use of Hollerith Constant::
8790 * Dummy Array Without Dimensioning Dummy::
8791 * Invalid FORMAT Specifiers::
8792 * Ambiguous Dialects::
8794 * Informational Messages::
8796 Run-time facilities:
8797 * Uninitialized Variables at Run Time::
8798 * Portable Unformatted Files::
8799 * Better List-directed I/O::
8800 * Default to Console I/O::
8803 * Labels Visible to Debugger::
8806 @node Better Source Model
8807 @subsection Better Source Model
8809 @command{g77} needs to provide, as the default source-line model,
8810 a ``pure visual'' mode, where
8811 the interpretation of a source program in this mode can be accurately
8812 determined by a user looking at a traditionally displayed rendition
8813 of the program (assuming the user knows whether the program is fixed
8816 The design should assume the user cannot tell tabs from spaces
8817 and cannot see trailing spaces on lines, but has canonical tab stops
8818 and, for fixed-form source, has the ability to always know exactly
8819 where column 72 is (since the Fortran standard itself requires
8820 this for fixed-form source).
8822 This would change the default treatment of fixed-form source
8823 to not treat lines with tabs as if they were infinitely long---instead,
8824 they would end at column 72 just as if the tabs were replaced
8825 by spaces in the canonical way.
8827 As part of this, provide common alternate models (Digital, @command{f2c},
8828 and so on) via command-line options.
8829 This includes allowing arbitrarily long
8830 lines for free-form source as well as fixed-form source and providing
8831 various limits and diagnostics as appropriate.
8833 @cindex sequence numbers
8834 @cindex columns 73 through 80
8835 Also, @command{g77} should offer, perhaps even default to, warnings
8836 when characters beyond the last valid column are anything other
8838 This would mean code with ``sequence numbers'' in columns 73 through 80
8839 would be rejected, and there's a lot of that kind of code around,
8840 but one of the most frequent bugs encountered by new users is
8841 accidentally writing fixed-form source code into and beyond
8843 So, maybe the users of old code would be able to more easily handle
8844 having to specify, say, a @option{-Wno-col73to80} option.
8846 @node Fortran 90 Support
8847 @subsection Fortran 90 Support
8848 @cindex Fortran 90, support
8849 @cindex support, Fortran 90
8851 @command{g77} does not support many of the features that
8852 distinguish Fortran 90 (and, now, Fortran 95) from
8855 Some Fortran 90 features are supported, because they
8856 make sense to offer even to die-hard users of F77.
8857 For example, many of them codify various ways F77 has
8858 been extended to meet users' needs during its tenure,
8859 so @command{g77} might as well offer them as the primary
8860 way to meet those same needs, even if it offers compatibility
8861 with one or more of the ways those needs were met
8862 by other F77 compilers in the industry.
8864 Still, many important F90 features are not supported,
8865 because no attempt has been made to research each and
8866 every feature and assess its viability in @command{g77}.
8867 In the meantime, users who need those features must
8868 use Fortran 90 compilers anyway, and the best approach
8869 to adding some F90 features to GNU Fortran might well be
8870 to fund a comprehensive project to create GNU Fortran 95.
8872 @node Intrinsics in PARAMETER Statements
8873 @subsection Intrinsics in @code{PARAMETER} Statements
8874 @cindex PARAMETER statement
8875 @cindex statements, PARAMETER
8877 @command{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
8878 This feature is considered to be absolutely vital, even though it
8879 is not standard-conforming, and is scheduled for version 0.6.
8881 Related to this, @command{g77} doesn't allow non-integral
8882 exponentiation in @code{PARAMETER} statements, such as
8883 @samp{PARAMETER (R=2**.25)}.
8884 It is unlikely @command{g77} will ever support this feature,
8885 as doing it properly requires complete emulation of
8886 a target computer's floating-point facilities when
8887 building @command{g77} as a cross-compiler.
8888 But, if the @command{gcc} back end is enhanced to provide
8889 such a facility, @command{g77} will likely use that facility
8890 in implementing this feature soon afterwards.
8892 @node Arbitrary Concatenation
8893 @subsection Arbitrary Concatenation
8894 @cindex concatenation
8895 @cindex CHARACTER*(*)
8896 @cindex run-time, dynamic allocation
8898 @command{g77} doesn't support arbitrary operands for concatenation
8899 in contexts where run-time allocation is required.
8905 CALL FOO(A // 'suffix')
8908 @node SELECT CASE on CHARACTER Type
8909 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
8911 Character-type selector/cases for @code{SELECT CASE} currently
8914 @node RECURSIVE Keyword
8915 @subsection @code{RECURSIVE} Keyword
8916 @cindex RECURSIVE keyword
8917 @cindex keywords, RECURSIVE
8918 @cindex recursion, lack of
8919 @cindex lack of recursion
8921 @command{g77} doesn't support the @code{RECURSIVE} keyword that
8923 Nor does it provide any means for compiling procedures
8924 designed to do recursion.
8926 All recursive code can be rewritten to not use recursion,
8927 but the result is not pretty.
8929 @node Increasing Precision/Range
8930 @subsection Increasing Precision/Range
8932 @cindex -qrealsize=8
8935 @cindex increasing precision
8936 @cindex precision, increasing
8937 @cindex increasing range
8938 @cindex range, increasing
8942 Some compilers, such as @command{f2c}, have an option (@option{-r8},
8943 @option{-qrealsize=8} or
8944 similar) that provides automatic treatment of @code{REAL}
8945 entities such that they have twice the storage size, and
8946 a corresponding increase in the range and precision, of what
8947 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
8948 (This affects @code{COMPLEX} the same way.)
8950 They also typically offer another option (@option{-i8}) to increase
8951 @code{INTEGER} entities so they are twice as large
8952 (with roughly twice as much range).
8954 (There are potential pitfalls in using these options.)
8956 @command{g77} does not yet offer any option that performs these
8957 kinds of transformations.
8958 Part of the problem is the lack of detailed specifications regarding
8959 exactly how these options affect the interpretation of constants,
8960 intrinsics, and so on.
8962 Until @command{g77} addresses this need, programmers could improve
8963 the portability of their code by modifying it to not require
8964 compile-time options to produce correct results.
8965 Some free tools are available which may help, specifically
8966 in Toolpack (which one would expect to be sound) and the @file{fortran}
8967 section of the Netlib repository.
8969 Use of preprocessors can provide a fairly portable means
8970 to work around the lack of widely portable methods in the Fortran
8971 language itself (though increasing acceptance of Fortran 90 would
8972 alleviate this problem).
8974 @node Popular Non-standard Types
8975 @subsection Popular Non-standard Types
8976 @cindex @code{INTEGER*2} support
8977 @cindex types, @code{INTEGER*2}
8978 @cindex @code{LOGICAL*1} support
8979 @cindex types, @code{LOGICAL*1}
8981 @command{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
8983 Version 0.6 will provide full support for this very
8984 popular set of features.
8985 In the meantime, version 0.5.18 provides rudimentary support
8988 @node Full Support for Compiler Types
8989 @subsection Full Support for Compiler Types
8991 @cindex @code{REAL*16} support
8992 @cindex types, @code{REAL*16}
8993 @cindex @code{INTEGER*8} support
8994 @cindex types, @code{INTEGER*8}
8995 @command{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
8996 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
8997 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
8998 This means providing intrinsic support, and maybe constant
8999 support (using F90 syntax) as well, and, for most
9000 machines will result in automatic support of @code{INTEGER*1},
9001 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
9003 This is scheduled for version 0.6.
9005 @node Array Bounds Expressions
9006 @subsection Array Bounds Expressions
9007 @cindex array elements, in adjustable array bounds
9008 @cindex function references, in adjustable array bounds
9009 @cindex array bounds, adjustable
9010 @cindex @code{DIMENSION} statement
9011 @cindex statements, @code{DIMENSION}
9013 @command{g77} doesn't support more general expressions to dimension
9014 arrays, such as array element references, function
9017 For example, @command{g77} currently does not accept the following:
9021 INTEGER N(10), M(N(2), N(1))
9024 @node POINTER Statements
9025 @subsection POINTER Statements
9026 @cindex POINTER statement
9027 @cindex statements, POINTER
9028 @cindex Cray pointers
9030 @command{g77} doesn't support pointers or allocatable objects
9031 (other than automatic arrays).
9032 This set of features is
9033 probably considered just behind intrinsics
9034 in @code{PARAMETER} statements on the list of large,
9035 important things to add to @command{g77}.
9037 In the meantime, consider using the @code{INTEGER(KIND=7)}
9038 declaration to specify that a variable must be
9039 able to hold a pointer.
9040 This construct is not portable to other non-GNU compilers,
9041 but it is portable to all machines GNU Fortran supports
9042 when @command{g77} is used.
9044 @xref{Functions and Subroutines}, for information on
9045 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
9046 constructs, which are useful for passing pointers to
9047 procedures written in languages other than Fortran.
9049 @node Sensible Non-standard Constructs
9050 @subsection Sensible Non-standard Constructs
9052 @command{g77} rejects things other compilers accept,
9053 like @samp{INTRINSIC SQRT,SQRT}.
9054 As time permits in the future, some of these things that are easy for
9055 humans to read and write and unlikely to be intended to mean something
9056 else will be accepted by @command{g77} (though @option{-fpedantic} should
9057 trigger warnings about such non-standard constructs).
9059 Until @command{g77} no longer gratuitously rejects sensible code,
9060 you might as well fix your code
9061 to be more standard-conforming and portable.
9063 The kind of case that is important to except from the
9064 recommendation to change your code is one where following
9065 good coding rules would force you to write non-standard
9066 code that nevertheless has a clear meaning.
9068 For example, when writing an @code{INCLUDE} file that
9069 defines a common block, it might be appropriate to
9070 include a @code{SAVE} statement for the common block
9071 (such as @samp{SAVE /CBLOCK/}), so that variables
9072 defined in the common block retain their values even
9073 when all procedures declaring the common block become
9074 inactive (return to their callers).
9076 However, putting @code{SAVE} statements in an @code{INCLUDE}
9077 file would prevent otherwise standard-conforming code
9078 from also specifying the @code{SAVE} statement, by itself,
9079 to indicate that all local variables and arrays are to
9080 have the @code{SAVE} attribute.
9082 For this reason, @command{g77} already has been changed to
9083 allow this combination, because although the general
9084 problem of gratuitously rejecting unambiguous and
9085 ``safe'' constructs still exists in @command{g77}, this
9086 particular construct was deemed useful enough that
9087 it was worth fixing @command{g77} for just this case.
9089 So, while there is no need to change your code
9090 to avoid using this particular construct, there
9091 might be other, equally appropriate but non-standard
9092 constructs, that you shouldn't have to stop using
9093 just because @command{g77} (or any other compiler)
9094 gratuitously rejects it.
9096 Until the general problem is solved, if you have
9097 any such construct you believe is worthwhile
9098 using (e.g. not just an arbitrary, redundant
9099 specification of an attribute), please submit a
9100 bug report with an explanation, so we can consider
9101 fixing @command{g77} just for cases like yours.
9103 @node READONLY Keyword
9104 @subsection @code{READONLY} Keyword
9107 Support for @code{READONLY}, in @code{OPEN} statements,
9108 requires @code{libg2c} support,
9109 to make sure that @samp{CLOSE(@dots{},STATUS='DELETE')}
9110 does not delete a file opened on a unit
9111 with the @code{READONLY} keyword,
9112 and perhaps to trigger a fatal diagnostic
9113 if a @code{WRITE} or @code{PRINT}
9114 to such a unit is attempted.
9116 @emph{Note:} It is not sufficient for @command{g77} and @code{libg2c}
9117 (its version of @code{libf2c})
9118 to assume that @code{READONLY} does not need some kind of explicit support
9120 due to UNIX systems not (generally) needing it.
9121 @command{g77} is not just a UNIX-based compiler!
9123 Further, mounting of non-UNIX filesystems on UNIX systems
9125 might require proper @code{READONLY} support.
9128 (Similar issues might be involved with supporting the @code{SHARED}
9131 @node FLUSH Statement
9132 @subsection @code{FLUSH} Statement
9134 @command{g77} could perhaps use a @code{FLUSH} statement that
9135 does what @samp{CALL FLUSH} does,
9136 but that supports @samp{*} as the unit designator (same unit as for
9137 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
9140 @node Expressions in FORMAT Statements
9141 @subsection Expressions in @code{FORMAT} Statements
9142 @cindex FORMAT statement
9143 @cindex statements, FORMAT
9145 @command{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
9146 Supporting this requires a significant redesign or replacement
9149 However, @command{g77} does support
9150 this construct when the expression is constant
9151 (as of version 0.5.22).
9155 PARAMETER (IWIDTH = 12)
9156 10 FORMAT (I<IWIDTH>)
9159 Otherwise, at least for output (@code{PRINT} and
9160 @code{WRITE}), Fortran code making use of this feature can
9161 be rewritten to avoid it by constructing the @code{FORMAT}
9162 string in a @code{CHARACTER} variable or array, then
9163 using that variable or array in place of the @code{FORMAT}
9164 statement label to do the original @code{PRINT} or @code{WRITE}.
9166 Many uses of this feature on input can be rewritten this way
9167 as well, but not all can.
9168 For example, this can be rewritten:
9175 However, this cannot, in general, be rewritten, especially
9176 when @code{ERR=} and @code{END=} constructs are employed:
9183 @node Explicit Assembler Code
9184 @subsection Explicit Assembler Code
9186 @command{g77} needs to provide some way, a la @command{gcc}, for @command{g77}
9187 code to specify explicit assembler code.
9189 @node Q Edit Descriptor
9190 @subsection Q Edit Descriptor
9191 @cindex FORMAT statement
9192 @cindex Q edit descriptor
9193 @cindex edit descriptor, Q
9195 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
9196 (This is meant to get the number of characters remaining in an input record.)
9197 Supporting this requires a significant redesign or replacement
9200 A workaround might be using internal I/O or the stream-based intrinsics.
9201 @xref{FGetC Intrinsic (subroutine)}.
9203 @node Old-style PARAMETER Statements
9204 @subsection Old-style PARAMETER Statements
9205 @cindex PARAMETER statement
9206 @cindex statements, PARAMETER
9208 @command{g77} doesn't accept @samp{PARAMETER I=1}.
9209 Supporting this obsolete form of
9210 the @code{PARAMETER} statement would not be particularly hard, as most of the
9211 parsing code is already in place and working.
9214 spent implementing it, you might as well fix your code to use the
9215 standard form, @samp{PARAMETER (I=1)} (possibly needing
9216 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
9217 otherwise, in the obsolete form of @code{PARAMETER}, the
9218 type of the variable is set from the type of the constant being
9221 @node TYPE and ACCEPT I/O Statements
9222 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
9223 @cindex TYPE statement
9224 @cindex statements, TYPE
9225 @cindex ACCEPT statement
9226 @cindex statements, ACCEPT
9228 @command{g77} doesn't support the I/O statements @code{TYPE} and
9230 These are common extensions that should be easy to support,
9231 but also are fairly easy to work around in user code.
9233 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
9234 by @samp{PRINT fmt,list}.
9235 And, any @samp{ACCEPT fmt,list} statement can be
9236 replaced by @samp{READ fmt,list}.
9238 @node STRUCTURE UNION RECORD MAP
9239 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
9240 @cindex STRUCTURE statement
9241 @cindex statements, STRUCTURE
9242 @cindex UNION statement
9243 @cindex statements, UNION
9244 @cindex RECORD statement
9245 @cindex statements, RECORD
9246 @cindex MAP statement
9247 @cindex statements, MAP
9249 @command{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
9251 This set of extensions is quite a bit
9252 lower on the list of large, important things to add to @command{g77}, partly
9253 because it requires a great deal of work either upgrading or
9254 replacing @code{libg2c}.
9256 @node OPEN CLOSE and INQUIRE Keywords
9257 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
9258 @cindex disposition of files
9259 @cindex OPEN statement
9260 @cindex statements, OPEN
9261 @cindex CLOSE statement
9262 @cindex statements, CLOSE
9263 @cindex INQUIRE statement
9264 @cindex statements, INQUIRE
9266 @command{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
9267 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
9268 These extensions are easy to add to @command{g77} itself, but
9269 require much more work on @code{libg2c}.
9271 @cindex FORM='PRINT'
9272 @cindex ANS carriage control
9273 @cindex carriage control
9276 @command{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
9277 translate the traditional `carriage control' characters in column 1 of
9278 output to use backspaces, carriage returns and the like. However
9279 programs exist to translate them in output files (or standard output).
9280 These are typically called either @command{fpr} or @command{asa}. You can get
9281 a version of @command{asa} from
9282 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
9283 systems which will probably build easily on other systems.
9284 Alternatively, @command{fpr} is in BSD distributions in various archive
9287 @c (Can both programs can be used in a pipeline,
9288 @c with a named input file,
9289 @c and/or with a named output file???)
9291 @node ENCODE and DECODE
9292 @subsection @code{ENCODE} and @code{DECODE}
9293 @cindex ENCODE statement
9294 @cindex statements, ENCODE
9295 @cindex DECODE statement
9296 @cindex statements, DECODE
9298 @command{g77} doesn't support @code{ENCODE} or @code{DECODE}.
9300 These statements are best replaced by READ and WRITE statements
9301 involving internal files (CHARACTER variables and arrays).
9303 For example, replace a code fragment like
9308 DECODE (80, 9000, LINE) A, B, C
9310 9000 FORMAT (1X, 3(F10.5))
9319 READ (UNIT=LINE, FMT=9000) A, B, C
9321 9000 FORMAT (1X, 3(F10.5))
9324 Similarly, replace a code fragment like
9329 ENCODE (80, 9000, LINE) A, B, C
9331 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
9340 WRITE (UNIT=LINE, FMT=9000) A, B, C
9342 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
9345 It is entirely possible that @code{ENCODE} and @code{DECODE} will
9346 be supported by a future version of @command{g77}.
9348 @node AUTOMATIC Statement
9349 @subsection @code{AUTOMATIC} Statement
9350 @cindex @code{AUTOMATIC} statement
9351 @cindex statements, @code{AUTOMATIC}
9352 @cindex automatic variables
9353 @cindex variables, automatic
9355 @command{g77} doesn't support the @code{AUTOMATIC} statement that
9358 @code{AUTOMATIC} would identify a variable or array
9359 as not being @code{SAVE}'d, which is normally the default,
9360 but which would be especially useful for code that, @emph{generally},
9361 needed to be compiled with the @option{-fno-automatic} option.
9363 @code{AUTOMATIC} also would serve as a hint to the compiler that placing
9364 the variable or array---even a very large array--on the stack is acceptable.
9366 @code{AUTOMATIC} would not, by itself, designate the containing procedure
9369 @code{AUTOMATIC} should work syntactically like @code{SAVE},
9370 in that @code{AUTOMATIC} with no variables listed should apply to
9371 all pertinent variables and arrays
9372 (which would not include common blocks or their members).
9374 Variables and arrays denoted as @code{AUTOMATIC}
9375 would not be permitted to be initialized via @code{DATA}
9376 or other specification of any initial values,
9377 requiring explicit initialization,
9378 such as via assignment statements.
9382 Perhaps @code{UNSAVE} and @code{STATIC},
9383 as strict semantic opposites to @code{SAVE} and @code{AUTOMATIC},
9384 should be provided as well.
9386 @node Suppressing Space Padding
9387 @subsection Suppressing Space Padding of Source Lines
9389 @command{g77} should offer VXT-Fortran-style suppression of virtual
9390 spaces at the end of a source line
9391 if an appropriate command-line option is specified.
9393 This affects cases where
9394 a character constant is continued onto the next line in a fixed-form
9395 source file, as in the following example:
9398 10 PRINT *,'HOW MANY
9403 @command{g77}, and many other compilers, virtually extend
9404 the continued line through column 72 with spaces that become part
9405 of the character constant, but Digital Fortran normally didn't,
9406 leaving only one space between @samp{MANY} and @samp{SPACES?}
9407 in the output of the above statement.
9409 Fairly recently, at least one version of Digital Fortran
9410 was enhanced to provide the other behavior when a
9411 command-line option is specified, apparently due to demand
9412 from readers of the USENET group @file{comp.lang.fortran}
9413 to offer conformance to this widespread practice in the
9415 @command{g77} should return the favor by offering conformance
9416 to Digital's approach to handling the above example.
9418 @node Fortran Preprocessor
9419 @subsection Fortran Preprocessor
9421 @command{g77} should offer a preprocessor designed specifically
9422 for Fortran to replace @samp{cpp -traditional}.
9423 There are several out there worth evaluating, at least.
9425 Such a preprocessor would recognize Hollerith constants,
9426 properly parse comments and character constants, and so on.
9427 It might also recognize, process, and thus preprocess
9428 files included via the @code{INCLUDE} directive.
9430 @node Bit Operations on Floating-point Data
9431 @subsection Bit Operations on Floating-point Data
9432 @cindex @code{And} intrinsic
9433 @cindex intrinsics, @code{And}
9434 @cindex @code{Or} intrinsic
9435 @cindex intrinsics, @code{Or}
9436 @cindex @code{Shift} intrinsic
9437 @cindex intrinsics, @code{Shift}
9439 @command{g77} does not allow @code{REAL} and other non-integral types for
9440 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
9442 For example, this program is rejected by @command{g77}, because
9443 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
9446 DATA A/7.54/, B/9.112/
9451 @node Really Ugly Character Assignments
9452 @subsection Really Ugly Character Assignments
9454 An option such as @option{-fugly-char} should be provided
9459 DATA A1 / '12345678' /
9469 @node POSIX Standard
9470 @subsection @code{POSIX} Standard
9472 @command{g77} should support the POSIX standard for Fortran.
9474 @node Floating-point Exception Handling
9475 @subsection Floating-point Exception Handling
9476 @cindex floating-point, exceptions
9477 @cindex exceptions, floating-point
9478 @cindex FPE handling
9481 The @command{gcc} backend and, consequently, @command{g77}, currently provides no
9482 general control over whether or not floating-point exceptions are trapped or
9484 (Ignoring them typically results in NaN values being
9485 propagated in systems that conform to IEEE 754.)
9486 The behaviour is normally inherited from the system-dependent startup
9487 code, though some targets, such as the Alpha, have code generation
9488 options which change the behaviour.
9490 Most systems provide some C-callable mechanism to change this; this can
9491 be invoked at startup using @command{gcc}'s @code{constructor} attribute.
9492 For example, just compiling and linking the following C code with your
9493 program will turn on exception trapping for the ``common'' exceptions
9494 on a GNU system using glibc 2.2 or newer:
9497 #define _GNU_SOURCE 1
9499 static void __attribute__ ((constructor))
9502 /* Enable some exceptions. At startup all exceptions are masked. */
9504 feenableexcept (FE_INVALID|FE_DIVBYZERO|FE_OVERFLOW);
9508 A convenient trick is to compile this something like:
9510 gcc -o libtrapfpe.a trapfpe.c
9512 and then use it by adding @option{-trapfpe} to the @command{g77} command line
9515 @node Nonportable Conversions
9516 @subsection Nonportable Conversions
9517 @cindex nonportable conversions
9518 @cindex conversions, nonportable
9520 @command{g77} doesn't accept some particularly nonportable,
9521 silent data-type conversions such as @code{LOGICAL}
9522 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
9523 is type @code{REAL}), that other compilers might
9526 Some of these conversions are accepted by @command{g77}
9527 when the @option{-fugly-logint} option is specified.
9528 Perhaps it should accept more or all of them.
9530 @node Large Automatic Arrays
9531 @subsection Large Automatic Arrays
9532 @cindex automatic arrays
9533 @cindex arrays, automatic
9535 Currently, automatic arrays always are allocated on the stack.
9536 For situations where the stack cannot be made large enough,
9537 @command{g77} should offer a compiler option that specifies
9538 allocation of automatic arrays in heap storage.
9540 @node Support for Threads
9541 @subsection Support for Threads
9543 @cindex parallel processing
9545 Neither the code produced by @command{g77} nor the @code{libg2c} library
9546 are thread-safe, nor does @command{g77} have support for parallel processing
9547 (other than the instruction-level parallelism available on some
9549 A package such as PVM might help here.
9551 @node Enabling Debug Lines
9552 @subsection Enabling Debug Lines
9554 @cindex comment line, debug
9556 An option such as @option{-fdebug-lines} should be provided
9557 to turn fixed-form lines beginning with @samp{D}
9558 to be treated as if they began with a space,
9559 instead of as if they began with a @samp{C}
9562 @node Better Warnings
9563 @subsection Better Warnings
9565 Because of how @command{g77} generates code via the back end,
9566 it doesn't always provide warnings the user wants.
9575 Currently, the above is not flagged as a case of
9576 using an uninitialized variable,
9577 because @command{g77} generates a run-time library call that looks,
9578 to the GBE, like it might actually @emph{modify} @samp{A} at run time.
9579 (And, in fact, depending on the previous run-time library call,
9582 Fixing this requires one of the following:
9586 Switch to new library, @code{libg77}, that provides
9587 a more ``clean'' interface,
9588 vis-a-vis input, output, and modified arguments,
9589 so the GBE can tell what's going on.
9591 This would provide a pretty big performance improvement,
9592 at least theoretically, and, ultimately, in practice,
9593 for some types of code.
9596 Have @command{g77} pass a pointer to a temporary
9597 containing a copy of @samp{A},
9598 instead of to @samp{A} itself.
9599 The GBE would then complain about the copy operation
9600 involving a potentially uninitialized variable.
9602 This might also provide a performance boost for some code,
9603 because @samp{A} might then end up living in a register,
9604 which could help with inner loops.
9607 Have @command{g77} use a GBE construct similar to @code{ADDR_EXPR}
9608 but with extra information on the fact that the
9609 item pointed to won't be modified
9610 (a la @code{const} in C).
9612 Probably the best solution for now, but not quite trivial
9613 to implement in the general case.
9614 Worth considering after @command{g77} 0.6 is considered
9618 @node Gracefully Handle Sensible Bad Code
9619 @subsection Gracefully Handle Sensible Bad Code
9621 @command{g77} generally should continue processing for
9622 warnings and recoverable (user) errors whenever possible---that
9623 is, it shouldn't gratuitously make bad or useless code.
9634 When compiling the above with @option{-ff2c-intrinsics-disable},
9635 @command{g77} should indeed complain about passing @code{ZABS},
9636 but it still should compile, instead of rejecting
9637 the entire @code{CALL} statement.
9638 (Some of this is related to improving
9639 the compiler internals to improve how statements are analyzed.)
9641 @node Non-standard Conversions
9642 @subsection Non-standard Conversions
9644 @option{-Wconversion} and related should flag places where non-standard
9645 conversions are found.
9646 Perhaps much of this would be part of @option{-Wugly*}.
9648 @node Non-standard Intrinsics
9649 @subsection Non-standard Intrinsics
9651 @command{g77} needs a new option, like @option{-Wintrinsics}, to warn about use of
9652 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
9653 This would help find code that might fail silently when ported to another
9656 @node Modifying DO Variable
9657 @subsection Modifying @code{DO} Variable
9659 @command{g77} should warn about modifying @code{DO} variables
9660 via @code{EQUIVALENCE}.
9661 (The internal information gathered to produce this warning
9662 might also be useful in setting the
9663 internal ``doiter'' flag for a variable or even array
9664 reference within a loop, since that might produce faster code someday.)
9666 For example, this code is invalid, so @command{g77} should warn about
9667 the invalid assignment to @samp{NOTHER}:
9670 EQUIVALENCE (I, NOTHER)
9672 IF (I.EQ. 10) NOTHER = 20
9676 @node Better Pedantic Compilation
9677 @subsection Better Pedantic Compilation
9679 @command{g77} needs to support @option{-fpedantic} more thoroughly,
9680 and use it only to generate
9681 warnings instead of rejecting constructs outright.
9683 if a variable that dimensions an array is not a dummy or placed
9684 explicitly in @code{COMMON} (F77 does not allow it to be
9685 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
9686 follow statement-function-definition statements; about all sorts of
9687 syntactic extensions.
9689 @node Warn About Implicit Conversions
9690 @subsection Warn About Implicit Conversions
9692 @command{g77} needs a @option{-Wpromotions} option to warn if source code appears
9693 to expect automatic, silent, and
9694 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
9695 constants to @code{REAL(KIND=2)} based on context.
9697 For example, it would warn about cases like this:
9700 DOUBLE PRECISION FOO
9701 PARAMETER (TZPHI = 9.435784839284958)
9705 @node Invalid Use of Hollerith Constant
9706 @subsection Invalid Use of Hollerith Constant
9708 @command{g77} should disallow statements like @samp{RETURN 2HAB},
9709 which are invalid in both source forms
9710 (unlike @samp{RETURN (2HAB)},
9711 which probably still makes no sense but at least can
9712 be reliably parsed).
9713 Fixed-form processing rejects it, but not free-form, except
9714 in a way that is a bit difficult to understand.
9716 @node Dummy Array Without Dimensioning Dummy
9717 @subsection Dummy Array Without Dimensioning Dummy
9719 @command{g77} should complain when a list of dummy arguments containing an
9720 adjustable dummy array does
9721 not also contain every variable listed in the dimension list of the
9724 Currently, @command{g77} does complain about a variable that
9725 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
9726 area, but this needs to be extended to catch cases where it doesn't appear in
9727 every dummy list that also lists any arrays it dimensions.
9729 For example, @command{g77} should warn about the entry point @samp{ALT}
9730 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
9734 SUBROUTINE PRIMARY(ARRAY, ISIZE)
9739 @node Invalid FORMAT Specifiers
9740 @subsection Invalid FORMAT Specifiers
9742 @command{g77} should check @code{FORMAT} specifiers for validity
9743 as it does @code{FORMAT} statements.
9745 For example, a diagnostic would be produced for:
9748 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
9751 @node Ambiguous Dialects
9752 @subsection Ambiguous Dialects
9754 @command{g77} needs a set of options such as @option{-Wugly*}, @option{-Wautomatic},
9755 @option{-Wvxt}, @option{-Wf90}, and so on.
9756 These would warn about places in the user's source where ambiguities
9757 are found, helpful in resolving ambiguities in the program's
9758 dialect or dialects.
9761 @subsection Unused Labels
9763 @command{g77} should warn about unused labels when @option{-Wunused} is in effect.
9765 @node Informational Messages
9766 @subsection Informational Messages
9768 @command{g77} needs an option to suppress information messages (notes).
9769 @option{-w} does this but also suppresses warnings.
9770 The default should be to suppress info messages.
9772 Perhaps info messages should simply be eliminated.
9774 @node Uninitialized Variables at Run Time
9775 @subsection Uninitialized Variables at Run Time
9777 @command{g77} needs an option to initialize everything (not otherwise
9778 explicitly initialized) to ``weird''
9779 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
9780 largest-magnitude integers, would help track down references to
9781 some kinds of uninitialized variables at run time.
9783 Note that use of the options @samp{-O -Wuninitialized} can catch
9784 many such bugs at compile time.
9786 @node Portable Unformatted Files
9787 @subsection Portable Unformatted Files
9789 @cindex unformatted files
9790 @cindex file formats
9792 @cindex byte ordering
9793 @command{g77} has no facility for exchanging unformatted files with systems
9794 using different number formats---even differing only in endianness (byte
9795 order)---or written by other compilers. Some compilers provide
9796 facilities at least for doing byte-swapping during unformatted I/O.
9798 It is unrealistic to expect to cope with exchanging unformatted files
9799 with arbitrary other compiler runtimes, but the @command{g77} runtime
9800 should at least be able to read files written by @command{g77} on systems
9801 with different number formats, particularly if they differ only in byte
9804 In case you do need to write a program to translate to or from
9805 @command{g77} (@code{libf2c}) unformatted files, they are written as
9809 Unformatted sequential records consist of
9812 A number giving the length of the record contents;
9814 the length of record contents again (for backspace).
9817 The record length is of C type
9818 @code{long}; this means that it is 8 bytes on 64-bit systems such as
9819 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
9820 Consequently such files cannot be exchanged between 64-bit and 32-bit
9821 systems, even with the same basic number format.
9823 Unformatted direct access files form a byte stream of length
9824 @var{records}*@var{recl} bytes, where @var{records} is the maximum
9825 record number (@code{REC=@var{records}}) written and @var{recl} is the
9826 record length in bytes specified in the @code{OPEN} statement
9827 (@code{RECL=@var{recl}}). Data appear in the records as determined by
9828 the relevant @code{WRITE} statement. Dummy records with arbitrary
9829 contents appear in the file in place of records which haven't been
9833 Thus for exchanging a sequential or direct access unformatted file
9834 between big- and little-endian 32-bit systems using IEEE 754 floating
9835 point it would be sufficient to reverse the bytes in consecutive words
9836 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
9837 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
9840 If necessary, it is possible to do byte-oriented i/o with @command{g77}'s
9841 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
9842 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
9843 array or a set of scalars.
9847 If you need to exchange binary data between arbitrary system and
9848 compiler variations, we recommend using a portable binary format with
9849 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
9850 or PACT's PDB@footnote{No, not @emph{that} one.}
9851 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
9852 say, CDF or XDR, HDF-like systems write in the native number formats and
9853 only incur overhead when they are read on a system with a different
9854 format.) A future @command{g77} runtime library should use such
9857 @node Better List-directed I/O
9858 @subsection Better List-directed I/O
9860 Values output using list-directed I/O
9861 (@samp{PRINT *, R, D})
9862 should be written with a field width, precision, and so on
9863 appropriate for the type (precision) of each value.
9865 (Currently, no distinction is made between single-precision
9866 and double-precision values
9869 It is likely this item will require the @code{libg77} project
9872 In the meantime, use of formatted I/O is recommended.
9873 While it might be of little consolation,
9874 @command{g77} does support @samp{FORMAT(F<WIDTH>.4)}, for example,
9875 as long as @samp{WIDTH} is defined as a named constant
9876 (via @code{PARAMETER}).
9877 That at least allows some compile-time specification
9878 of the precision of a data type,
9879 perhaps controlled by preprocessing directives.
9881 @node Default to Console I/O
9882 @subsection Default to Console I/O
9884 The default I/O units,
9885 specified by @samp{READ @var{fmt}},
9886 @samp{READ (UNIT=*)},
9887 @samp{WRITE (UNIT=*)}, and
9888 @samp{PRINT @var{fmt}},
9889 should not be units 5 (input) and 6 (output),
9890 but, rather, unit numbers not normally available
9891 for use in statements such as @code{OPEN} and @code{CLOSE}.
9893 Changing this would allow a program to connect units 5 and 6
9894 to files via @code{OPEN},
9895 but still use @samp{READ (UNIT=*)} and @samp{PRINT}
9896 to do I/O to the ``console''.
9898 This change probably requires the @code{libg77} project.
9900 @node Labels Visible to Debugger
9901 @subsection Labels Visible to Debugger
9903 @command{g77} should output debugging information for statements labels,
9904 for use by debuggers that know how to support them.
9905 Same with weirder things like construct names.
9906 It is not yet known if any debug formats or debuggers support these.
9908 @node Disappointments
9909 @section Disappointments and Misunderstandings
9911 These problems are perhaps regrettable, but we don't know any practical
9912 way around them for now.
9915 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
9916 external name @samp{foo_}.
9917 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
9918 and @samp{SUBROUTINE FOO}.
9919 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
9922 @node Mangling of Names
9923 @subsection Mangling of Names in Source Code
9924 @cindex naming issues
9925 @cindex external names
9926 @cindex common blocks
9930 The current external-interface design, which includes naming of
9931 external procedures, COMMON blocks, and the library interface,
9932 has various usability problems, including things like adding
9933 underscores where not really necessary (and preventing easier
9934 inter-language operability) and yet not providing complete
9935 namespace freedom for user C code linked with Fortran apps (due
9936 to the naming of functions in the library, among other things).
9938 Project GNU should at least get all this ``right'' for systems
9939 it fully controls, such as the Hurd, and provide defaults and
9940 options for compatibility with existing systems and interoperability
9941 with popular existing compilers.
9943 @node Multiple Definitions of External Names
9944 @subsection Multiple Definitions of External Names
9946 @cindex BLOCK DATA statement
9947 @cindex statements, BLOCK DATA
9948 @cindex @code{COMMON} statement
9949 @cindex statements, @code{COMMON}
9950 @cindex naming conflicts
9952 @command{g77} doesn't allow a common block and an external procedure or
9953 @code{BLOCK DATA} to have the same name.
9954 Some systems allow this, but @command{g77} does not,
9955 to be compatible with @command{f2c}.
9957 @command{g77} could special-case the way it handles
9958 @code{BLOCK DATA}, since it is not compatible with @command{f2c} in this
9959 particular area (necessarily, since @command{g77} offers an
9960 important feature here), but
9961 it is likely that such special-casing would be very annoying to people
9962 with programs that use @samp{EXTERNAL FOO}, with no other mention of
9963 @samp{FOO} in the same program unit, to refer to external procedures, since
9964 the result would be that @command{g77} would treat these references as requests to
9965 force-load BLOCK DATA program units.
9967 In that case, if @command{g77} modified
9968 names of @code{BLOCK DATA} so they could have the same names as
9969 @code{COMMON}, users
9970 would find that their programs wouldn't link because the @samp{FOO} procedure
9971 didn't have its name translated the same way.
9974 @command{g77} could emit a null-but-externally-satisfying definition of
9975 @samp{FOO} with its name transformed as if it had been a
9976 @code{BLOCK DATA}, but that probably invites more trouble than it's
9979 @node Limitation on Implicit Declarations
9980 @subsection Limitation on Implicit Declarations
9981 @cindex IMPLICIT CHARACTER*(*) statement
9982 @cindex statements, IMPLICIT CHARACTER*(*)
9984 @command{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
9985 This is not standard-conforming.
9988 @section Certain Changes We Don't Want to Make
9990 This section lists changes that people frequently request, but which
9991 we do not make because we think GNU Fortran is better without them.
9994 * Backslash in Constants:: Why @samp{'\\'} is a constant that
9995 is one, not two, characters long.
9996 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
9998 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
9999 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
10000 single-precision constant,
10001 and might be interpreted as
10002 @samp{9.435785} or similar.
10003 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
10004 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
10005 not behave as expected.
10008 @node Backslash in Constants
10009 @subsection Backslash in Constants
10011 @cindex @command{f77} support
10012 @cindex support, @command{f77}
10014 In the opinion of many experienced Fortran users,
10015 @option{-fno-backslash} should be the default, not @option{-fbackslash},
10016 as currently set by @command{g77}.
10018 First of all, you can always specify
10019 @option{-fno-backslash} to turn off this processing.
10021 Despite not being within the spirit (though apparently within the
10022 letter) of the ANSI FORTRAN 77 standard, @command{g77} defaults to
10023 @option{-fbackslash} because that is what most UNIX @command{f77} commands
10024 default to, and apparently lots of code depends on this feature.
10026 This is a particularly troubling issue.
10027 The use of a C construct in the midst of Fortran code
10028 is bad enough, worse when it makes existing Fortran
10029 programs stop working (as happens when programs written
10030 for non-UNIX systems are ported to UNIX systems with
10031 compilers that provide the @option{-fbackslash} feature
10032 as the default---sometimes with no option to turn it off).
10034 The author of GNU Fortran wished, for reasons of linguistic
10035 purity, to make @option{-fno-backslash} the default for GNU
10036 Fortran and thus require users of UNIX @command{f77} and @command{f2c}
10037 to specify @option{-fbackslash} to get the UNIX behavior.
10039 However, the realization that @command{g77} is intended as
10040 a replacement for @emph{UNIX} @command{f77}, caused the author
10041 to choose to make @command{g77} as compatible with
10042 @command{f77} as feasible, which meant making @option{-fbackslash}
10045 The primary focus on compatibility is at the source-code
10046 level, and the question became ``What will users expect
10047 a replacement for @command{f77} to do, by default?''
10048 Although at least one UNIX @command{f77} does not provide
10049 @option{-fbackslash} as a default, it appears that
10050 the majority of them do, which suggests that
10051 the majority of code that is compiled by UNIX @command{f77}
10052 compilers expects @option{-fbackslash} to be the default.
10054 It is probably the case that more code exists
10055 that would @emph{not} work with @option{-fbackslash}
10056 in force than code that requires it be in force.
10058 However, most of @emph{that} code is not being compiled
10059 with @command{f77},
10060 and when it is, new build procedures (shell scripts,
10061 makefiles, and so on) must be set up anyway so that
10062 they work under UNIX.
10063 That makes a much more natural and safe opportunity for
10064 non-UNIX users to adapt their build procedures for
10065 @command{g77}'s default of @option{-fbackslash} than would
10066 exist for the majority of UNIX @command{f77} users who
10067 would have to modify existing, working build procedures
10068 to explicitly specify @option{-fbackslash} if that was
10071 One suggestion has been to configure the default for
10072 @option{-fbackslash} (and perhaps other options as well)
10073 based on the configuration of @command{g77}.
10075 This is technically quite straightforward, but will be avoided
10076 even in cases where not configuring defaults to be
10077 dependent on a particular configuration greatly inconveniences
10078 some users of legacy code.
10080 Many users appreciate the GNU compilers because they provide an
10081 environment that is uniform across machines.
10082 These users would be
10083 inconvenienced if the compiler treated things like the
10084 format of the source code differently on certain machines.
10086 Occasionally users write programs intended only for a particular machine
10088 On these occasions, the users would benefit if the GNU Fortran compiler
10089 were to support by default the same dialect as the other compilers on
10091 But such applications are rare.
10092 And users writing a
10093 program to run on more than one type of machine cannot possibly benefit
10094 from this kind of compatibility.
10095 (This is consistent with the design goals for @command{gcc}.
10096 To change them for @command{g77}, you must first change them
10098 Do not ask the maintainers of @command{g77} to do this for you,
10099 or to disassociate @command{g77} from the widely understood, if
10100 not widely agreed-upon, goals for GNU compilers in general.)
10102 This is why GNU Fortran does and will treat backslashes in the same
10103 fashion on all types of machines (by default).
10104 @xref{Direction of Language Development}, for more information on
10105 this overall philosophy guiding the development of the GNU Fortran
10108 Of course, users strongly concerned about portability should indicate
10109 explicitly in their build procedures which options are expected
10110 by their source code, or write source code that has as few such
10111 expectations as possible.
10113 For example, avoid writing code that depends on backslash (@samp{\})
10114 being interpreted either way in particular, such as by
10115 starting a program unit with:
10119 PARAMETER (BACKSL = '\\')
10123 Then, use concatenation of @samp{BACKSL} anyplace a backslash
10125 In this way, users can write programs which have the same meaning
10126 in many Fortran dialects.
10128 (However, this technique does not work for Hollerith constants---which
10129 is just as well, since the only generally portable uses for Hollerith
10130 constants are in places where character constants can and should
10131 be used instead, for readability.)
10133 @node Initializing Before Specifying
10134 @subsection Initializing Before Specifying
10135 @cindex initialization, statement placement
10136 @cindex placing initialization statements
10138 @command{g77} does not allow @samp{DATA VAR/1/} to appear in the
10139 source code before @samp{COMMON VAR},
10140 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
10141 In general, @command{g77} requires initialization of a variable
10142 or array to be specified @emph{after} all other specifications
10143 of attributes (type, size, placement, and so on) of that variable
10144 or array are specified (though @emph{confirmation} of data type is
10147 It is @emph{possible} @command{g77} will someday allow all of this,
10148 even though it is not allowed by the FORTRAN 77 standard.
10150 Then again, maybe it is better to have
10151 @command{g77} always require placement of @code{DATA}
10152 so that it can possibly immediately write constants
10153 to the output file, thus saving time and space.
10155 That is, @samp{DATA A/1000000*1/} should perhaps always
10156 be immediately writable to canonical assembler, unless it's already known
10157 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
10158 and to do this it cannot be followed by @samp{COMMON A}.
10160 @node Context-Sensitive Intrinsicness
10161 @subsection Context-Sensitive Intrinsicness
10162 @cindex intrinsics, context-sensitive
10163 @cindex context-sensitive intrinsics
10165 @command{g77} treats procedure references to @emph{possible} intrinsic
10166 names as always enabling their intrinsic nature, regardless of
10167 whether the @emph{form} of the reference is valid for that
10170 For example, @samp{CALL SQRT} is interpreted by @command{g77} as
10171 an invalid reference to the @code{SQRT} intrinsic function,
10172 because the reference is a subroutine invocation.
10174 First, @command{g77} recognizes the statement @samp{CALL SQRT}
10175 as a reference to a @emph{procedure} named @samp{SQRT}, not
10176 to a @emph{variable} with that name (as it would for a statement
10177 such as @samp{V = SQRT}).
10179 Next, @command{g77} establishes that, in the program unit being compiled,
10180 @code{SQRT} is an intrinsic---not a subroutine that
10181 happens to have the same name as an intrinsic (as would be
10182 the case if, for example, @samp{EXTERNAL SQRT} was present).
10184 Finally, @command{g77} recognizes that the @emph{form} of the
10185 reference is invalid for that particular intrinsic.
10186 That is, it recognizes that it is invalid for an intrinsic
10187 @emph{function}, such as @code{SQRT}, to be invoked as
10188 a @emph{subroutine}.
10190 At that point, @command{g77} issues a diagnostic.
10192 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
10193 references an external subroutine of their own, not an
10194 intrinsic function.
10196 However, @command{g77} knows about intrinsic
10197 subroutines, not just functions, and is able to support both having
10198 the same names, for example.
10200 As a result of this, @command{g77} rejects calls
10201 to intrinsics that are not subroutines, and function invocations
10202 of intrinsics that are not functions, just as it (and most compilers)
10203 rejects invocations of intrinsics with the wrong number (or types)
10206 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
10207 a user-written subroutine named @samp{SQRT}.
10209 @node Context-Sensitive Constants
10210 @subsection Context-Sensitive Constants
10211 @cindex constants, context-sensitive
10212 @cindex context-sensitive constants
10214 @command{g77} does not use context to determine the types of
10215 constants or named constants (@code{PARAMETER}), except
10216 for (non-standard) typeless constants such as @samp{'123'O}.
10218 For example, consider the following statement:
10221 PRINT *, 9.435784839284958 * 2D0
10225 @command{g77} will interpret the (truncated) constant
10226 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
10227 constant, because the suffix @code{D0} is not specified.
10229 As a result, the output of the above statement when
10230 compiled by @command{g77} will appear to have ``less precision''
10231 than when compiled by other compilers.
10233 In these and other cases, some compilers detect the
10234 fact that a single-precision constant is used in
10235 a double-precision context and therefore interpret the
10236 single-precision constant as if it was @emph{explicitly}
10237 specified as a double-precision constant.
10238 (This has the effect of appending @emph{decimal}, not
10239 @emph{binary}, zeros to the fractional part of the
10240 number---producing different computational results.)
10242 The reason this misfeature is dangerous is that a slight,
10243 apparently innocuous change to the source code can change
10244 the computational results.
10249 DOUBLE PRECISION FIVE
10250 PARAMETER (ALMOST = 5.000000000001)
10252 CLOSE = 5.000000000001
10253 PRINT *, 5.000000000001 - FIVE
10254 PRINT *, ALMOST - FIVE
10255 PRINT *, CLOSE - FIVE
10260 Running the above program should
10261 result in the same value being
10262 printed three times.
10263 With @command{g77} as the compiler,
10266 However, compiled by many other compilers,
10267 running the above program would print
10268 two or three distinct values, because
10269 in two or three of the statements, the
10270 constant @samp{5.000000000001}, which
10271 on most systems is exactly equal to @samp{5.}
10272 when interpreted as a single-precision constant,
10273 is instead interpreted as a double-precision
10274 constant, preserving the represented
10276 However, this ``clever'' promotion of
10277 type does not extend to variables or,
10278 in some compilers, to named constants.
10280 Since programmers often are encouraged to replace manifest
10281 constants or permanently-assigned variables with named
10282 constants (@code{PARAMETER} in Fortran), and might need
10283 to replace some constants with variables having the same
10284 values for pertinent portions of code,
10285 it is important that compilers treat code so modified in the
10286 same way so that the results of such programs are the same.
10287 @command{g77} helps in this regard by treating constants just
10288 the same as variables in terms of determining their types
10289 in a context-independent way.
10291 Still, there is a lot of existing Fortran code that has
10292 been written to depend on the way other compilers freely
10293 interpret constants' types based on context, so anything
10294 @command{g77} can do to help flag cases of this in such code
10295 could be very helpful.
10297 @node Equivalence Versus Equality
10298 @subsection Equivalence Versus Equality
10299 @cindex .EQV., with integer operands
10300 @cindex comparing logical expressions
10301 @cindex logical expressions, comparing
10303 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
10304 is not supported, except via @option{-fugly-logint}, which is not
10305 recommended except for legacy code (where the behavior expected
10306 by the @emph{code} is assumed).
10308 Legacy code should be changed, as resources permit, to use @code{.EQV.}
10309 and @code{.NEQV.} instead, as these are permitted by the various
10312 New code should never be written expecting @code{.EQ.} or @code{.NE.}
10313 to work if either of its operands is @code{LOGICAL}.
10315 The problem with supporting this ``feature'' is that there is
10316 unlikely to be consensus on how it works, as illustrated by the
10317 following sample program:
10321 DATA L,M,N /3*.FALSE./
10322 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
10326 The issue raised by the above sample program is: what is the
10327 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
10328 @code{LOGICAL} operands?
10330 Some programmers will argue that it is the same as the precedence
10331 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
10333 By this interpretation, the subexpression @samp{M.EQ.N} must be
10334 evaluated first in the above program, resulting in a program that,
10335 when run, does not execute the @code{PRINT} statement.
10337 Other programmers will argue that the precedence is the same as
10338 the precedence for @code{.EQV.}, which is restricted by the standards
10339 to @code{LOGICAL} operands.
10340 By this interpretation, the subexpression @samp{L.AND.M} must be
10341 evaluated first, resulting in a program that @emph{does} execute
10342 the @code{PRINT} statement.
10344 Assigning arbitrary semantic interpretations to syntactic expressions
10345 that might legitimately have more than one ``obvious'' interpretation
10346 is generally unwise.
10348 The creators of the various Fortran standards have done a good job
10349 in this case, requiring a distinct set of operators (which have their
10350 own distinct precedence) to compare @code{LOGICAL} operands.
10351 This requirement results in expression syntax with more certain
10352 precedence (without requiring substantial context), making it easier
10353 for programmers to read existing code.
10354 @command{g77} will avoid muddying up elements of the Fortran language
10355 that were well-designed in the first place.
10357 (Ask C programmers about the precedence of expressions such as
10358 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
10359 you, without knowing more context, whether the @samp{&} and @samp{-}
10360 operators are infix (binary) or unary!)
10362 Most dangerous of all is the fact that,
10363 even assuming consensus on its meaning,
10364 an expression like @samp{L.AND.M.EQ.N},
10365 if it is the result of a typographical error,
10366 doesn't @emph{look} like it has such a typo.
10367 Even experienced Fortran programmers would not likely notice that
10368 @samp{L.AND.M.EQV.N} was, in fact, intended.
10370 So, this is a prime example of a circumstance in which
10371 a quality compiler diagnoses the code,
10372 instead of leaving it up to someone debugging it
10373 to know to turn on special compiler options
10374 that might diagnose it.
10376 @node Order of Side Effects
10377 @subsection Order of Side Effects
10378 @cindex side effects, order of evaluation
10379 @cindex order of evaluation, side effects
10381 @command{g77} does not necessarily produce code that, when run, performs
10382 side effects (such as those performed by function invocations)
10383 in the same order as in some other compiler---or even in the same
10384 order as another version, port, or invocation (using different
10385 command-line options) of @command{g77}.
10387 It is never safe to depend on the order of evaluation of side effects.
10388 For example, an expression like this may very well behave differently
10389 from one compiler to another:
10392 J = IFUNC() - IFUNC()
10396 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
10398 Either invocation might happen first.
10399 If @samp{IFUNC} returns 5 the first time it is invoked, and
10400 returns 12 the second time, @samp{J} might end up with the
10401 value @samp{7}, or it might end up with @samp{-7}.
10403 Generally, in Fortran, procedures with side-effects intended to
10404 be visible to the caller are best designed as @emph{subroutines},
10406 Examples of such side-effects include:
10410 The generation of random numbers
10411 that are intended to influence return values.
10415 (other than internal I/O to local variables).
10418 Updating information in common blocks.
10421 An example of a side-effect that is not intended to be visible
10422 to the caller is a function that maintains a cache of recently
10423 calculated results, intended solely to speed repeated invocations
10424 of the function with identical arguments.
10425 Such a function can be safely used in expressions, because
10426 if the compiler optimizes away one or more calls to the
10427 function, operation of the program is unaffected (aside
10428 from being speeded up).
10430 @node Warnings and Errors
10431 @section Warning Messages and Error Messages
10433 @cindex error messages
10434 @cindex warnings vs errors
10435 @cindex messages, warning and error
10436 The GNU compiler can produce two kinds of diagnostics: errors and
10438 Each kind has a different purpose:
10442 @emph{Errors} report problems that make it impossible to compile your
10444 GNU Fortran reports errors with the source file name, line
10445 number, and column within the line where the problem is apparent.
10448 @emph{Warnings} report other unusual conditions in your code that
10449 @emph{might} indicate a problem, although compilation can (and does)
10451 Warning messages also report the source file name, line number,
10452 and column information,
10453 but include the text @samp{warning:} to distinguish them
10454 from error messages.
10457 Warnings might indicate danger points where you should check to make sure
10458 that your program really does what you intend; or the use of obsolete
10459 features; or the use of nonstandard features of GNU Fortran.
10460 Many warnings are issued only if you ask for them, with one of the
10461 @option{-W} options (for instance, @option{-Wall} requests a variety of
10464 @emph{Note:} Currently, the text of the line and a pointer to the column
10465 is printed in most @command{g77} diagnostics.
10466 Probably, as of version 0.6, @command{g77} will
10467 no longer print the text of the source line, instead printing
10468 the column number following the file name and line number in
10469 a form that GNU Emacs recognizes.
10470 This change is expected to speed up and reduce the memory usage
10471 of the @command{g77} compiler.
10473 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
10475 @c GNU Fortran always tries to compile your program if possible; it never
10476 @c gratuitously rejects a program whose meaning is clear merely because
10477 @c (for instance) it fails to conform to a standard. In some cases,
10478 @c however, the Fortran standard specifies that certain extensions are
10479 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
10480 @c compiler. The @option{-pedantic} option tells GNU Fortran to issue warnings
10481 @c in such cases; @option{-pedantic-errors} says to make them errors instead.
10482 @c This does not mean that @emph{all} non-ANSI constructs get warnings
10485 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
10486 more detail on these and related command-line options.
10488 @node Open Questions
10489 @chapter Open Questions
10491 Please consider offering useful answers to these questions!
10495 @code{LOC()} and other intrinsics are probably somewhat misclassified.
10496 Is the a need for more precise classification of intrinsics, and if so,
10497 what are the appropriate groupings?
10498 Is there a need to individually
10499 enable/disable/delete/hide intrinsics from the command line?
10503 @chapter Reporting Bugs
10505 @cindex reporting bugs
10507 Your bug reports play an essential role in making GNU Fortran reliable.
10509 When you encounter a problem, the first thing to do is to see if it is
10512 If it isn't known, then you should report the problem.
10514 Reporting a bug might help you by bringing a solution to your problem, or
10516 (If it does not, look in the service directory; see
10518 In any case, the principal function of a bug report is
10519 to help the entire community by making the next version of GNU Fortran work
10521 Bug reports are your contribution to the maintenance of GNU Fortran.
10523 Since the maintainers are very overloaded, we cannot respond to every
10525 However, if the bug has not been fixed, we are likely to
10526 send you a patch and ask you to tell us whether it works.
10528 In order for a bug report to serve its purpose, you must include the
10529 information that makes for fixing the bug.
10532 * Criteria: Bug Criteria. Have you really found a bug?
10533 * Where: Bug Lists. Where to send your bug report.
10534 * Reporting: Bug Reporting. How to report a bug effectively.
10537 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
10538 for information on problems we already know about.
10540 @xref{Service,,How To Get Help with GNU Fortran},
10541 for information on where to ask for help.
10544 @section Have You Found a Bug?
10545 @cindex bug criteria
10547 If you are not sure whether you have found a bug, here are some guidelines:
10550 @cindex fatal signal
10553 If the compiler gets a fatal signal, for any input whatever, that is a
10555 Reliable compilers never crash---they just remain obsolete.
10557 @cindex invalid assembly code
10558 @cindex assembly code, invalid
10560 If the compiler produces invalid assembly code, for any input whatever,
10561 @c (except an @code{asm} statement),
10562 that is a compiler bug, unless the
10563 compiler reports errors (not just warnings) which would ordinarily
10564 prevent the assembler from being run.
10566 @cindex undefined behavior
10567 @cindex undefined function value
10569 If the compiler produces valid assembly code that does not correctly
10570 execute the input source code, that is a compiler bug.
10572 However, you must double-check to make sure, because you might have run
10573 into an incompatibility between GNU Fortran and traditional Fortran.
10574 @c (@pxref{Incompatibilities}).
10575 These incompatibilities might be considered
10576 bugs, but they are inescapable consequences of valuable features.
10578 Or you might have a program whose behavior is undefined, which happened
10579 by chance to give the desired results with another Fortran compiler.
10580 It is best to check the relevant Fortran standard thoroughly if
10581 it is possible that the program indeed does something undefined.
10583 After you have localized the error to a single source line, it should
10584 be easy to check for these things.
10585 If your program is correct and well defined, you have found
10588 It might help if, in your submission, you identified the specific
10589 language in the relevant Fortran standard that specifies the
10590 desired behavior, if it isn't likely to be obvious and agreed-upon
10591 by all Fortran users.
10594 If the compiler produces an error message for valid input, that is a
10597 @cindex invalid input
10599 If the compiler does not produce an error message for invalid input,
10600 that is a compiler bug.
10601 However, you should note that your idea of
10602 ``invalid input'' might be someone else's idea
10603 of ``an extension'' or ``support for traditional practice''.
10606 If you are an experienced user of Fortran compilers, your suggestions
10607 for improvement of GNU Fortran are welcome in any case.
10610 Many, perhaps most, bug reports against @command{g77} turn out to
10611 be bugs in the user's code.
10612 While we find such bug reports educational, they sometimes take
10613 a considerable amount of time to track down or at least respond
10614 to---time we could be spending making @command{g77}, not some user's
10617 Some steps you can take to verify that the bug is not certainly
10618 in the code you're compiling with @command{g77}:
10622 Compile your code using the @command{g77} options @samp{-W -Wall -O}.
10623 These options enable many useful warning; the @option{-O} option
10624 enables flow analysis that enables the uninitialized-variable
10627 If you investigate the warnings and find evidence of possible bugs
10628 in your code, fix them first and retry @command{g77}.
10631 Compile your code using the @command{g77} options @option{-finit-local-zero},
10632 @option{-fno-automatic}, @option{-ffloat-store}, and various
10633 combinations thereof.
10635 If your code works with any of these combinations, that is not
10636 proof that the bug isn't in @command{g77}---a @command{g77} bug exposed
10637 by your code might simply be avoided, or have a different, more subtle
10638 effect, when different options are used---but it can be a
10639 strong indicator that your code is making unwarranted assumptions
10640 about the Fortran dialect and/or underlying machine it is
10641 being compiled and run on.
10643 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10644 for information on the @option{-fno-automatic} and
10645 @option{-finit-local-zero} options and how to convert
10646 their use into selective changes in your own code.
10650 Validate your code with @command{ftnchek} or a similar code-checking
10652 @command{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
10653 or @uref{ftp://ftp.dsm.fordham.edu}.
10656 @cindex Makefile example
10657 Here are some sample @file{Makefile} rules using @command{ftnchek}
10658 ``project'' files to do cross-file checking and @command{sfmakedepend}
10659 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
10660 to maintain dependencies automatically.
10661 These assume the use of GNU @command{make}.
10664 # Dummy suffix for ftnchek targets:
10668 # How to compile .f files (for implicit rule):
10670 # Assume `include' directory:
10671 FFLAGS = -Iinclude -g -O -Wall
10673 # Flags for ftnchek:
10674 CHEK1 = -array=0 -include=includes -noarray
10675 CHEK2 = -nonovice -usage=1 -notruncation
10676 CHEKFLAGS = $(CHEK1) $(CHEK2)
10678 # Run ftnchek with all the .prj files except the one corresponding
10679 # to the target's root:
10681 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
10682 -noextern -library $<
10684 # Derive a project file from a source file:
10686 ftnchek $(CHEKFLAGS) -noextern -project -library $<
10688 # The list of objects is assumed to be in variable OBJS.
10689 # Sources corresponding to the objects:
10690 SRCS = $(OBJS:%.o=%.f)
10691 # ftnchek project files:
10692 PRJS = $(OBJS:%.o=%.prj)
10694 # Build the program
10696 $(FC) -o $@ $(OBJS)
10698 chekall: $(PRJS) ; \
10699 ftnchek $(CHEKFLAGS) $(PRJS)
10703 # For Emacs M-x find-tag:
10707 # Rebuild dependencies:
10709 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
10713 Try your code out using other Fortran compilers, such as @command{f2c}.
10714 If it does not work on at least one other compiler (assuming the
10715 compiler supports the features the code needs), that is a strong
10716 indicator of a bug in the code.
10718 However, even if your code works on many compilers @emph{except}
10719 @command{g77}, that does @emph{not} mean the bug is in @command{g77}.
10720 It might mean the bug is in your code, and that @command{g77} simply
10721 exposes it more readily than other compilers.
10725 @section Where to Report Bugs
10726 @cindex bug report mailing lists
10727 @kindex @value{email-bugs}
10728 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
10730 Often people think of posting bug reports to a newsgroup instead of
10732 This sometimes appears to work, but it has one problem which can be
10733 crucial: a newsgroup posting does not contain a mail path back to the
10735 Thus, if maintainers need more information, they might be unable
10736 to reach you. For this reason, you should always send bug reports by
10737 mail to the proper mailing list.
10739 As a last resort, send bug reports on paper to:
10743 Free Software Foundation
10744 59 Temple Place - Suite 330
10745 Boston, MA 02111-1307, USA
10748 @node Bug Reporting
10749 @section How to Report Bugs
10750 @cindex compiler bugs, reporting
10752 The fundamental principle of reporting bugs usefully is this:
10753 @strong{report all the facts}.
10754 If you are not sure whether to state a
10755 fact or leave it out, state it!
10757 Often people omit facts because they think they know what causes the
10758 problem and they conclude that some details don't matter.
10760 assume that the name of the variable you use in an example does not matter.
10761 Well, probably it doesn't, but one cannot be sure.
10762 Perhaps the bug is a
10763 stray memory reference which happens to fetch from the location where that
10764 name is stored in memory; perhaps, if the name were different, the contents
10765 of that location would fool the compiler into doing the right thing despite
10767 Play it safe and give a specific, complete example.
10769 easiest thing for you to do, and the most helpful.
10771 Keep in mind that the purpose of a bug report is to enable someone to
10772 fix the bug if it is not known.
10773 It isn't very important what happens if
10774 the bug is already known.
10775 Therefore, always write your bug reports on
10776 the assumption that the bug is not known.
10778 Sometimes people give a few sketchy facts and ask, ``Does this ring a
10780 This cannot help us fix a bug, so it is rarely helpful.
10781 We respond by asking for enough details to enable us to investigate.
10782 You might as well expedite matters by sending them to begin with.
10783 (Besides, there are enough bells ringing around here as it is.)
10785 Try to make your bug report self-contained.
10786 If we have to ask you for
10787 more information, it is best if you include all the previous information
10788 in your response, as well as the information that was missing.
10790 Please report each bug in a separate message.
10791 This makes it easier for
10792 us to track which bugs have been fixed and to forward your bugs reports
10793 to the appropriate maintainer.
10795 Do not compress and encode any part of your bug report using programs
10796 such as @file{uuencode}.
10797 If you do so it will slow down the processing
10799 If you must submit multiple large files, use @file{shar},
10800 which allows us to read your message without having to run any
10801 decompression programs.
10803 (As a special exception for GNU Fortran bug-reporting, at least
10804 for now, if you are sending more than a few lines of code, if
10805 your program's source file format contains ``interesting'' things
10806 like trailing spaces or strange characters, or if you need to
10807 include binary data files, it is acceptable to put all the
10808 files together in a @command{tar} archive, and, whether you need to
10809 do that, it is acceptable to then compress the single file (@command{tar}
10810 archive or source file)
10811 using @command{gzip} and encode it via @command{uuencode}.
10812 Do not use any MIME stuff---the current maintainer can't decode this.
10813 Using @command{compress} instead of @command{gzip} is acceptable, assuming
10814 you have licensed the use of the patented algorithm in
10815 @command{compress} from Unisys.)
10817 To enable someone to investigate the bug, you should include all these
10822 The version of GNU Fortran.
10823 You can get this by running @command{g77} with the @option{-v} option.
10824 (Ignore any error messages that might be displayed
10825 when the linker is run.)
10827 Without this, we won't know whether there is any point in looking for
10828 the bug in the current version of GNU Fortran.
10831 @cindex preprocessor
10832 @cindex cpp program
10833 @cindex programs, cpp
10835 A complete input file that will reproduce the bug.
10837 If your source file(s) require preprocessing
10838 (for example, their names have suffixes like
10839 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
10840 and the bug is in the compiler proper (@file{f771})
10841 or in a subsequent phase of processing,
10842 run your source file through the C preprocessor
10843 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
10844 Then, include the contents of @var{newfile} in the bug report.
10845 (When you do this, use the same preprocessor options---such as
10846 @option{-I}, @option{-D}, and @option{-U}---that you used in actual
10849 A single statement is not enough of an example.
10850 In order to compile it,
10851 it must be embedded in a complete file of compiler input.
10852 The bug might depend on the details of how this is done.
10854 Without a real example one can compile,
10855 all anyone can do about your bug report is wish you luck.
10856 It would be futile to try to guess how to provoke the bug.
10857 For example, bugs in register allocation and reloading
10858 can depend on every little detail of the source and include files
10862 @cindex included files
10863 @cindex INCLUDE directive
10864 @cindex directive, INCLUDE
10865 @cindex #include directive
10866 @cindex directive, #include
10867 Note that you should include with your bug report any files
10868 included by the source file
10869 (via the @code{#include} or @code{INCLUDE} directive)
10870 that you send, and any files they include, and so on.
10872 It is not necessary to replace
10873 the @code{#include} and @code{INCLUDE} directives
10874 with the actual files in the version of the source file that
10875 you send, but it might make submitting the bug report easier
10877 However, be sure to @emph{reproduce} the bug using the @emph{exact}
10878 version of the source material you submit, to avoid wild-goose
10882 The command arguments you gave GNU Fortran to compile that example
10883 and observe the bug. For example, did you use @option{-O}? To guarantee
10884 you won't omit something important, list all the options.
10886 If we were to try to guess the arguments, we would probably guess wrong
10887 and then we would not encounter the bug.
10890 The type of machine you are using, and the operating system name and
10892 (Much of this information is printed by @samp{g77 -v}---if you
10893 include that, send along any additional info you have that you
10894 don't see clearly represented in that output.)
10897 The operands you gave to the @command{configure} command when you installed
10901 A complete list of any modifications you have made to the compiler
10902 source. (We don't promise to investigate the bug unless it happens in
10903 an unmodified compiler. But if you've made modifications and don't tell
10904 us, then you are sending us on a wild-goose chase.)
10906 Be precise about these changes. A description in English is not
10907 enough---send a context diff for them.
10909 Adding files of your own (such as a machine description for a machine we
10910 don't support) is a modification of the compiler source.
10913 Details of any other deviations from the standard procedure for installing
10917 A description of what behavior you observe that you believe is
10918 incorrect. For example, ``The compiler gets a fatal signal,'' or,
10919 ``The assembler instruction at line 208 in the output is incorrect.''
10921 Of course, if the bug is that the compiler gets a fatal signal, then one
10922 can't miss it. But if the bug is incorrect output, the maintainer might
10923 not notice unless it is glaringly wrong. None of us has time to study
10924 all the assembler code from a 50-line Fortran program just on the chance that
10925 one instruction might be wrong. We need @emph{you} to do this part!
10927 Even if the problem you experience is a fatal signal, you should still
10928 say so explicitly. Suppose something strange is going on, such as, your
10929 copy of the compiler is out of synch, or you have encountered a bug in
10930 the C library on your system. (This has happened!) Your copy might
10931 crash and the copy here would not. If you @i{said} to expect a crash,
10932 then when the compiler here fails to crash, we would know that the bug
10933 was not happening. If you don't say to expect a crash, then we would
10934 not know whether the bug was happening. We would not be able to draw
10935 any conclusion from our observations.
10937 If the problem is a diagnostic when building GNU Fortran with some other
10938 compiler, say whether it is a warning or an error.
10940 Often the observed symptom is incorrect output when your program is run.
10941 Sad to say, this is not enough information unless the program is short
10942 and simple. None of us has time to study a large program to figure out
10943 how it would work if compiled correctly, much less which line of it was
10944 compiled wrong. So you will have to do that. Tell us which source line
10945 it is, and what incorrect result happens when that line is executed. A
10946 person who understands the program can find this as easily as finding a
10947 bug in the program itself.
10950 If you send examples of assembler code output from GNU Fortran,
10951 please use @option{-g} when you make them. The debugging information
10952 includes source line numbers which are essential for correlating the
10953 output with the input.
10956 If you wish to mention something in the GNU Fortran source, refer to it by
10957 context, not by line number.
10959 The line numbers in the development sources don't match those in your
10960 sources. Your line numbers would convey no convenient information to the
10964 Additional information from a debugger might enable someone to find a
10965 problem on a machine which he does not have available. However, you
10966 need to think when you collect this information if you want it to have
10967 any chance of being useful.
10969 @cindex backtrace for bug reports
10970 For example, many people send just a backtrace, but that is never
10971 useful by itself. A simple backtrace with arguments conveys little
10972 about GNU Fortran because the compiler is largely data-driven; the same
10973 functions are called over and over for different RTL insns, doing
10974 different things depending on the details of the insn.
10976 Most of the arguments listed in the backtrace are useless because they
10977 are pointers to RTL list structure. The numeric values of the
10978 pointers, which the debugger prints in the backtrace, have no
10979 significance whatever; all that matters is the contents of the objects
10980 they point to (and most of the contents are other such pointers).
10982 In addition, most compiler passes consist of one or more loops that
10983 scan the RTL insn sequence. The most vital piece of information about
10984 such a loop---which insn it has reached---is usually in a local variable,
10985 not in an argument.
10988 What you need to provide in addition to a backtrace are the values of
10989 the local variables for several stack frames up. When a local
10990 variable or an argument is an RTX, first print its value and then use
10991 the GDB command @command{pr} to print the RTL expression that it points
10992 to. (If GDB doesn't run on your machine, use your debugger to call
10993 the function @code{debug_rtx} with the RTX as an argument.) In
10994 general, whenever a variable is a pointer, its value is no use
10995 without the data it points to.
10998 Here are some things that are not necessary:
11002 A description of the envelope of the bug.
11004 Often people who encounter a bug spend a lot of time investigating
11005 which changes to the input file will make the bug go away and which
11006 changes will not affect it.
11008 This is often time consuming and not very useful, because the way we
11009 will find the bug is by running a single example under the debugger with
11010 breakpoints, not by pure deduction from a series of examples. You might
11011 as well save your time for something else.
11013 Of course, if you can find a simpler example to report @emph{instead} of
11014 the original one, that is a convenience. Errors in the output will be
11015 easier to spot, running under the debugger will take less time, etc.
11016 Most GNU Fortran bugs involve just one function, so the most straightforward
11017 way to simplify an example is to delete all the function definitions
11018 except the one where the bug occurs. Those earlier in the file may be
11019 replaced by external declarations if the crucial function depends on
11020 them. (Exception: inline functions might affect compilation of functions
11021 defined later in the file.)
11023 However, simplification is not vital; if you don't want to do this,
11024 report the bug anyway and send the entire test case you used.
11027 In particular, some people insert conditionals @samp{#ifdef BUG} around
11028 a statement which, if removed, makes the bug not happen. These are just
11029 clutter; we won't pay any attention to them anyway. Besides, you should
11030 send us preprocessor output, and that can't have conditionals.
11033 A patch for the bug.
11035 A patch for the bug is useful if it is a good one. But don't omit the
11036 necessary information, such as the test case, on the assumption that a
11037 patch is all we need. We might see problems with your patch and decide
11038 to fix the problem another way, or we might not understand it at all.
11040 Sometimes with a program as complicated as GNU Fortran it is very hard to
11041 construct an example that will make the program follow a certain path
11042 through the code. If you don't send the example, we won't be able to
11043 construct one, so we won't be able to verify that the bug is fixed.
11045 And if we can't understand what bug you are trying to fix, or why your
11046 patch should be an improvement, we won't install it. A test case will
11047 help us to understand.
11049 See @uref{http://gcc.gnu.org/contribute.html}
11050 for guidelines on how to make it easy for us to
11051 understand and install your patches.
11054 A guess about what the bug is or what it depends on.
11056 Such guesses are usually wrong. Even the maintainer can't guess right
11057 about such things without first using the debugger to find the facts.
11062 We have no way of examining a core dump for your type of machine
11063 unless we have an identical system---and if we do have one,
11064 we should be able to reproduce the crash ourselves.
11068 @chapter How To Get Help with GNU Fortran
11070 If you need help installing, using or changing GNU Fortran, there are two
11075 Look in the service directory for someone who might help you for a fee.
11076 The service directory is found in the file named @file{SERVICE} in the
11077 GNU CC distribution.
11080 Send a message to @email{@value{email-help}}.
11085 @node Adding Options
11086 @chapter Adding Options
11087 @cindex options, adding
11088 @cindex adding options
11090 To add a new command-line option to @command{g77}, first decide
11091 what kind of option you wish to add.
11092 Search the @command{g77} and @command{gcc} documentation for one
11093 or more options that is most closely like the one you want to add
11094 (in terms of what kind of effect it has, and so on) to
11095 help clarify its nature.
11099 @emph{Fortran options} are options that apply only
11100 when compiling Fortran programs.
11101 They are accepted by @command{g77} and @command{gcc}, but
11102 they apply only when compiling Fortran programs.
11105 @emph{Compiler options} are options that apply
11106 when compiling most any kind of program.
11109 @emph{Fortran options} are listed in the file
11110 @file{@value{path-g77}/lang-options.h},
11111 which is used during the build of @command{gcc} to
11112 build a list of all options that are accepted by
11113 at least one language's compiler.
11114 This list goes into the @code{documented_lang_options} array
11115 in @file{gcc/toplev.c}, which uses this array to
11116 determine whether a particular option should be
11117 offered to the linked-in front end for processing
11118 by calling @code{lang_option_decode}, which, for
11119 @command{g77}, is in @file{@value{path-g77}/com.c} and just
11120 calls @code{ffe_decode_option}.
11122 If the linked-in front end ``rejects'' a
11123 particular option passed to it, @file{toplev.c}
11124 just ignores the option, because @emph{some}
11125 language's compiler is willing to accept it.
11127 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
11128 to work, even though Fortran compilation does
11129 not currently support the @option{-fno-asm} option;
11130 even though the @code{f771} version of @code{lang_decode_option}
11131 rejects @option{-fno-asm}, @file{toplev.c} doesn't
11132 produce a diagnostic because some other language (C)
11135 This also means that commands like
11136 @samp{g77 -fno-asm foo.f} yield no diagnostics,
11137 despite the fact that no phase of the command was
11138 able to recognize and process @option{-fno-asm}---perhaps
11139 a warning about this would be helpful if it were
11142 Code that processes Fortran options is found in
11143 @file{@value{path-g77}/top.c}, function @code{ffe_decode_option}.
11144 This code needs to check positive and negative forms
11147 The defaults for Fortran options are set in their
11148 global definitions, also found in @file{@value{path-g77}/top.c}.
11149 Many of these defaults are actually macros defined
11150 in @file{@value{path-g77}/target.h}, since they might be
11152 However, since, in practice, GNU compilers
11153 should behave the same way on all configurations
11154 (especially when it comes to language constructs),
11155 the practice of setting defaults in @file{target.h}
11156 is likely to be deprecated and, ultimately, stopped
11157 in future versions of @command{g77}.
11159 Accessor macros for Fortran options, used by code
11160 in the @command{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
11162 @emph{Compiler options} are listed in @file{gcc/toplev.c}
11163 in the array @code{f_options}.
11164 An option not listed in @code{lang_options} is
11165 looked up in @code{f_options} and handled from there.
11167 The defaults for compiler options are set in the
11168 global definitions for the corresponding variables,
11169 some of which are in @file{gcc/toplev.c}.
11171 You can set different defaults for @emph{Fortran-oriented}
11172 or @emph{Fortran-reticent} compiler options by changing
11173 the source code of @command{g77} and rebuilding.
11174 How to do this depends on the version of @command{g77}:
11177 @item G77 0.5.24 (EGCS 1.1)
11178 @itemx G77 0.5.25 (EGCS 1.2 - which became GCC 2.95)
11179 Change the @code{lang_init_options} routine in @file{gcc/gcc/f/com.c}.
11181 (Note that these versions of @command{g77}
11182 perform internal consistency checking automatically
11183 when the @option{-fversion} option is specified.)
11186 @itemx G77 0.5.24 (EGCS 1.0)
11187 Change the way @code{f771} handles the @option{-fset-g77-defaults}
11188 option, which is always provided as the first option when
11189 called by @command{g77} or @command{gcc}.
11191 This code is in @code{ffe_decode_options} in @file{@value{path-g77}/top.c}.
11192 Have it change just the variables that you want to default
11193 to a different setting for Fortran compiles compared to
11194 compiles of other languages.
11196 The @option{-fset-g77-defaults} option is passed to @code{f771}
11197 automatically because of the specification information
11198 kept in @file{@value{path-g77}/lang-specs.h}.
11199 This file tells the @command{gcc} command how to recognize,
11200 in this case, Fortran source files (those to be preprocessed,
11201 and those that are not), and further, how to invoke the
11202 appropriate programs (including @code{f771}) to process
11203 those source files.
11205 It is in @file{@value{path-g77}/lang-specs.h} that @option{-fset-g77-defaults},
11206 @option{-fversion}, and other options are passed, as appropriate,
11207 even when the user has not explicitly specified them.
11208 Other ``internal'' options such as @option{-quiet} also
11209 are passed via this mechanism.
11216 If you want to contribute to @command{g77} by doing research,
11217 design, specification, documentation, coding, or testing,
11218 the following information should give you some ideas.
11219 More relevant information might be available from
11220 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
11223 * Efficiency:: Make @command{g77} itself compile code faster.
11224 * Better Optimization:: Teach @command{g77} to generate faster code.
11225 * Simplify Porting:: Make @command{g77} easier to configure, build,
11227 * More Extensions:: Features many users won't know to ask for.
11228 * Machine Model:: @command{g77} should better leverage @command{gcc}.
11229 * Internals Documentation:: Make maintenance easier.
11230 * Internals Improvements:: Make internals more robust.
11231 * Better Diagnostics:: Make using @command{g77} on new code easier.
11235 @section Improve Efficiency
11238 Don't bother doing any performance analysis until most of the
11239 following items are taken care of, because there's no question
11240 they represent serious space/time problems, although some of
11241 them show up only given certain kinds of (popular) input.
11245 Improve @code{malloc} package and its uses to specify more info about
11246 memory pools and, where feasible, use obstacks to implement them.
11249 Skip over uninitialized portions of aggregate areas (arrays,
11250 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
11251 This would reduce memory usage for large initialized aggregate
11252 areas, even ones with only one initialized element.
11254 As of version 0.5.18, a portion of this item has already been
11258 Prescan the statement (in @file{sta.c}) so that the nature of the statement
11259 is determined as much as possible by looking entirely at its form,
11260 and not looking at any context (previous statements, including types
11262 This would allow ripping out of the statement-confirmation,
11263 symbol retraction/confirmation, and diagnostic inhibition
11265 Plus, it would result in much-improved diagnostics.
11266 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
11267 is not a subroutine intrinsic, would result actual error instead of the
11268 unimplemented-statement catch-all.
11271 Throughout @command{g77}, don't pass line/column pairs where
11272 a simple @code{ffewhere} type, which points to the error as much as is
11273 desired by the configuration, will do, and don't pass @code{ffelexToken} types
11274 where a simple @code{ffewhere} type will do.
11275 Then, allow new default
11276 configuration of @code{ffewhere} such that the source line text is not
11277 preserved, and leave it to things like Emacs' next-error function
11278 to point to them (now that @samp{next-error} supports column,
11279 or, perhaps, character-offset, numbers).
11280 The change in calling sequences should improve performance somewhat,
11281 as should not having to save source lines.
11282 (Whether this whole
11283 item will improve performance is questionable, but it should
11284 improve maintainability.)
11287 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
11288 as regards the assembly output.
11289 Some of this might require improving
11290 the back end, but lots of improvement in space/time required in @command{g77}
11291 itself can be fairly easily obtained without touching the back end.
11292 Maybe type-conversion, where necessary, can be speeded up as well in
11293 cases like the one shown (converting the @samp{2} into @samp{2.}).
11296 If analysis shows it to be worthwhile, optimize @file{lex.c}.
11299 Consider redesigning @file{lex.c} to not need any feedback
11300 during tokenization, by keeping track of enough parse state on its
11304 @node Better Optimization
11305 @section Better Optimization
11306 @cindex optimization, better
11307 @cindex code generation, improving
11309 Much of this work should be put off until after @command{g77} has
11310 all the features necessary for its widespread acceptance as a
11311 useful F77 compiler.
11312 However, perhaps this work can be done in parallel during
11313 the feature-adding work.
11317 Do the equivalent of the trick of putting @samp{extern inline} in front
11318 of every function definition in @code{libg2c} and #include'ing the resulting
11319 file in @command{f2c}+@command{gcc}---that is, inline all run-time-library functions
11320 that are at all worth inlining.
11321 (Some of this has already been done, such as for integral exponentiation.)
11324 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
11325 and it's clear that types line up
11326 and @samp{CHAR_VAR} is addressable or not a @code{VAR_DECL},
11327 make @samp{CHAR_VAR}, not a
11328 temporary, be the receiver for @samp{CHAR_FUNC}.
11329 (This is now done for @code{COMPLEX} variables.)
11332 Design and implement Fortran-specific optimizations that don't
11333 really belong in the back end, or where the front end needs to
11334 give the back end more info than it currently does.
11337 Design and implement a new run-time library interface, with the
11338 code going into @code{libgcc} so no special linking is required to
11339 link Fortran programs using standard language features.
11341 would speed up lots of things, from I/O (using precompiled formats,
11342 doing just one, or, at most, very few, calls for arrays or array sections,
11343 and so on) to general computing (array/section implementations of
11344 various intrinsics, implementation of commonly performed loops that
11345 aren't likely to be optimally compiled otherwise, etc.).
11347 Among the important things the library would do are:
11351 Be a one-stop-shop-type
11352 library, hence shareable and usable by all, in that what are now
11353 library-build-time options in @code{libg2c} would be moved at least to the
11354 @command{g77} compile phase, if not to finer grains (such as choosing how
11355 list-directed I/O formatting is done by default at @code{OPEN} time, for
11356 preconnected units via options or even statements in the main program
11357 unit, maybe even on a per-I/O basis with appropriate pragma-like
11362 Probably requiring the new library design, change interface to
11363 normally have @code{COMPLEX} functions return their values in the way
11364 @command{gcc} would if they were declared @code{__complex__ float},
11366 the mechanism currently used by @code{CHARACTER} functions (whereby the
11367 functions are compiled as returning void and their first arg is
11368 a pointer to where to store the result).
11369 (Don't append underscores to
11370 external names for @code{COMPLEX} functions in some cases once @command{g77} uses
11371 @command{gcc} rather than @command{f2c} calling conventions.)
11374 Do something useful with @code{doiter} references where possible.
11375 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
11376 a @code{DO} loop that uses @samp{I} as the
11377 iteration variable, and the back end might find that info useful
11378 in determining whether it needs to read @samp{I} back into a register after
11380 (It normally has to do that, unless it knows @samp{FOO} never
11381 modifies its passed-by-reference argument, which is rarely the case
11382 for Fortran-77 code.)
11385 @node Simplify Porting
11386 @section Simplify Porting
11387 @cindex porting, simplify
11388 @cindex simplify porting
11390 Making @command{g77} easier to configure, port, build, and install, either
11391 as a single-system compiler or as a cross-compiler, would be
11396 A new library (replacing @code{libg2c}) should improve portability as well as
11397 produce more optimal code.
11398 Further, @command{g77} and the new library should
11399 conspire to simplify naming of externals, such as by removing unnecessarily
11400 added underscores, and to reduce/eliminate the possibility of naming
11401 conflicts, while making debugger more straightforward.
11404 make multi-language applications more feasible, such as by providing
11405 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
11409 Possibly related to a new library, @command{g77} should produce the equivalent
11410 of a @command{gcc} @samp{main(argc, argv)} function when it compiles a
11411 main program unit, instead of compiling something that must be
11412 called by a library
11413 implementation of @code{main()}.
11415 This would do many useful things such as
11416 provide more flexibility in terms of setting up exception handling,
11417 not requiring programmers to start their debugging sessions with
11418 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
11421 The GBE needs to understand the difference between alignment
11422 requirements and desires.
11423 For example, on Intel x86 machines, @command{g77} currently imposes
11424 overly strict alignment requirements, due to the back end, but it
11425 would be useful for Fortran and C programmers to be able to override
11426 these @emph{recommendations} as long as they don't violate the actual
11427 processor @emph{requirements}.
11430 @node More Extensions
11431 @section More Extensions
11432 @cindex extensions, more
11434 These extensions are not the sort of things users ask for ``by name'',
11435 but they might improve the usability of @command{g77}, and Fortran in
11436 general, in the long run.
11437 Some of these items really pertain to improving @command{g77} internals
11438 so that some popular extensions can be more easily supported.
11442 Look through all the documentation on the GNU Fortran language,
11443 dialects, compiler, missing features, bugs, and so on.
11444 Many mentions of incomplete or missing features are
11445 sprinkled throughout.
11446 It is not worth repeating them here.
11449 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
11451 The idea is to provide a forward-looking, effective
11452 replacement for things like the old-style @code{PARAMETER} statement
11454 really need typelessness in a maintainable, portable, clearly documented
11456 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
11457 and whatever else might come along.
11458 (This is not really a call for polymorphism per se, just
11459 an ability to express limited, syntactic polymorphism.)
11462 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
11465 Support arbitrary file unit numbers, instead of limiting them
11466 to 0 through @samp{MXUNIT-1}.
11467 (This is a @code{libg2c} issue.)
11470 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
11471 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
11472 later @code{UNIT=} in the first example is invalid.
11473 Make sure this is what users of this feature would expect.
11476 Currently @command{g77} disallows @samp{READ(1'10)} since
11477 it is an obnoxious syntax, but
11478 supporting it might be pretty easy if needed.
11479 More details are needed, such
11480 as whether general expressions separated by an apostrophe are supported,
11481 or maybe the record number can be a general expression, and so on.
11484 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
11486 Currently there is no support at all
11487 for @code{%FILL} in @code{STRUCTURE} and related syntax,
11488 whereas the rest of the
11489 stuff has at least some parsing support.
11490 This requires either major
11491 changes to @code{libg2c} or its replacement.
11494 F90 and @command{g77} probably disagree about label scoping relative to
11495 @code{INTERFACE} and @code{END INTERFACE}, and their contained
11496 procedure interface bodies (blocks?).
11499 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
11500 since that was added after S8.112.
11503 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
11504 with the final form of the standard (it was vague at S8.112).
11507 It seems to be an ``open'' question whether a file, immediately after being
11508 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
11509 might be nice to offer an option of opening to ``undefined'' status, requiring
11510 an explicit absolute-positioning operation to be performed before any
11511 other (besides @code{CLOSE}) to assist in making applications port to systems
11512 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
11515 @node Machine Model
11516 @section Machine Model
11518 This items pertain to generalizing @command{g77}'s view of
11519 the machine model to more fully accept whatever the GBE
11520 provides it via its configuration.
11524 Switch to using @code{REAL_VALUE_TYPE} to represent floating-point constants
11525 exclusively so the target float format need not be required.
11527 means changing the way @command{g77} handles initialization of aggregate areas
11528 having more than one type, such as @code{REAL} and @code{INTEGER},
11530 it initializes them as if they were arrays of @code{char} and uses the
11531 bit patterns of the constants of the various types in them to determine
11532 what to stuff in elements of the arrays.
11535 Rely more and more on back-end info and capabilities, especially in the
11536 area of constants (where having the @command{g77} front-end's IL just store
11537 the appropriate tree nodes containing constants might be best).
11540 Suite of C and Fortran programs that a user/administrator can run on a
11541 machine to help determine the configuration for @command{g77} before building
11542 and help determine if the compiler works (especially with whatever
11543 libraries are installed) after building.
11546 @node Internals Documentation
11547 @section Internals Documentation
11549 Better info on how @command{g77} works and how to port it is needed.
11550 Much of this should be done only after the redesign planned for
11553 @xref{Front End}, which contains some information
11554 on @command{g77} internals.
11556 @node Internals Improvements
11557 @section Internals Improvements
11559 Some more items that would make @command{g77} more reliable
11560 and easier to maintain:
11564 Generally make expression handling focus
11565 more on critical syntax stuff, leaving semantics to callers.
11567 anything a caller can check, semantically, let it do so, rather
11568 than having @file{expr.c} do it.
11569 (Exceptions might include things like
11570 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
11572 important to preserve the left-to-right-in-source order of production
11576 Come up with better naming conventions for @option{-D} to establish requirements
11577 to achieve desired implementation dialect via @file{proj.h}.
11580 Clean up used tokens and @code{ffewhere}s in @code{ffeglobal_terminate_1}.
11583 Replace @file{sta.c} @code{outpooldisp} mechanism with @code{malloc_pool_use}.
11586 Check for @code{opANY} in more places in @file{com.c}, @file{std.c},
11587 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
11588 (after determining if there is indeed no real need for it).
11591 Utility to read and check @file{bad.def} messages and their references in the
11592 code, to make sure calls are consistent with message templates.
11595 Search and fix @samp{&ffe@dots{}} and similar so that
11596 @samp{ffe@dots{}ptr@dots{}} macros are
11597 available instead (a good argument for wishing this could have written all
11598 this stuff in C++, perhaps).
11599 On the other hand, it's questionable whether this sort of
11600 improvement is really necessary, given the availability of
11601 tools such as Emacs and Perl, which make finding any
11602 address-taking of structure members easy enough?
11605 Some modules truly export the member names of their structures (and the
11606 structures themselves), maybe fix this, and fix other modules that just
11607 appear to as well (by appending @samp{_}, though it'd be ugly and probably
11608 not worth the time).
11611 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
11613 and use them throughout @command{g77} source code (especially in the definitions
11614 of access macros in @samp{.h} files) so they can be tailored
11615 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
11618 Decorate throughout with @code{const} and other such stuff.
11621 All F90 notational derivations in the source code are still based
11622 on the S8.112 version of the draft standard.
11623 Probably should update
11624 to the official standard, or put documentation of the rules as used
11625 in the code@dots{}uh@dots{}in the code.
11628 Some @code{ffebld_new} calls (those outside of @file{ffeexpr.c} or
11629 inside but invoked via paths not involving @code{ffeexpr_lhs} or
11630 @code{ffeexpr_rhs}) might be creating things
11631 in improper pools, leading to such things staying around too long or
11632 (doubtful, but possible and dangerous) not long enough.
11635 Some @code{ffebld_list_new} (or whatever) calls might not be matched by
11636 @code{ffebld_list_bottom} (or whatever) calls, which might someday matter.
11637 (It definitely is not a problem just yet.)
11640 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
11641 due to alignment/mismatch or other problems---they end up without
11642 @code{ffestorag} objects, so maybe the backend (and other parts of the front
11643 end) can notice that and handle like an @code{opANY} (do what it wants, just
11644 don't complain or crash).
11645 Most of this seems to have been addressed
11646 by now, but a code review wouldn't hurt.
11649 @node Better Diagnostics
11650 @section Better Diagnostics
11652 These are things users might not ask about, or that need to
11653 be looked into, before worrying about.
11654 Also here are items that involve reducing unnecessary diagnostic
11659 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
11660 lengths, type classes, and so on),
11661 @code{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
11665 Speed up and improve error handling for data when repeat-count is
11667 For example, don't output 20 unnecessary messages after the
11668 first necessary one for:
11673 DATA (X(I), J= 1, 20) /20*5/
11678 (The @code{CONTINUE} statement ensures the @code{DATA} statement
11679 is processed in the context of executable, not specification,
11689 @chapter Diagnostics
11690 @cindex diagnostics
11692 Some diagnostics produced by @command{g77} require sufficient explanation
11693 that the explanations are given below, and the diagnostics themselves
11694 identify the appropriate explanation.
11696 Identification uses the GNU Info format---specifically, the @command{info}
11697 command that displays the explanation is given within square
11698 brackets in the diagnostic.
11702 foo.f:5: Invalid statement [info -f g77 M FOOEY]
11705 More details about the above diagnostic is found in the @command{g77} Info
11706 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
11707 which is displayed by typing the UNIX command
11708 @samp{info -f g77 M FOOEY}.
11710 Other Info readers, such as EMACS, may be just as easily used to display
11711 the pertinent node.
11712 In the above example, @samp{g77} is the Info document name,
11713 @samp{M} is the top-level menu item to select,
11714 and, in that node (named @samp{Diagnostics}, the name of
11715 this chapter, which is the very text you're reading now),
11716 @samp{FOOEY} is the menu item to select.
11719 In this printed version of the @command{g77} manual, the above example
11720 points to a section, below, entitled @samp{FOOEY}---though, of course,
11721 as the above is just a sample, no such section exists.
11725 * CMPAMBIG:: Ambiguous use of intrinsic.
11726 * EXPIMP:: Intrinsic used explicitly and implicitly.
11727 * INTGLOB:: Intrinsic also used as name of global.
11728 * LEX:: Various lexer messages
11729 * GLOBALS:: Disagreements about globals.
11730 * LINKFAIL:: When linking @code{f771} fails.
11731 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
11735 @section @code{CMPAMBIG}
11739 Ambiguous use of intrinsic @var{intrinsic} @dots{}
11742 The type of the argument to the invocation of the @var{intrinsic}
11743 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
11744 Typically, it is @code{COMPLEX(KIND=2)}, also known as
11745 @code{DOUBLE COMPLEX}.
11747 The interpretation of this invocation depends on the particular
11748 dialect of Fortran for which the code was written.
11749 Some dialects convert the real part of the argument to
11750 @code{REAL(KIND=1)}, thus losing precision; other dialects,
11751 and Fortran 90, do no such conversion.
11753 So, GNU Fortran rejects such invocations except under certain
11754 circumstances, to avoid making an incorrect assumption that results
11755 in generating the wrong code.
11757 To determine the dialect of the program unit, perhaps even whether
11758 that particular invocation is properly coded, determine how the
11759 result of the intrinsic is used.
11761 The result of @var{intrinsic} is expected (by the original programmer)
11762 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
11766 It is passed as an argument to a procedure that explicitly or
11767 implicitly declares that argument @code{REAL(KIND=1)}.
11770 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
11771 statement specifying the dummy argument corresponding to an
11772 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
11773 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
11774 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
11775 of @code{REAL(KIND=2)}.
11778 It is used in a context that would otherwise not include
11779 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
11780 invocation as @code{REAL(KIND=2)} would result in unnecessary
11781 promotions and (typically) more expensive operations on the
11792 The above example suggests the programmer expected the real part
11793 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
11794 multiplied by @samp{T} (presumed, along with @samp{R} above, to
11795 be type @code{REAL(KIND=1)}).
11797 Otherwise, the conversion would have to be delayed until after
11798 the multiplication, requiring not only an extra conversion
11799 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
11800 expensive multiplication (a double-precision multiplication instead
11801 of a single-precision one).
11804 The result of @var{intrinsic} is expected (by the original programmer)
11805 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
11809 It is passed as an argument to a procedure that explicitly or
11810 implicitly declares that argument @code{REAL(KIND=2)}.
11812 For example, a procedure specifying a @code{DOUBLE PRECISION}
11813 dummy argument corresponding to an
11814 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
11815 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
11816 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
11817 of @code{REAL(KIND=1)}.
11820 It is used in an expression context that includes
11821 other @code{REAL(KIND=2)} operands,
11822 or is assigned to a @code{REAL(KIND=2)} variable or array element.
11828 DOUBLE PRECISION R, T
11833 The above example suggests the programmer expected the real part
11834 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
11835 by the @code{REAL()} intrinsic.
11837 Otherwise, the conversion would have to be immediately followed
11838 by a conversion back to @code{REAL(KIND=2)}, losing
11839 the original, full precision of the real part of @code{Z},
11840 before being multiplied by @samp{T}.
11843 Once you have determined whether a particular invocation of @var{intrinsic}
11844 expects the Fortran 90 interpretation, you can:
11848 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
11849 @code{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
11851 if it expected the Fortran 90 interpretation.
11853 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
11854 some other type, such as @code{COMPLEX*32}, you should use the
11855 appropriate intrinsic, such as the one to convert to @code{REAL*16}
11856 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
11857 @code{QIMAG()} in place of @code{DIMAG()}).
11860 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
11862 This converts to @code{REAL(KIND=1)} in all working
11866 If you don't want to change the code, and you are certain that all
11867 ambiguous invocations of @var{intrinsic} in the source file have
11868 the same expectation regarding interpretation, you can:
11872 Compile with the @command{g77} option @option{-ff90}, to enable the
11873 Fortran 90 interpretation.
11876 Compile with the @command{g77} options @samp{-fno-f90 -fugly-complex},
11877 to enable the non-Fortran-90 interpretations.
11880 @xref{REAL() and AIMAG() of Complex}, for more information on this
11883 Note: If the above suggestions don't produce enough evidence
11884 as to whether a particular program expects the Fortran 90
11885 interpretation of this ambiguous invocation of @var{intrinsic},
11886 there is one more thing you can try.
11888 If you have access to most or all the compilers used on the
11889 program to create successfully tested and deployed executables,
11890 read the documentation for, and @emph{also} test out, each compiler
11891 to determine how it treats the @var{intrinsic} intrinsic in
11893 (If all the compilers don't agree on an interpretation, there
11894 might be lurking bugs in the deployed versions of the program.)
11896 The following sample program might help:
11898 @cindex JCB003 program
11902 C Written by James Craig Burley 1997-02-23.
11904 C Determine how compilers handle non-standard REAL
11905 C and AIMAG on DOUBLE COMPLEX operands.
11913 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
11914 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
11918 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
11919 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
11922 C Just to make sure compiler doesn't use naive flow
11923 C analysis to optimize away careful work above,
11924 C which might invalidate results....
11926 SUBROUTINE DUMDUM(Z, R)
11932 If the above program prints contradictory results on a
11933 particular compiler, run away!
11936 @section @code{EXPIMP}
11940 Intrinsic @var{intrinsic} referenced @dots{}
11943 The @var{intrinsic} is explicitly declared in one program
11944 unit in the source file and implicitly used as an intrinsic
11945 in another program unit in the same source file.
11947 This diagnostic is designed to catch cases where a program
11948 might depend on using the name @var{intrinsic} as an intrinsic
11949 in one program unit and as a global name (such as the name
11950 of a subroutine or function) in another, but @command{g77} recognizes
11951 the name as an intrinsic in both cases.
11953 After verifying that the program unit making implicit use
11954 of the intrinsic is indeed written expecting the intrinsic,
11955 add an @samp{INTRINSIC @var{intrinsic}} statement to that
11956 program unit to prevent this warning.
11958 This and related warnings are disabled by using
11959 the @option{-Wno-globals} option when compiling.
11961 Note that this warning is not issued for standard intrinsics.
11962 Standard intrinsics include those described in the FORTRAN 77
11963 standard and, if @option{-ff90} is specified, those described
11964 in the Fortran 90 standard.
11965 Such intrinsics are not as likely to be confused with user
11966 procedures as intrinsics provided as extensions to the
11967 standard by @command{g77}.
11970 @section @code{INTGLOB}
11974 Same name `@var{intrinsic}' given @dots{}
11977 The name @var{intrinsic} is used for a global entity (a common
11978 block or a program unit) in one program unit and implicitly
11979 used as an intrinsic in another program unit.
11981 This diagnostic is designed to catch cases where a program
11982 intends to use a name entirely as a global name, but @command{g77}
11983 recognizes the name as an intrinsic in the program unit that
11984 references the name, a situation that would likely produce
11990 INTEGER FUNCTION TIME()
11996 PRINT *, 'Time is ', TIME()
12000 The above example defines a program unit named @samp{TIME}, but
12001 the reference to @samp{TIME} in the main program unit @samp{SAMP}
12002 is normally treated by @command{g77} as a reference to the intrinsic
12003 @code{TIME()} (unless a command-line option that prevents such
12004 treatment has been specified).
12006 As a result, the program @samp{SAMP} will @emph{not}
12007 invoke the @samp{TIME} function in the same source file.
12009 Since @command{g77} recognizes @code{libU77} procedures as
12010 intrinsics, and since some existing code uses the same names
12011 for its own procedures as used by some @code{libU77}
12012 procedures, this situation is expected to arise often enough
12013 to make this sort of warning worth issuing.
12015 After verifying that the program unit making implicit use
12016 of the intrinsic is indeed written expecting the intrinsic,
12017 add an @samp{INTRINSIC @var{intrinsic}} statement to that
12018 program unit to prevent this warning.
12020 Or, if you believe the program unit is designed to invoke the
12021 program-defined procedure instead of the intrinsic (as
12022 recognized by @command{g77}), add an @samp{EXTERNAL @var{intrinsic}}
12023 statement to the program unit that references the name to
12024 prevent this warning.
12026 This and related warnings are disabled by using
12027 the @option{-Wno-globals} option when compiling.
12029 Note that this warning is not issued for standard intrinsics.
12030 Standard intrinsics include those described in the FORTRAN 77
12031 standard and, if @option{-ff90} is specified, those described
12032 in the Fortran 90 standard.
12033 Such intrinsics are not as likely to be confused with user
12034 procedures as intrinsics provided as extensions to the
12035 standard by @command{g77}.
12038 @section @code{LEX}
12042 Unrecognized character @dots{}
12043 Invalid first character @dots{}
12044 Line too long @dots{}
12045 Non-numeric character @dots{}
12046 Continuation indicator @dots{}
12047 Label at @dots{} invalid with continuation line indicator @dots{}
12048 Character constant @dots{}
12049 Continuation line @dots{}
12050 Statement at @dots{} begins with invalid token
12053 Although the diagnostics identify specific problems, they can
12054 be produced when general problems such as the following occur:
12058 The source file contains something other than Fortran code.
12060 If the code in the file does not look like many of the examples
12061 elsewhere in this document, it might not be Fortran code.
12062 (Note that Fortran code often is written in lower case letters,
12063 while the examples in this document use upper case letters,
12064 for stylistic reasons.)
12066 For example, if the file contains lots of strange-looking
12067 characters, it might be APL source code; if it contains lots
12068 of parentheses, it might be Lisp source code; if it
12069 contains lots of bugs, it might be C++ source code.
12072 The source file contains free-form Fortran code, but @option{-ffree-form}
12073 was not specified on the command line to compile it.
12075 Free form is a newer form for Fortran code.
12076 The older, classic form is called fixed form.
12078 @cindex continuation character
12079 @cindex characters, continuation
12080 Fixed-form code is visually fairly distinctive, because
12081 numerical labels and comments are all that appear in
12082 the first five columns of a line, the sixth column is
12083 reserved to denote continuation lines,
12084 and actual statements start at or beyond column 7.
12085 Spaces generally are not significant, so if you
12086 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
12087 you are looking at fixed-form code.
12090 Comment lines are indicated by the letter @samp{C} or the symbol
12091 @samp{*} in column 1.
12092 @cindex trailing comment
12094 @cindex characters, comment
12096 @cindex exclamation point
12097 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
12098 which many compilers support.)
12100 Free-form code is distinguished from fixed-form source
12101 primarily by the fact that statements may start anywhere.
12102 (If lots of statements start in columns 1 through 6,
12103 that's a strong indicator of free-form source.)
12104 Consecutive keywords must be separated by spaces, so
12105 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
12106 There are no comment lines per se, but @samp{!} starts a
12107 comment anywhere in a line (other than within a character or
12108 Hollerith constant).
12110 @xref{Source Form}, for more information.
12113 The source file is in fixed form and has been edited without
12114 sensitivity to the column requirements.
12116 Statements in fixed-form code must be entirely contained within
12117 columns 7 through 72 on a given line.
12118 Starting them ``early'' is more likely to result in diagnostics
12119 than finishing them ``late'', though both kinds of errors are
12120 often caught at compile time.
12122 For example, if the following code fragment is edited by following
12123 the commented instructions literally, the result, shown afterward,
12124 would produce a diagnostic when compiled:
12127 C On XYZZY systems, remove "C" on next line:
12131 The result of editing the above line might be:
12134 C On XYZZY systems, remove "C" on next line:
12138 However, that leaves the first @samp{C} in the @code{CALL}
12139 statement in column 6, making it a comment line, which is
12140 not really what the author intended, and which is likely
12141 to result in one of the above-listed diagnostics.
12143 @emph{Replacing} the @samp{C} in column 1 with a space
12144 is the proper change to make, to ensure the @code{CALL}
12145 keyword starts in or after column 7.
12147 Another common mistake like this is to forget that fixed-form
12148 source lines are significant through only column 72, and that,
12149 normally, any text beyond column 72 is ignored or is diagnosed
12152 @xref{Source Form}, for more information.
12155 The source file requires preprocessing, and the preprocessing
12156 is not being specified at compile time.
12158 A source file containing lines beginning with @code{#define},
12159 @code{#include}, @code{#if}, and so on is likely one that
12160 requires preprocessing.
12162 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
12163 the file normally will be compiled @emph{without} preprocessing
12166 Change the file's suffix from @samp{.f} to @samp{.F}
12167 (or, on systems with case-insensitive file names,
12168 to @samp{.fpp} or @samp{.FPP}),
12169 from @samp{.for} to @samp{.fpp},
12170 or from @samp{.FOR} to @samp{.FPP}.
12171 @command{g77} compiles files with such names @emph{with}
12175 @cindex preprocessor
12176 @cindex cpp program
12177 @cindex programs, cpp
12178 @cindex @option{-x f77-cpp-input} option
12179 @cindex options, @option{-x f77-cpp-input}
12180 Or, learn how to use @command{gcc}'s @option{-x} option to specify
12181 the language @samp{f77-cpp-input} for Fortran files that
12182 require preprocessing.
12183 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
12186 The source file is preprocessed, and the results of preprocessing
12187 result in syntactic errors that are not necessarily obvious to
12188 someone examining the source file itself.
12190 Examples of errors resulting from preprocessor macro expansion
12191 include exceeding the line-length limit, improperly starting,
12192 terminating, or incorporating the apostrophe or double-quote in
12193 a character constant, improperly forming a Hollerith constant,
12196 @xref{Overall Options,,Options Controlling the Kind of Output},
12197 for suggestions about how to use, and not use, preprocessing
12202 @section @code{GLOBALS}
12206 Global name @var{name} defined at @dots{} already defined@dots{}
12207 Global name @var{name} at @dots{} has different type@dots{}
12208 Too many arguments passed to @var{name} at @dots{}
12209 Too few arguments passed to @var{name} at @dots{}
12210 Argument #@var{n} of @var{name} is @dots{}
12213 These messages all identify disagreements about the
12214 global procedure named @var{name} among different program units
12215 (usually including @var{name} itself).
12217 Whether a particular disagreement is reported
12218 as a warning or an error
12219 can depend on the relative order
12220 of the disagreeing portions of the source file.
12222 Disagreements between a procedure invocation
12223 and the @emph{subsequent} procedure itself
12224 are, usually, diagnosed as errors
12225 when the procedure itself @emph{precedes} the invocation.
12226 Other disagreements are diagnosed via warnings.
12228 @cindex forward references
12229 @cindex in-line code
12230 @cindex compilation, in-line
12231 This distinction, between warnings and errors,
12232 is due primarily to the present tendency of the @command{gcc} back end
12233 to inline only those procedure invocations that are
12234 @emph{preceded} by the corresponding procedure definitions.
12235 If the @command{gcc} back end is changed
12236 to inline ``forward references'',
12237 in which invocations precede definitions,
12238 the @command{g77} front end will be changed
12239 to treat both orderings as errors, accordingly.
12241 The sorts of disagreements that are diagnosed by @command{g77} include
12242 whether a procedure is a subroutine or function;
12243 if it is a function, the type of the return value of the procedure;
12244 the number of arguments the procedure accepts;
12245 and the type of each argument.
12247 Disagreements regarding global names among program units
12248 in a Fortran program @emph{should} be fixed in the code itself.
12249 However, if that is not immediately practical,
12250 and the code has been working for some time,
12251 it is possible it will work
12252 when compiled with the @option{-fno-globals} option.
12254 The @option{-fno-globals} option
12255 causes these diagnostics to all be warnings
12256 and disables all inlining of references to global procedures
12257 (to avoid subsequent compiler crashes and bad-code generation).
12258 Use of the @option{-Wno-globals} option as well as @option{-fno-globals}
12259 suppresses all of these diagnostics.
12260 (@option{-Wno-globals} by itself disables only the warnings,
12263 After using @option{-fno-globals} to work around these problems,
12264 it is wise to stop using that option and address them by fixing
12265 the Fortran code, because such problems, while they might not
12266 actually result in bugs on some systems, indicate that the code
12267 is not as portable as it could be.
12268 In particular, the code might appear to work on a particular
12269 system, but have bugs that affect the reliability of the data
12270 without exhibiting any other outward manifestations of the bugs.
12273 @section @code{LINKFAIL}
12276 On AIX 4.1, @command{g77} might not build with the native (non-GNU) tools
12277 due to a linker bug in coping with the @option{-bbigtoc} option which
12278 leads to a @samp{Relocation overflow} error. The GNU linker is not
12279 recommended on current AIX versions, though; it was developed under a
12280 now-unsupported version. This bug is said to be fixed by `update PTF
12281 U455193 for APAR IX75823'.
12283 Compiling with @option{-mminimal-toc}
12284 might solve this problem, e.g.@: by adding
12286 BOOT_CFLAGS='-mminimal-toc -O2 -g'
12288 to the @code{make bootstrap} command line.
12291 @section @code{Y2KBAD}
12292 @cindex Y2K compliance
12293 @cindex Year 2000 compliance
12297 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
12300 This diagnostic indicates that
12301 the specific intrinsic invoked by the name @var{name}
12302 is known to have an interface
12303 that is not Year-2000 (Y2K) compliant.
12305 @xref{Year 2000 (Y2K) Problems}.