1 \input texinfo @c -*-texinfo-*-
2 @c fix @set inside @example:
4 \gdef\set{\begingroup\catcode` =10 \parsearg\setxxx}
5 \gdef\setyyy#1 #2\endsetyyy{%
7 \ifx\temp\empty \global\expandafter\let\csname SET#1\endcsname = \empty
8 \else \setzzz{#1}#2\endsetzzz % Remove the trailing space \setxxx inserted.
17 @set last-up-date 1998-08-23
18 @set version-g77 0.5.24
19 @set email-general egcs@@cygnus.com
20 @set email-bugs egcs-bugs@@cygnus.com
21 @set path-g77 egcs/gcc/f
22 @set path-libf2c egcs/libf2c
24 @c @setfilename useg77.info
25 @c @setfilename portg77.info
26 @c To produce the full manual, use the "g77.info" setfilename, and
27 @c make sure the following do NOT begin with '@c' (and the @clear lines DO)
30 @c To produce a user-only manual, use the "useg77.info" setfilename, and
31 @c make sure the following does NOT begin with '@c':
33 @c To produce a porter-only manual, use the "portg77.info" setfilename,
34 @c and make sure the following does NOT begin with '@c':
37 @c (For FSF printing, turn on smallbook; that is all that is needed.)
43 @settitle Using and Porting GNU Fortran
46 @c seems reasonable to assume at least one of INTERNALS or USING is set...
48 @settitle Using GNU Fortran
51 @settitle Porting GNU Fortran
53 @c then again, have some fun
56 @settitle Doing Squat with GNU Fortran
63 @setchapternewpage odd
66 This file explains how to use the GNU Fortran system.
68 Published by the Free Software Foundation
69 59 Temple Place - Suite 330
70 Boston, MA 02111-1307 USA
72 Copyright (C) 1995-1997 Free Software Foundation, Inc.
74 Permission is granted to make and distribute verbatim copies of
75 this manual provided the copyright notice and this permission notice
76 are preserved on all copies.
79 Permission is granted to process this file through Tex and print the
80 results, provided the printed document carries copying permission
81 notice identical to this one except for the removal of this paragraph
82 (this paragraph not being relevant to the printed manual).
85 Permission is granted to copy and distribute modified versions of this
86 manual under the conditions for verbatim copying, provided also that the
87 sections entitled ``GNU General Public License,'' ``Funding for Free
88 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
89 included exactly as in the original, and provided that the entire
90 resulting derived work is distributed under the terms of a permission
91 notice identical to this one.
93 Permission is granted to copy and distribute translations of this manual
94 into another language, under the above conditions for modified versions,
95 except that the sections entitled ``GNU General Public License,''
96 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
97 And Feel'@w{}'', and this permission notice, may be included in
98 translations approved by the Free Software Foundation instead of in the
102 Contributed by James Craig Burley (@email{burley@@gnu.org}).
103 Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
104 was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).
108 @comment The title is printed in a large font.
109 @center @titlefont{Using GNU Fortran}
111 @center James Craig Burley
113 @center Last updated @value{last-up-date}
115 @c The version number appears some more times in this file.
117 @center for version @value{version-g77}
119 @vskip 0pt plus 1filll
120 Copyright @copyright{} 1995-1997 Free Software Foundation, Inc.
122 For GNU Fortran Version @value{version-g77}*
124 Published by the Free Software Foundation @*
125 59 Temple Place - Suite 330@*
126 Boston, MA 02111-1307, USA@*
127 @c Last printed ??ber, 19??.@*
128 @c Printed copies are available for $? each.@*
131 Permission is granted to make and distribute verbatim copies of
132 this manual provided the copyright notice and this permission notice
133 are preserved on all copies.
135 Permission is granted to copy and distribute modified versions of this
136 manual under the conditions for verbatim copying, provided also that the
137 sections entitled ``GNU General Public License,'' ``Funding for Free
138 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
139 included exactly as in the original, and provided that the entire
140 resulting derived work is distributed under the terms of a permission
141 notice identical to this one.
143 Permission is granted to copy and distribute translations of this manual
144 into another language, under the above conditions for modified versions,
145 except that the sections entitled ``GNU General Public License,''
146 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
147 And Feel'@w{}'', and this permission notice, may be included in
148 translations approved by the Free Software Foundation instead of in the
155 @dircategory Programming
157 * g77: (g77). The GNU Fortran compiler.
159 @node Top, Copying,, (DIR)
165 This manual documents how to run, install and port the GNU Fortran
166 compiler, as well as its new features and incompatibilities, and how to
167 report bugs. It corresponds to GNU Fortran version @value{version-g77}.
172 This manual documents how to run and install the GNU Fortran compiler,
173 as well as its new features and incompatibilities, and how to report
174 bugs. It corresponds to GNU Fortran version @value{version-g77}.
177 This manual documents how to port the GNU Fortran compiler,
178 as well as its new features and incompatibilities, and how to report
179 bugs. It corresponds to GNU Fortran version @value{version-g77}.
184 * Copying:: GNU General Public License says
185 how you can copy and share GNU Fortran.
186 * Contributors:: People who have contributed to GNU Fortran.
187 * Funding:: How to help assure continued work for free software.
188 * Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
189 * Look and Feel:: Protect your freedom---fight ``look and feel''.
191 * Getting Started:: Finding your way around this manual.
192 * What is GNU Fortran?:: How @code{g77} fits into the universe.
193 * G77 and GCC:: You can compile Fortran, C, or other programs.
194 * Invoking G77:: Command options supported by @code{g77}.
195 * News:: News about recent releases of @code{g77}.
196 * Changes:: User-visible changes to recent releases of @code{g77}.
197 * Language:: The GNU Fortran language.
198 * Compiler:: The GNU Fortran compiler.
199 * Other Dialects:: Dialects of Fortran supported by @code{g77}.
200 * Other Compilers:: Fortran compilers other than @code{g77}.
201 * Other Languages:: Languages other than Fortran.
202 * Installation:: How to configure, compile and install GNU Fortran.
203 * Debugging and Interfacing:: How @code{g77} generates code.
204 * Collected Fortran Wisdom:: How to avoid Trouble.
205 * Trouble:: If you have trouble with GNU Fortran.
206 * Open Questions:: Things we'd like to know.
207 * Bugs:: How, why, and where to report bugs.
208 * Service:: How to find suppliers of support for GNU Fortran.
211 * Adding Options:: Guidance on teaching @code{g77} about new options.
212 * Projects:: Projects for @code{g77} internals hackers.
215 * M: Diagnostics. Diagnostics produced by @code{g77}.
217 * Index:: Index of concepts and symbol names.
219 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
222 @unnumbered GNU GENERAL PUBLIC LICENSE
223 @center Version 2, June 1991
226 Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
227 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
229 Everyone is permitted to copy and distribute verbatim copies
230 of this license document, but changing it is not allowed.
233 @unnumberedsec Preamble
235 The licenses for most software are designed to take away your
236 freedom to share and change it. By contrast, the GNU General Public
237 License is intended to guarantee your freedom to share and change free
238 software---to make sure the software is free for all its users. This
239 General Public License applies to most of the Free Software
240 Foundation's software and to any other program whose authors commit to
241 using it. (Some other Free Software Foundation software is covered by
242 the GNU Library General Public License instead.) You can apply it to
245 When we speak of free software, we are referring to freedom, not
246 price. Our General Public Licenses are designed to make sure that you
247 have the freedom to distribute copies of free software (and charge for
248 this service if you wish), that you receive source code or can get it
249 if you want it, that you can change the software or use pieces of it
250 in new free programs; and that you know you can do these things.
252 To protect your rights, we need to make restrictions that forbid
253 anyone to deny you these rights or to ask you to surrender the rights.
254 These restrictions translate to certain responsibilities for you if you
255 distribute copies of the software, or if you modify it.
257 For example, if you distribute copies of such a program, whether
258 gratis or for a fee, you must give the recipients all the rights that
259 you have. You must make sure that they, too, receive or can get the
260 source code. And you must show them these terms so they know their
263 We protect your rights with two steps: (1) copyright the software, and
264 (2) offer you this license which gives you legal permission to copy,
265 distribute and/or modify the software.
267 Also, for each author's protection and ours, we want to make certain
268 that everyone understands that there is no warranty for this free
269 software. If the software is modified by someone else and passed on, we
270 want its recipients to know that what they have is not the original, so
271 that any problems introduced by others will not reflect on the original
272 authors' reputations.
274 Finally, any free program is threatened constantly by software
275 patents. We wish to avoid the danger that redistributors of a free
276 program will individually obtain patent licenses, in effect making the
277 program proprietary. To prevent this, we have made it clear that any
278 patent must be licensed for everyone's free use or not licensed at all.
280 The precise terms and conditions for copying, distribution and
284 @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
287 @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
292 This License applies to any program or other work which contains
293 a notice placed by the copyright holder saying it may be distributed
294 under the terms of this General Public License. The ``Program'', below,
295 refers to any such program or work, and a ``work based on the Program''
296 means either the Program or any derivative work under copyright law:
297 that is to say, a work containing the Program or a portion of it,
298 either verbatim or with modifications and/or translated into another
299 language. (Hereinafter, translation is included without limitation in
300 the term ``modification''.) Each licensee is addressed as ``you''.
302 Activities other than copying, distribution and modification are not
303 covered by this License; they are outside its scope. The act of
304 running the Program is not restricted, and the output from the Program
305 is covered only if its contents constitute a work based on the
306 Program (independent of having been made by running the Program).
307 Whether that is true depends on what the Program does.
310 You may copy and distribute verbatim copies of the Program's
311 source code as you receive it, in any medium, provided that you
312 conspicuously and appropriately publish on each copy an appropriate
313 copyright notice and disclaimer of warranty; keep intact all the
314 notices that refer to this License and to the absence of any warranty;
315 and give any other recipients of the Program a copy of this License
316 along with the Program.
318 You may charge a fee for the physical act of transferring a copy, and
319 you may at your option offer warranty protection in exchange for a fee.
322 You may modify your copy or copies of the Program or any portion
323 of it, thus forming a work based on the Program, and copy and
324 distribute such modifications or work under the terms of Section 1
325 above, provided that you also meet all of these conditions:
329 You must cause the modified files to carry prominent notices
330 stating that you changed the files and the date of any change.
333 You must cause any work that you distribute or publish, that in
334 whole or in part contains or is derived from the Program or any
335 part thereof, to be licensed as a whole at no charge to all third
336 parties under the terms of this License.
339 If the modified program normally reads commands interactively
340 when run, you must cause it, when started running for such
341 interactive use in the most ordinary way, to print or display an
342 announcement including an appropriate copyright notice and a
343 notice that there is no warranty (or else, saying that you provide
344 a warranty) and that users may redistribute the program under
345 these conditions, and telling the user how to view a copy of this
346 License. (Exception: if the Program itself is interactive but
347 does not normally print such an announcement, your work based on
348 the Program is not required to print an announcement.)
351 These requirements apply to the modified work as a whole. If
352 identifiable sections of that work are not derived from the Program,
353 and can be reasonably considered independent and separate works in
354 themselves, then this License, and its terms, do not apply to those
355 sections when you distribute them as separate works. But when you
356 distribute the same sections as part of a whole which is a work based
357 on the Program, the distribution of the whole must be on the terms of
358 this License, whose permissions for other licensees extend to the
359 entire whole, and thus to each and every part regardless of who wrote it.
361 Thus, it is not the intent of this section to claim rights or contest
362 your rights to work written entirely by you; rather, the intent is to
363 exercise the right to control the distribution of derivative or
364 collective works based on the Program.
366 In addition, mere aggregation of another work not based on the Program
367 with the Program (or with a work based on the Program) on a volume of
368 a storage or distribution medium does not bring the other work under
369 the scope of this License.
372 You may copy and distribute the Program (or a work based on it,
373 under Section 2) in object code or executable form under the terms of
374 Sections 1 and 2 above provided that you also do one of the following:
378 Accompany it with the complete corresponding machine-readable
379 source code, which must be distributed under the terms of Sections
380 1 and 2 above on a medium customarily used for software interchange; or,
383 Accompany it with a written offer, valid for at least three
384 years, to give any third party, for a charge no more than your
385 cost of physically performing source distribution, a complete
386 machine-readable copy of the corresponding source code, to be
387 distributed under the terms of Sections 1 and 2 above on a medium
388 customarily used for software interchange; or,
391 Accompany it with the information you received as to the offer
392 to distribute corresponding source code. (This alternative is
393 allowed only for noncommercial distribution and only if you
394 received the program in object code or executable form with such
395 an offer, in accord with Subsection b above.)
398 The source code for a work means the preferred form of the work for
399 making modifications to it. For an executable work, complete source
400 code means all the source code for all modules it contains, plus any
401 associated interface definition files, plus the scripts used to
402 control compilation and installation of the executable. However, as a
403 special exception, the source code distributed need not include
404 anything that is normally distributed (in either source or binary
405 form) with the major components (compiler, kernel, and so on) of the
406 operating system on which the executable runs, unless that component
407 itself accompanies the executable.
409 If distribution of executable or object code is made by offering
410 access to copy from a designated place, then offering equivalent
411 access to copy the source code from the same place counts as
412 distribution of the source code, even though third parties are not
413 compelled to copy the source along with the object code.
416 You may not copy, modify, sublicense, or distribute the Program
417 except as expressly provided under this License. Any attempt
418 otherwise to copy, modify, sublicense or distribute the Program is
419 void, and will automatically terminate your rights under this License.
420 However, parties who have received copies, or rights, from you under
421 this License will not have their licenses terminated so long as such
422 parties remain in full compliance.
425 You are not required to accept this License, since you have not
426 signed it. However, nothing else grants you permission to modify or
427 distribute the Program or its derivative works. These actions are
428 prohibited by law if you do not accept this License. Therefore, by
429 modifying or distributing the Program (or any work based on the
430 Program), you indicate your acceptance of this License to do so, and
431 all its terms and conditions for copying, distributing or modifying
432 the Program or works based on it.
435 Each time you redistribute the Program (or any work based on the
436 Program), the recipient automatically receives a license from the
437 original licensor to copy, distribute or modify the Program subject to
438 these terms and conditions. You may not impose any further
439 restrictions on the recipients' exercise of the rights granted herein.
440 You are not responsible for enforcing compliance by third parties to
444 If, as a consequence of a court judgment or allegation of patent
445 infringement or for any other reason (not limited to patent issues),
446 conditions are imposed on you (whether by court order, agreement or
447 otherwise) that contradict the conditions of this License, they do not
448 excuse you from the conditions of this License. If you cannot
449 distribute so as to satisfy simultaneously your obligations under this
450 License and any other pertinent obligations, then as a consequence you
451 may not distribute the Program at all. For example, if a patent
452 license would not permit royalty-free redistribution of the Program by
453 all those who receive copies directly or indirectly through you, then
454 the only way you could satisfy both it and this License would be to
455 refrain entirely from distribution of the Program.
457 If any portion of this section is held invalid or unenforceable under
458 any particular circumstance, the balance of the section is intended to
459 apply and the section as a whole is intended to apply in other
462 It is not the purpose of this section to induce you to infringe any
463 patents or other property right claims or to contest validity of any
464 such claims; this section has the sole purpose of protecting the
465 integrity of the free software distribution system, which is
466 implemented by public license practices. Many people have made
467 generous contributions to the wide range of software distributed
468 through that system in reliance on consistent application of that
469 system; it is up to the author/donor to decide if he or she is willing
470 to distribute software through any other system and a licensee cannot
473 This section is intended to make thoroughly clear what is believed to
474 be a consequence of the rest of this License.
477 If the distribution and/or use of the Program is restricted in
478 certain countries either by patents or by copyrighted interfaces, the
479 original copyright holder who places the Program under this License
480 may add an explicit geographical distribution limitation excluding
481 those countries, so that distribution is permitted only in or among
482 countries not thus excluded. In such case, this License incorporates
483 the limitation as if written in the body of this License.
486 The Free Software Foundation may publish revised and/or new versions
487 of the General Public License from time to time. Such new versions will
488 be similar in spirit to the present version, but may differ in detail to
489 address new problems or concerns.
491 Each version is given a distinguishing version number. If the Program
492 specifies a version number of this License which applies to it and ``any
493 later version'', you have the option of following the terms and conditions
494 either of that version or of any later version published by the Free
495 Software Foundation. If the Program does not specify a version number of
496 this License, you may choose any version ever published by the Free Software
500 If you wish to incorporate parts of the Program into other free
501 programs whose distribution conditions are different, write to the author
502 to ask for permission. For software which is copyrighted by the Free
503 Software Foundation, write to the Free Software Foundation; we sometimes
504 make exceptions for this. Our decision will be guided by the two goals
505 of preserving the free status of all derivatives of our free software and
506 of promoting the sharing and reuse of software generally.
516 BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
517 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
518 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
519 PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
520 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
521 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
522 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
523 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
524 REPAIR OR CORRECTION.
527 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
528 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
529 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
530 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
531 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
532 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
533 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
534 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
535 POSSIBILITY OF SUCH DAMAGES.
539 @heading END OF TERMS AND CONDITIONS
542 @center END OF TERMS AND CONDITIONS
546 @unnumberedsec How to Apply These Terms to Your New Programs
548 If you develop a new program, and you want it to be of the greatest
549 possible use to the public, the best way to achieve this is to make it
550 free software which everyone can redistribute and change under these terms.
552 To do so, attach the following notices to the program. It is safest
553 to attach them to the start of each source file to most effectively
554 convey the exclusion of warranty; and each file should have at least
555 the ``copyright'' line and a pointer to where the full notice is found.
558 @var{one line to give the program's name and a brief idea of what it does.}
559 Copyright (C) 19@var{yy} @var{name of author}
561 This program is free software; you can redistribute it and/or modify
562 it under the terms of the GNU General Public License as published by
563 the Free Software Foundation; either version 2 of the License, or
564 (at your option) any later version.
566 This program is distributed in the hope that it will be useful,
567 but WITHOUT ANY WARRANTY; without even the implied warranty of
568 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
569 GNU General Public License for more details.
571 You should have received a copy of the GNU General Public License
572 along with this program; if not, write to the Free Software
573 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
576 Also add information on how to contact you by electronic and paper mail.
578 If the program is interactive, make it output a short notice like this
579 when it starts in an interactive mode:
582 Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
583 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
585 This is free software, and you are welcome to redistribute it
586 under certain conditions; type `show c' for details.
589 The hypothetical commands @samp{show w} and @samp{show c} should show
590 the appropriate parts of the General Public License. Of course, the
591 commands you use may be called something other than @samp{show w} and
592 @samp{show c}; they could even be mouse-clicks or menu items---whatever
595 You should also get your employer (if you work as a programmer) or your
596 school, if any, to sign a ``copyright disclaimer'' for the program, if
597 necessary. Here is a sample; alter the names:
600 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
601 `Gnomovision' (which makes passes at compilers) written by James Hacker.
603 @var{signature of Ty Coon}, 1 April 1989
604 Ty Coon, President of Vice
607 This General Public License does not permit incorporating your program into
608 proprietary programs. If your program is a subroutine library, you may
609 consider it more useful to permit linking proprietary applications with the
610 library. If this is what you want to do, use the GNU Library General
611 Public License instead of this License.
614 @unnumbered Contributors to GNU Fortran
618 In addition to James Craig Burley, who wrote the front end,
619 many people have helped create and improve GNU Fortran.
623 The packaging and compiler portions of GNU Fortran are based largely
624 on the GNU CC compiler.
625 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
626 for more information.
629 The run-time library used by GNU Fortran is a repackaged version
630 of the @code{libf2c} library (combined from the @code{libF77} and
631 @code{libI77} libraries) provided as part of @code{f2c}, available for
632 free from @code{netlib} sites on the Internet.
635 Cygnus Support and The Free Software Foundation contributed
636 significant money and/or equipment to Craig's efforts.
639 The following individuals served as alpha testers prior to @code{g77}'s
640 public release. This work consisted of testing, researching, sometimes
641 debugging, and occasionally providing small amounts of code and fixes
642 for @code{g77}, plus offering plenty of helpful advice to Craig:
648 Dr.@: Mark Fernyhough
650 Takafumi Hayashi (The University of AIzu)---@email{takafumi@@u-aizu.ac.jp}
654 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
656 Dr.@: A. O. V. Le Blanc
678 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
679 provided the patch to add rudimentary support
680 for @code{INTEGER*1}, @code{INTEGER*2}, and
682 This inspired Craig to add further support,
683 even though the resulting support
684 would still be incomplete, because version 0.6 is still
688 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
689 and encouraged Craig to rewrite the documentation in texinfo
690 format by contributing a first pass at a translation of the
691 old @file{g77-0.5.16/f/DOC} file.
694 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
695 some analysis of generated code as part of an overall project
696 to improve @code{g77} code generation to at least be as good
697 as @code{f2c} used in conjunction with @code{gcc}.
698 So far, this has resulted in the three, somewhat
699 experimental, options added by @code{g77} to the @code{gcc}
700 compiler and its back end.
702 (These, in turn, have made their way into the @code{egcs}
703 version of the compiler, and do not exist in @code{gcc}
704 version 2.8 or versions of @code{g77} based on that version
708 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
711 Thanks to Mary Cortani and the staff at Craftwork Solutions
712 (@email{support@@craftwork.com}) for all of their support.
715 Many other individuals have helped debug, test, and improve @code{g77}
716 over the past several years, and undoubtedly more people
717 will be doing so in the future.
718 If you have done so, and would like
719 to see your name listed in the above list, please ask!
720 The default is that people wish to remain anonymous.
724 @chapter Funding Free Software
726 If you want to have more free software a few years from now, it makes
727 sense for you to help encourage people to contribute funds for its
728 development. The most effective approach known is to encourage
729 commercial redistributors to donate.
731 Users of free software systems can boost the pace of development by
732 encouraging for-a-fee distributors to donate part of their selling price
733 to free software developers---the Free Software Foundation, and others.
735 The way to convince distributors to do this is to demand it and expect
736 it from them. So when you compare distributors, judge them partly by
737 how much they give to free software development. Show distributors
738 they must compete to be the one who gives the most.
740 To make this approach work, you must insist on numbers that you can
741 compare, such as, ``We will donate ten dollars to the Frobnitz project
742 for each disk sold.'' Don't be satisfied with a vague promise, such as
743 ``A portion of the profits are donated,'' since it doesn't give a basis
746 Even a precise fraction ``of the profits from this disk'' is not very
747 meaningful, since creative accounting and unrelated business decisions
748 can greatly alter what fraction of the sales price counts as profit.
749 If the price you pay is $50, ten percent of the profit is probably
750 less than a dollar; it might be a few cents, or nothing at all.
752 Some redistributors do development work themselves. This is useful too;
753 but to keep everyone honest, you need to inquire how much they do, and
754 what kind. Some kinds of development make much more long-term
755 difference than others. For example, maintaining a separate version of
756 a program contributes very little; maintaining the standard version of a
757 program for the whole community contributes much. Easy new ports
758 contribute little, since someone else would surely do them; difficult
759 ports such as adding a new CPU to the GNU C compiler contribute more;
760 major new features or packages contribute the most.
762 By establishing the idea that supporting further development is ``the
763 proper thing to do'' when distributing free software for a fee, we can
764 assure a steady flow of resources into making more free software.
767 Copyright (C) 1994 Free Software Foundation, Inc.
768 Verbatim copying and redistribution of this section is permitted
769 without royalty; alteration is not permitted.
772 @node Funding GNU Fortran
773 @chapter Funding GNU Fortran
774 @cindex funding improvements
775 @cindex improvements, funding
777 Work on GNU Fortran is still being done mostly by its author,
778 James Craig Burley (@email{burley@@gnu.org}), who is a volunteer
779 for, not an employee of, the Free Software Foundation (FSF).
780 As with other GNU software, funding is important because it can pay for
781 needed equipment, personnel, and so on.
783 @cindex FSF, funding the
784 @cindex funding the FSF
785 The FSF provides information on the best way to fund ongoing
786 development of GNU software (such as GNU Fortran) in documents
787 such as the ``GNUS Bulletin''.
788 Email @email{gnu@@gnu.org} for information on funding the FSF.
790 To fund specific GNU Fortran work in particular, the FSF might
791 provide a means for that, but the FSF does not provide direct funding
792 to the author of GNU Fortran to continue his work. The FSF has
793 employee salary restrictions that can be incompatible with the
794 financial needs of some volunteers, who therefore choose to
795 remain volunteers and thus be able to be free to do contract work
796 and otherwise make their own schedules for doing GNU work.
798 Still, funding the FSF at least indirectly benefits work
799 on specific projects like GNU Fortran because it ensures the
800 continuing operation of the FSF offices, their workstations, their
801 network connections, and so on, which are invaluable to volunteers.
802 (Similarly, hiring Cygnus Support can help a project like GNU
803 Fortran---Cygnus has been a long-time donor of equipment usage to the author
804 of GNU Fortran, and this too has been invaluable---@xref{Contributors}.)
806 Currently, the only way to directly fund the author of GNU Fortran
807 in his work on that project is to hire him for the work you want
808 him to do, or donate money to him.
809 Several people have done this
810 already, with the result that he has not needed to immediately find
811 contract work on a few occasions.
812 If more people did this, he
813 would be able to plan on not doing contract work for many months and
814 could thus devote that time to work on projects (such as the planned
815 changes for 0.6) that require longer timeframes to complete.
816 For the latest information on the status of the author, do
817 @kbd{finger -l burley@@gnu.org} on a UNIX system
818 (or any system with a command like UNIX @code{finger}).
820 Another important way to support work on GNU Fortran is to volunteer
822 Work is needed on documentation, testing, porting
823 to various machines, and in some cases, coding (although major
824 changes planned for version 0.6 make it difficult to add manpower to this
826 Email @email{@value{email-general}} to volunteer for this work.
828 @xref{Funding,,Funding Free Software}, for more information.
831 @chapter Protect Your Freedom---Fight ``Look And Feel''
832 @c the above chapter heading overflows onto the next line. --mew 1/26/93
834 To preserve the ability to write free software, including replacements
835 for proprietary software, authors must be free to replicate the
836 user interface to which users of existing software have become
839 @xref{Look and Feel,,Protect Your Freedom---Fight ``Look And Feel'',
840 gcc,Using and Porting GNU CC}, for more information.
842 @node Getting Started
843 @chapter Getting Started
844 @cindex getting started
849 If you don't need help getting started reading the portions
850 of this manual that are most important to you, you should skip
851 this portion of the manual.
853 If you are new to compilers, especially Fortran compilers, or
854 new to how compilers are structured under UNIX and UNIX-like
855 systems, you'll want to see @ref{What is GNU Fortran?}.
857 If you are new to GNU compilers, or have used only one GNU
858 compiler in the past and not had to delve into how it lets
859 you manage various versions and configurations of @code{gcc},
860 you should see @ref{G77 and GCC}.
862 Everyone except experienced @code{g77} users should
863 see @ref{Invoking G77}.
865 If you're acquainted with previous versions of @code{g77},
866 you should see @ref{News}.
867 Further, if you've actually used previous versions of @code{g77},
868 especially if you've written or modified Fortran code to
869 be compiled by previous versions of @code{g77}, you
870 should see @ref{Changes}.
872 If you intend to write or otherwise compile code that is
873 not already strictly conforming ANSI FORTRAN 77---and this
874 is probably everyone---you should see @ref{Language}.
876 If you don't already have @code{g77} installed on your
877 system, you must see @ref{Installation}.
879 If you run into trouble getting Fortran code to compile,
880 link, run, or work properly, you might find answers
881 if you see @ref{Debugging and Interfacing},
882 see @ref{Collected Fortran Wisdom},
883 and see @ref{Trouble}.
884 You might also find that the problems you are encountering
885 are bugs in @code{g77}---see @ref{Bugs}, for information on
886 reporting them, after reading the other material.
888 If you need further help with @code{g77}, or with
889 freely redistributable software in general,
892 If you would like to help the @code{g77} project,
893 see @ref{Funding GNU Fortran}, for information on
894 helping financially, and see @ref{Projects}, for information
895 on helping in other ways.
897 If you're generally curious about the future of
898 @code{g77}, see @ref{Projects}.
899 If you're curious about its past,
900 see @ref{Contributors},
901 and see @ref{Funding GNU Fortran}.
903 To see a few of the questions maintainers of @code{g77} have,
904 and that you might be able to answer,
905 see @ref{Open Questions}.
908 @node What is GNU Fortran?
909 @chapter What is GNU Fortran?
910 @cindex concepts, basic
911 @cindex basic concepts
913 GNU Fortran, or @code{g77}, is designed initially as a free replacement
914 for, or alternative to, the UNIX @code{f77} command.
915 (Similarly, @code{gcc} is designed as a replacement
916 for the UNIX @code{cc} command.)
918 @code{g77} also is designed to fit in well with the other
919 fine GNU compilers and tools.
921 Sometimes these design goals conflict---in such cases, resolution
922 often is made in favor of fitting in well with Project GNU.
923 These cases are usually identified in the appropriate
924 sections of this manual.
927 As compilers, @code{g77}, @code{gcc}, and @code{f77}
928 share the following characteristics:
936 They read a user's program, stored in a file and
937 containing instructions written in the appropriate
938 language (Fortran, C, and so on).
939 This file contains @dfn{source code}.
941 @cindex translation of user programs
943 @cindex code, machine
946 They translate the user's program into instructions
947 a computer can carry out more quickly than it takes
948 to translate the instructions in the first place.
949 These instructions are called @dfn{machine code}---code
950 designed to be efficiently translated and processed
951 by a machine such as a computer.
952 Humans usually aren't as good writing machine code
953 as they are at writing Fortran or C, because
954 it is easy to make tiny mistakes writing machine code.
955 When writing Fortran or C, it is easy
956 to make big mistakes.
959 @cindex bugs, finding
961 @cindex commands, gdb
963 They provide information in the generated machine code
964 that can make it easier to find bugs in the program
965 (using a debugging tool, called a @dfn{debugger},
973 They locate and gather machine code already generated
974 to perform actions requested by statements in
976 This machine code is organized
977 into @dfn{libraries} and is located and gathered
978 during the @dfn{link} phase of the compilation
980 (Linking often is thought of as a separate
981 step, because it can be directly invoked via the
983 However, the @code{g77} and @code{gcc}
984 commands, as with most compiler commands, automatically
985 perform the linking step by calling on @code{ld}
986 directly, unless asked to not do so by the user.)
988 @cindex language, incorrect use of
989 @cindex incorrect use of language
991 They attempt to diagnose cases where the user's
992 program contains incorrect usages of the language.
993 The @dfn{diagnostics} produced by the compiler
994 indicate the problem and the location in the user's
995 source file where the problem was first noticed.
996 The user can use this information to locate and
998 @cindex diagnostics, incorrect
999 @cindex incorrect diagnostics
1000 @cindex error messages, incorrect
1001 @cindex incorrect error messages
1002 (Sometimes an incorrect usage
1003 of the language leads to a situation where the
1004 compiler can no longer make any sense of what
1005 follows---while a human might be able to---and
1006 thus ends up complaining about many ``problems''
1007 it encounters that, in fact, stem from just one
1008 problem, usually the first one reported.)
1011 @cindex questionable instructions
1013 They attempt to diagnose cases where the user's
1014 program contains a correct usage of the language,
1015 but instructs the computer to do something questionable.
1016 These diagnostics often are in the form of @dfn{warnings},
1017 instead of the @dfn{errors} that indicate incorrect
1018 usage of the language.
1021 How these actions are performed is generally under the
1022 control of the user.
1023 Using command-line options, the user can specify
1024 how persnickety the compiler is to be regarding
1025 the program (whether to diagnose questionable usage
1026 of the language), how much time to spend making
1027 the generated machine code run faster, and so on.
1029 @cindex components of g77
1030 @cindex g77, components of
1031 @code{g77} consists of several components:
1034 @cindex commands, gcc
1037 A modified version of the @code{gcc} command, which also might be
1038 installed as the system's @code{cc} command.
1039 (In many cases, @code{cc} refers to the
1040 system's ``native'' C compiler, which
1041 might be a non-GNU compiler, or an older version
1042 of @code{gcc} considered more stable or that is
1043 used to build the operating system kernel.)
1046 @cindex commands, g77
1048 The @code{g77} command itself, which also might be installed as the
1049 system's @code{f77} command.
1051 @cindex libg2c library
1052 @cindex libf2c library
1053 @cindex libraries, libf2c
1054 @cindex libraries, libg2c
1055 @cindex run-time library
1057 The @code{libg2c} run-time library.
1058 This library contains the machine code needed to support
1059 capabilities of the Fortran language that are not directly
1060 provided by the machine code generated by the @code{g77}
1063 @code{libg2c} is just the unique name @code{g77} gives
1064 to its version of @code{libf2c} to distinguish it from
1065 any copy of @code{libf2c} installed from @code{f2c}
1066 (or versions of @code{g77} that built @code{libf2c} under
1070 The maintainer of @code{libf2c} currently is
1071 @email{dmg@@bell-labs.com}.
1073 @cindex f771 program
1074 @cindex programs, f771
1077 @cindex commands, as
1078 @cindex assembly code
1079 @cindex code, assembly
1081 The compiler itself, internally named @code{f771}.
1083 Note that @code{f771} does not generate machine code directly---it
1084 generates @dfn{assembly code} that is a more readable form
1085 of machine code, leaving the conversion to actual machine code
1086 to an @dfn{assembler}, usually named @code{as}.
1089 @code{gcc} is often thought of as ``the C compiler'' only,
1090 but it does more than that.
1091 Based on command-line options and the names given for files
1092 on the command line, @code{gcc} determines which actions to perform, including
1093 preprocessing, compiling (in a variety of possible languages), assembling,
1096 @cindex driver, gcc command as
1097 @cindex gcc command as driver
1098 @cindex executable file
1099 @cindex files, executable
1101 @cindex programs, cc1
1102 @cindex preprocessor
1104 @cindex programs, cpp
1105 For example, the command @samp{gcc foo.c} @dfn{drives} the file
1106 @file{foo.c} through the preprocessor @code{cpp}, then
1107 the C compiler (internally named
1108 @code{cc1}), then the assembler (usually @code{as}), then the linker
1109 (@code{ld}), producing an executable program named @file{a.out} (on
1112 @cindex cc1plus program
1113 @cindex programs, cc1plus
1114 As another example, the command @samp{gcc foo.cc} would do much the same as
1115 @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
1116 @code{gcc} would use the C++ compiler (named @code{cc1plus}).
1118 @cindex f771 program
1119 @cindex programs, f771
1120 In a GNU Fortran installation, @code{gcc} recognizes Fortran source
1121 files by name just like it does C and C++ source files.
1122 It knows to use the Fortran compiler named @code{f771}, instead of
1123 @code{cc1} or @code{cc1plus}, to compile Fortran files.
1125 @cindex gcc not recognizing Fortran source
1126 @cindex unrecognized file format
1127 @cindex file format not recognized
1128 Non-Fortran-related operation of @code{gcc} is generally
1129 unaffected by installing the GNU Fortran version of @code{gcc}.
1130 However, without the installed version of @code{gcc} being the
1131 GNU Fortran version, @code{gcc} will not be able to compile
1132 and link Fortran programs---and since @code{g77} uses @code{gcc}
1133 to do most of the actual work, neither will @code{g77}!
1136 @cindex commands, g77
1137 The @code{g77} command is essentially just a front-end for
1138 the @code{gcc} command.
1139 Fortran users will normally use @code{g77} instead of @code{gcc},
1141 knows how to specify the libraries needed to link with Fortran programs
1142 (@code{libg2c} and @code{lm}).
1143 @code{g77} can still compile and link programs and
1144 source files written in other languages, just like @code{gcc}.
1146 @cindex printing version information
1147 @cindex version information, printing
1148 The command @samp{g77 -v} is a quick
1149 way to display lots of version information for the various programs
1150 used to compile a typical preprocessed Fortran source file---this
1151 produces much more output than @samp{gcc -v} currently does.
1152 (If it produces an error message near the end of the output---diagnostics
1153 from the linker, usually @code{ld}---you might
1154 have an out-of-date @code{libf2c} that improperly handles
1155 complex arithmetic.)
1156 In the output of this command, the line beginning @samp{GNU Fortran Front
1157 End} identifies the version number of GNU Fortran; immediately
1158 preceding that line is a line identifying the version of @code{gcc}
1159 with which that version of @code{g77} was built.
1161 @cindex libf2c library
1162 @cindex libraries, libf2c
1163 The @code{libf2c} library is distributed with GNU Fortran for
1164 the convenience of its users, but is not part of GNU Fortran.
1165 It contains the procedures
1166 needed by Fortran programs while they are running.
1168 @cindex in-line code
1169 @cindex code, in-line
1170 For example, while code generated by @code{g77} is likely
1171 to do additions, subtractions, and multiplications @dfn{in line}---in
1172 the actual compiled code---it is not likely to do trigonometric
1175 Instead, operations like trigonometric
1176 functions are compiled by the @code{f771} compiler
1177 (invoked by @code{g77} when compiling Fortran code) into machine
1178 code that, when run, calls on functions in @code{libg2c}, so
1179 @code{libg2c} must be linked with almost every useful program
1180 having any component compiled by GNU Fortran.
1181 (As mentioned above, the @code{g77} command takes
1182 care of all this for you.)
1184 The @code{f771} program represents most of what is unique to GNU Fortran.
1185 While much of the @code{libg2c} component comes from
1186 the @code{libf2c} component of @code{f2c},
1187 a free Fortran-to-C converter distributed by Bellcore (AT&T),
1188 plus @code{libU77}, provided by Dave Love,
1189 and the @code{g77} command is just a small front-end to @code{gcc},
1190 @code{f771} is a combination of two rather
1191 large chunks of code.
1193 @cindex GNU Back End (GBE)
1195 @cindex gcc back end
1196 @cindex back end, gcc
1197 @cindex code generator
1198 One chunk is the so-called @dfn{GNU Back End}, or GBE,
1199 which knows how to generate fast code for a wide variety of processors.
1200 The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
1201 @code{cc1plus}, and @code{f771}, plus others.
1202 Often the GBE is referred to as the ``gcc back end'' or
1203 even just ``gcc''---in this manual, the term GBE is used
1204 whenever the distinction is important.
1206 @cindex GNU Fortran Front End (FFE)
1208 @cindex g77 front end
1209 @cindex front end, g77
1210 The other chunk of @code{f771} is the
1211 majority of what is unique about GNU Fortran---the code that knows how
1212 to interpret Fortran programs to determine what they are intending to
1213 do, and then communicate that knowledge to the GBE for actual compilation
1215 This chunk is called the @dfn{Fortran Front End} (FFE).
1216 The @code{cc1} and @code{cc1plus} programs have their own front ends,
1217 for the C and C++ languages, respectively.
1218 These fronts ends are responsible for diagnosing
1219 incorrect usage of their respective languages by the
1220 programs the process, and are responsible for most of
1221 the warnings about questionable constructs as well.
1222 (The GBE handles producing some warnings, like those
1223 concerning possible references to undefined variables.)
1225 Because so much is shared among the compilers for various languages,
1226 much of the behavior and many of the user-selectable options for these
1227 compilers are similar.
1228 For example, diagnostics (error messages and
1229 warnings) are similar in appearance; command-line
1230 options like @samp{-Wall} have generally similar effects; and the quality
1231 of generated code (in terms of speed and size) is roughly similar
1232 (since that work is done by the shared GBE).
1235 @chapter Compile Fortran, C, or Other Programs
1236 @cindex compiling programs
1237 @cindex programs, compiling
1240 @cindex commands, gcc
1241 A GNU Fortran installation includes a modified version of the @code{gcc}
1244 In a non-Fortran installation, @code{gcc} recognizes C, C++,
1245 and Objective-C source files.
1247 In a GNU Fortran installation, @code{gcc} also recognizes Fortran source
1248 files and accepts Fortran-specific command-line options, plus some
1249 command-line options that are designed to cater to Fortran users
1250 but apply to other languages as well.
1252 @xref{G++ and GCC,,Compile C; C++; or Objective-C,gcc,Using and Porting GNU CC},
1253 for information on the way different languages are handled
1254 by the GNU CC compiler (@code{gcc}).
1257 @cindex commands, g77
1258 Also provided as part of GNU Fortran is the @code{g77} command.
1259 The @code{g77} command is designed to make compiling and linking Fortran
1260 programs somewhat easier than when using the @code{gcc} command for
1262 It does this by analyzing the command line somewhat and changing it
1263 appropriately before submitting it to the @code{gcc} command.
1266 @cindex g77 options, -v
1268 Use the @samp{-v} option with @code{g77}
1269 to see what is going on---the first line of output is the invocation
1270 of the @code{gcc} command.
1273 @chapter GNU Fortran Command Options
1274 @cindex GNU Fortran command options
1275 @cindex command options
1276 @cindex options, GNU Fortran command
1278 The @code{g77} command supports all the options supported by the
1280 @xref{Invoking GCC,,GNU CC Command Options,gcc,Using and Porting GNU CC},
1282 on the non-Fortran-specific aspects of the @code{gcc} command (and,
1283 therefore, the @code{g77} command).
1285 @cindex options, negative forms
1286 @cindex negative forms of options
1287 All @code{gcc} and @code{g77} options
1288 are accepted both by @code{g77} and by @code{gcc}
1289 (as well as any other drivers built at the same time,
1290 such as @code{g++}),
1291 since adding @code{g77} to the @code{gcc} distribution
1292 enables acceptance of @code{g77}-specific options
1293 by all of the relevant drivers.
1295 In some cases, options have positive and negative forms;
1296 the negative form of @samp{-ffoo} would be @samp{-fno-foo}.
1297 This manual documents only one of these two forms, whichever
1298 one is not the default.
1301 * Option Summary:: Brief list of all @code{g77} options,
1302 without explanations.
1303 * Overall Options:: Controlling the kind of output:
1304 an executable, object files, assembler files,
1305 or preprocessed source.
1306 * Shorthand Options:: Options that are shorthand for other options.
1307 * Fortran Dialect Options:: Controlling the variant of Fortran language
1309 * Warning Options:: How picky should the compiler be?
1310 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1311 * Optimize Options:: How much optimization?
1312 * Preprocessor Options:: Controlling header files and macro definitions.
1313 Also, getting dependency information for Make.
1314 * Directory Options:: Where to find header files and libraries.
1315 Where to find the compiler executable files.
1316 * Code Gen Options:: Specifying conventions for function calls, data layout
1318 * Environment Variables:: Env vars that affect GNU Fortran.
1321 @node Option Summary
1322 @section Option Summary
1324 Here is a summary of all the options specific to GNU Fortran, grouped
1325 by type. Explanations are in the following sections.
1328 @item Overall Options
1329 @xref{Overall Options,,Options Controlling the Kind of Output}.
1331 -fversion -fset-g77-defaults -fno-silent
1334 @item Shorthand Options
1335 @xref{Shorthand Options}.
1337 -ff66 -fno-f66 -ff77 -fno-f77 -fugly -fno-ugly
1340 @item Fortran Language Options
1341 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect}.
1343 -ffree-form -fno-fixed-form -ff90
1344 -fvxt -fdollar-ok -fno-backslash
1345 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1346 -fugly-comma -fugly-complex -fugly-init -fugly-logint
1347 -fonetrip -ftypeless-boz
1348 -fintrin-case-initcap -fintrin-case-upper
1349 -fintrin-case-lower -fintrin-case-any
1350 -fmatch-case-initcap -fmatch-case-upper
1351 -fmatch-case-lower -fmatch-case-any
1352 -fsource-case-upper -fsource-case-lower -fsource-case-preserve
1353 -fsymbol-case-initcap -fsymbol-case-upper
1354 -fsymbol-case-lower -fsymbol-case-any
1355 -fcase-strict-upper -fcase-strict-lower
1356 -fcase-initcap -fcase-upper -fcase-lower -fcase-preserve
1357 -ff2c-intrinsics-delete -ff2c-intrinsics-hide
1358 -ff2c-intrinsics-disable -ff2c-intrinsics-enable
1359 -fbadu77-intrinsics-delete -fbadu77-intrinsics-hide
1360 -fbadu77-intrinsics-disable -fbadu77-intrinsics-enable
1361 -ff90-intrinsics-delete -ff90-intrinsics-hide
1362 -ff90-intrinsics-disable -ff90-intrinsics-enable
1363 -fgnu-intrinsics-delete -fgnu-intrinsics-hide
1364 -fgnu-intrinsics-disable -fgnu-intrinsics-enable
1365 -fmil-intrinsics-delete -fmil-intrinsics-hide
1366 -fmil-intrinsics-disable -fmil-intrinsics-enable
1367 -funix-intrinsics-delete -funix-intrinsics-hide
1368 -funix-intrinsics-disable -funix-intrinsics-enable
1369 -fvxt-intrinsics-delete -fvxt-intrinsics-hide
1370 -fvxt-intrinsics-disable -fvxt-intrinsics-enable
1371 -ffixed-line-length-@var{n} -ffixed-line-length-none
1374 @item Warning Options
1375 @xref{Warning Options,,Options to Request or Suppress Warnings}.
1377 -fsyntax-only -pedantic -pedantic-errors -fpedantic
1378 -w -Wno-globals -Wimplicit -Wunused -Wuninitialized
1383 @item Debugging Options
1384 @xref{Debugging Options,,Options for Debugging Your Program or GCC}.
1389 @item Optimization Options
1390 @xref{Optimize Options,,Options that Control Optimization}.
1393 -ffloat-store -fforce-mem -fforce-addr -fno-inline
1394 -ffast-math -fstrength-reduce -frerun-cse-after-loop
1395 -fexpensive-optimizations -fdelayed-branch
1396 -fschedule-insns -fschedule-insn2 -fcaller-saves
1397 -funroll-loops -funroll-all-loops
1398 -fno-move-all-movables -fno-reduce-all-givs
1402 @item Directory Options
1403 @xref{Directory Options,,Options for Directory Search}.
1408 @item Code Generation Options
1409 @xref{Code Gen Options,,Options for Code Generation Conventions}.
1411 -fno-automatic -finit-local-zero -fno-f2c
1412 -ff2c-library -fno-underscoring -fno-ident
1413 -fpcc-struct-return -freg-struct-return
1414 -fshort-double -fno-common -fpack-struct
1415 -fzeros -fno-second-underscore
1416 -fdebug-kludge -fno-emulate-complex
1417 -falias-check -fargument-alias
1418 -fargument-noalias -fno-argument-noalias-global
1424 * Overall Options:: Controlling the kind of output:
1425 an executable, object files, assembler files,
1426 or preprocessed source.
1427 * Shorthand Options:: Options that are shorthand for other options.
1428 * Fortran Dialect Options:: Controlling the variant of Fortran language
1430 * Warning Options:: How picky should the compiler be?
1431 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1432 * Optimize Options:: How much optimization?
1433 * Preprocessor Options:: Controlling header files and macro definitions.
1434 Also, getting dependency information for Make.
1435 * Directory Options:: Where to find header files and libraries.
1436 Where to find the compiler executable files.
1437 * Code Gen Options:: Specifying conventions for function calls, data layout
1441 @node Overall Options
1442 @section Options Controlling the Kind of Output
1443 @cindex overall options
1444 @cindex options, overall
1446 Compilation can involve as many as four stages: preprocessing, code
1447 generation (often what is really meant by the term ``compilation''),
1448 assembly, and linking, always in that order. The first three
1449 stages apply to an individual source file, and end by producing an
1450 object file; linking combines all the object files (those newly
1451 compiled, and those specified as input) into an executable file.
1453 @cindex file name suffix
1454 @cindex suffixes, file name
1455 @cindex file name extension
1456 @cindex extensions, file name
1459 For any given input file, the file name suffix determines what kind of
1460 program is contained in the file---that is, the language in which the
1461 program is written is generally indicated by the suffix.
1462 Suffixes specific to GNU Fortran are listed below.
1463 @xref{Overall Options,,gcc,Using and Porting GNU CC}, for
1464 information on suffixes recognized by GNU CC.
1468 @item @var{file}.for
1469 Fortran source code that should not be preprocessed.
1471 Such source code cannot contain any preprocessor directives, such
1472 as @code{#include}, @code{#define}, @code{#if}, and so on.
1474 @cindex preprocessor
1475 @cindex C preprocessor
1476 @cindex cpp preprocessor
1477 @cindex Fortran preprocessor
1479 @cindex programs, cpp
1480 @cindex .F filename suffix
1481 @cindex .fpp filename suffix
1483 @item @var{file}.fpp
1484 Fortran source code that must be preprocessed (by the C preprocessor
1485 @code{cpp}, which is part of GNU CC).
1487 Note that preprocessing is not extended to the contents of
1488 files included by the @code{INCLUDE} directive---the @code{#include}
1489 preprocessor directive must be used instead.
1491 @cindex Ratfor preprocessor
1492 @cindex programs, ratfor
1493 @cindex .r filename suffix
1495 Ratfor source code, which must be preprocessed by the @code{ratfor}
1496 command, which is available separately (as it is not yet part of
1497 the GNU Fortran distribution).
1500 UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
1502 Users of other operating systems, especially those that cannot
1503 distinguish upper-case
1504 letters from lower-case letters in their file names, typically use
1505 the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.
1510 Use of the preprocessor @code{cpp} allows use of C-like
1511 constructs such as @code{#define} and @code{#include}, but can
1512 lead to unexpected, even mistaken, results due to Fortran's source file
1514 It is recommended that use of the C preprocessor
1515 be limited to @code{#include} and, in
1516 conjunction with @code{#define}, only @code{#if} and related directives,
1517 thus avoiding in-line macro expansion entirely.
1518 This recommendation applies especially
1519 when using the traditional fixed source form.
1520 With free source form,
1521 fewer unexpected transformations are likely to happen, but use of
1522 constructs such as Hollerith and character constants can nevertheless
1523 present problems, especially when these are continued across multiple
1525 These problems result, primarily, from differences between the way
1526 such constants are interpreted by the C preprocessor and by a Fortran
1529 Another example of a problem that results from using the C preprocessor
1530 is that a Fortran comment line that happens to contain any
1531 characters ``interesting'' to the C preprocessor,
1532 such as a backslash at the end of the line,
1533 is not recognized by the preprocessor as a comment line,
1534 so instead of being passed through ``raw'',
1535 the line is edited according to the rules for the preprocessor.
1536 For example, the backslash at the end of the line is removed,
1537 along with the subsequent newline, resulting in the next
1538 line being effectively commented out---unfortunate if that
1539 line is a non-comment line of important code!
1541 @emph{Note:} The @samp{-traditional} and @samp{-undef} flags are supplied
1542 to @code{cpp} by default, to avoid unpleasant surprises.
1543 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
1544 gcc,Using and Porting GNU CC}.
1545 This means that ANSI C preprocessor features (such as the @samp{#}
1546 operator) aren't available, and only variables in the C reserved
1547 namespace (generally, names with a leading underscore) are liable to
1548 substitution by C predefines.
1549 Thus, if you want to do system-specific
1550 tests, use, for example, @samp{#ifdef __linux__} rather than @samp{#ifdef linux}.
1551 Use the @samp{-v} option to see exactly how the preprocessor is invoked.
1553 The following options that affect overall processing are recognized
1554 by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:
1557 @cindex -fversion option
1558 @cindex options, -fversion
1559 @cindex printing version information
1560 @cindex version information, printing
1562 Ensure that the @code{g77}-specific version of the compiler phase is reported,
1564 (This is supplied automatically when @samp{-v} or @samp{--verbose}
1565 is specified as a command-line option for @code{g77} or @code{gcc}
1566 and when the resulting commands compile Fortran source files.)
1568 @cindex -fset-g77-defaults option
1569 @cindex options, -fset-g77-defaults
1570 @item -fset-g77-defaults
1571 @emph{Version info:}
1572 This option is obsolete in @code{egcs}
1575 Set up whatever @code{gcc} options are to apply to Fortran
1576 compilations, and avoid running internal consistency checks
1577 that might take some time.
1579 This option is supplied automatically when compiling Fortran code
1580 via the @code{g77} or @code{gcc} command.
1581 The description of this option is provided so that users seeing
1582 it in the output of, say, @samp{g77 -v} understand why it is
1585 @cindex modifying g77
1586 @cindex code, modifying
1587 Also, developers who run @code{f771} directly might want to specify it
1588 by hand to get the same defaults as they would running @code{f771}
1589 via @code{g77} or @code{gcc}.
1590 However, such developers should, after linking a new @code{f771}
1591 executable, invoke it without this option once,
1592 e.g. via @kbd{./f771 -quiet < /dev/null},
1593 to ensure that they have not introduced any
1594 internal inconsistencies (such as in the table of
1595 intrinsics) before proceeding---@code{g77} will crash
1596 with a diagnostic if it detects an inconsistency.
1598 @cindex -fno-silent option
1599 @cindex options, -fno-silent
1600 @cindex @code{f2c} compatibility
1601 @cindex compatibility, @code{f2c}
1602 @cindex status, compilation
1603 @cindex compilation status
1604 @cindex reporting compilation status
1605 @cindex printing compilation status
1607 Print (to @code{stderr}) the names of the program units as
1608 they are compiled, in a form similar to that used by popular
1609 UNIX @code{f77} implementations and @code{f2c}.
1612 @xref{Overall Options,,Options Controlling the Kind of Output,
1613 gcc,Using and Porting GNU CC}, for information
1614 on more options that control the overall operation of the @code{gcc} command
1615 (and, by extension, the @code{g77} command).
1617 @node Shorthand Options
1618 @section Shorthand Options
1619 @cindex shorthand options
1620 @cindex options, shorthand
1621 @cindex macro options
1622 @cindex options, macro
1624 The following options serve as ``shorthand''
1625 for other options accepted by the compiler:
1628 @cindex -fugly option
1629 @cindex options, -fugly
1631 @cindex ugly features
1632 @cindex features, ugly
1633 Specify that certain ``ugly'' constructs are to be quietly accepted.
1637 -fugly-args -fugly-assign -fugly-assumed
1638 -fugly-comma -fugly-complex -fugly-init
1642 These constructs are considered inappropriate to use in new
1643 or well-maintained portable Fortran code, but widely used
1645 @xref{Distensions}, for more information.
1647 @emph{Note:} The @samp{-fugly} option is likely to
1648 be removed in a future version.
1649 Implicitly enabling all the @samp{-fugly-*} options
1650 is unlikely to be feasible, or sensible, in the future,
1651 so users should learn to specify only those
1652 @samp{-fugly-*} options they really need for a
1653 particular source file.
1655 @cindex -fno-ugly option
1656 @cindex options, -fno-ugly
1658 @cindex ugly features
1659 @cindex features, ugly
1660 Specify that all ``ugly'' constructs are to be noisily rejected.
1664 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1665 -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
1669 @xref{Distensions}, for more information.
1671 @cindex -ff66 option
1672 @cindex options, -ff66
1675 @cindex compatibility, FORTRAN 66
1676 Specify that the program is written in idiomatic FORTRAN 66.
1677 Same as @samp{-fonetrip -fugly-assumed}.
1679 The @samp{-fno-f66} option is the inverse of @samp{-ff66}.
1680 As such, it is the same as @samp{-fno-onetrip -fno-ugly-assumed}.
1682 The meaning of this option is likely to be refined as future
1683 versions of @code{g77} provide more compatibility with other
1684 existing and obsolete Fortran implementations.
1686 @cindex -ff77 option
1687 @cindex options, -ff77
1690 @cindex @code{f2c} compatibility
1691 @cindex compatibility, @code{f2c}
1692 @cindex @code{f77} compatibility
1693 @cindex compatibility, @code{f77}
1694 Specify that the program is written in idiomatic UNIX FORTRAN 77
1695 and/or the dialect accepted by the @code{f2c} product.
1696 Same as @samp{-fbackslash -fno-typeless-boz}.
1698 The meaning of this option is likely to be refined as future
1699 versions of @code{g77} provide more compatibility with other
1700 existing and obsolete Fortran implementations.
1702 @cindex -fno-f77 option
1703 @cindex options, -fno-f77
1706 The @samp{-fno-f77} option is @emph{not} the inverse
1708 It specifies that the program is not written in idiomatic UNIX
1709 FORTRAN 77 or @code{f2c}, but in a more widely portable dialect.
1710 @samp{-fno-f77} is the same as @samp{-fno-backslash}.
1712 The meaning of this option is likely to be refined as future
1713 versions of @code{g77} provide more compatibility with other
1714 existing and obsolete Fortran implementations.
1717 @node Fortran Dialect Options
1718 @section Options Controlling Fortran Dialect
1719 @cindex dialect options
1720 @cindex language dialect options
1721 @cindex options, dialect
1723 The following options control the dialect of Fortran
1724 that the compiler accepts:
1727 @cindex -ffree-form option
1728 @cindex options, -ffree-form
1729 @cindex -fno-fixed-form option
1730 @cindex options, -fno-fixed-form
1731 @cindex source file form
1734 @cindex Fortran 90 features
1736 @item -fno-fixed-form
1737 Specify that the source file is written in free form
1738 (introduced in Fortran 90) instead of the more-traditional fixed form.
1740 @cindex -ff90 option
1741 @cindex options, -ff90
1742 @cindex Fortran 90 features
1744 Allow certain Fortran-90 constructs.
1746 This option controls whether certain
1747 Fortran 90 constructs are recognized.
1748 (Other Fortran 90 constructs
1749 might or might not be recognized depending on other options such as
1750 @samp{-fvxt}, @samp{-ff90-intrinsics-enable}, and the
1751 current level of support for Fortran 90.)
1753 @xref{Fortran 90}, for more information.
1755 @cindex -fvxt option
1756 @cindex options, -fvxt
1758 @cindex Fortran 90 features
1759 @cindex VXT features
1760 Specify the treatment of certain constructs that have different
1761 meanings depending on whether the code is written in
1762 GNU Fortran (based on FORTRAN 77 and akin to Fortran 90)
1763 or VXT Fortran (more like VAX FORTRAN).
1765 The default is @samp{-fno-vxt}.
1766 @samp{-fvxt} specifies that the VXT Fortran interpretations
1767 for those constructs are to be chosen.
1769 @xref{VXT Fortran}, for more information.
1771 @cindex -fdollar-ok option
1772 @cindex options, -fdollar-ok
1775 @cindex symbol names
1776 @cindex character set
1777 Allow @samp{$} as a valid character in a symbol name.
1779 @cindex -fno-backslash option
1780 @cindex options, -fno-backslash
1781 @item -fno-backslash
1783 @cindex character constants
1784 @cindex Hollerith constants
1785 Specify that @samp{\} is not to be specially interpreted in character
1786 and Hollerith constants a la C and many UNIX Fortran compilers.
1788 For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
1789 three characters, with the second one being newline.
1790 With @samp{-fno-backslash}, it specifies four characters,
1791 @samp{A}, @samp{\}, @samp{n}, and @samp{B}.
1793 Note that @code{g77} implements a fairly general form of backslash
1794 processing that is incompatible with the narrower forms supported
1795 by some other compilers.
1796 For example, @samp{'A\003B'} is a three-character string in @code{g77},
1797 whereas other compilers that support backslash might not support
1798 the three-octal-digit form, and thus treat that string as longer
1799 than three characters.
1801 @xref{Backslash in Constants}, for
1802 information on why @samp{-fbackslash} is the default
1803 instead of @samp{-fno-backslash}.
1805 @cindex -fno-ugly-args option
1806 @cindex options, -fno-ugly-args
1807 @item -fno-ugly-args
1808 Disallow passing Hollerith and typeless constants as actual
1809 arguments (for example, @samp{CALL FOO(4HABCD)}).
1811 @xref{Ugly Implicit Argument Conversion}, for more information.
1813 @cindex -fugly-assign option
1814 @cindex options, -fugly-assign
1816 Use the same storage for a given variable regardless of
1817 whether it is used to hold an assigned-statement label
1818 (as in @samp{ASSIGN 10 TO I}) or used to hold numeric data
1819 (as in @samp{I = 3}).
1821 @xref{Ugly Assigned Labels}, for more information.
1823 @cindex -fugly-assumed option
1824 @cindex options, -fugly-assumed
1825 @item -fugly-assumed
1826 Assume any dummy array with a final dimension specified as @samp{1}
1827 is really an assumed-size array, as if @samp{*} had been specified
1828 for the final dimension instead of @samp{1}.
1830 For example, @samp{DIMENSION X(1)} is treated as if it
1831 had read @samp{DIMENSION X(*)}.
1833 @xref{Ugly Assumed-Size Arrays}, for more information.
1835 @cindex -fugly-comma option
1836 @cindex options, -fugly-comma
1838 In an external-procedure invocation,
1839 treat a trailing comma in the argument list
1840 as specification of a trailing null argument,
1841 and treat an empty argument list
1842 as specification of a single null argument.
1844 For example, @samp{CALL FOO(,)} is treated as
1845 @samp{CALL FOO(%VAL(0), %VAL(0))}.
1846 That is, @emph{two} null arguments are specified
1847 by the procedure call when @samp{-fugly-comma} is in force.
1848 And @samp{F = FUNC()} is treated as @samp{F = FUNC(%VAL(0))}.
1850 The default behavior, @samp{-fno-ugly-comma}, is to ignore
1851 a single trailing comma in an argument list.
1852 So, by default, @samp{CALL FOO(X,)} is treated
1853 exactly the same as @samp{CALL FOO(X)}.
1855 @xref{Ugly Null Arguments}, for more information.
1857 @cindex -fugly-complex option
1858 @cindex options, -fugly-complex
1859 @item -fugly-complex
1860 Do not complain about @samp{REAL(@var{expr})} or
1861 @samp{AIMAG(@var{expr})} when @var{expr} is a @code{COMPLEX}
1862 type other than @code{COMPLEX(KIND=1)}---usually
1863 this is used to permit @code{COMPLEX(KIND=2)}
1864 (@code{DOUBLE COMPLEX}) operands.
1866 The @samp{-ff90} option controls the interpretation
1869 @xref{Ugly Complex Part Extraction}, for more information.
1871 @cindex -fno-ugly-init option
1872 @cindex options, -fno-ugly-init
1873 @item -fno-ugly-init
1874 Disallow use of Hollerith and typeless constants as initial
1875 values (in @code{PARAMETER} and @code{DATA} statements), and
1876 use of character constants to
1877 initialize numeric types and vice versa.
1879 For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
1880 @samp{-fno-ugly-init}.
1882 @xref{Ugly Conversion of Initializers}, for more information.
1884 @cindex -fugly-logint option
1885 @cindex options, -fugly-logint
1887 Treat @code{INTEGER} and @code{LOGICAL} variables and
1888 expressions as potential stand-ins for each other.
1890 For example, automatic conversion between @code{INTEGER} and
1891 @code{LOGICAL} is enabled, for many contexts, via this option.
1893 @xref{Ugly Integer Conversions}, for more information.
1895 @cindex -fonetrip option
1896 @cindex options, -fonetrip
1899 @cindex DO loops, one-trip
1900 @cindex one-trip DO loops
1901 @cindex compatibility, FORTRAN 66
1902 Imperative executable @code{DO} loops are to be executed at
1903 least once each time they are reached.
1905 ANSI FORTRAN 77 and more recent versions of the Fortran standard
1906 specify that the body of an imperative @code{DO} loop is not executed
1907 if the number of iterations calculated from the parameters of the
1908 loop is less than 1.
1909 (For example, @samp{DO 10 I = 1, 0}.)
1910 Such a loop is called a @dfn{zero-trip loop}.
1912 Prior to ANSI FORTRAN 77, many compilers implemented @code{DO} loops
1913 such that the body of a loop would be executed at least once, even
1914 if the iteration count was zero.
1915 Fortran code written assuming this behavior is said to require
1916 @dfn{one-trip loops}.
1917 For example, some code written to the FORTRAN 66 standard
1918 expects this behavior from its @code{DO} loops, although that
1919 standard did not specify this behavior.
1921 The @samp{-fonetrip} option specifies that the source file(s) being
1922 compiled require one-trip loops.
1924 This option affects only those loops specified by the (imperative) @code{DO}
1925 statement and by implied-@code{DO} lists in I/O statements.
1926 Loops specified by implied-@code{DO} lists in @code{DATA} and
1927 specification (non-executable) statements are not affected.
1929 @cindex -ftypeless-boz option
1930 @cindex options, -ftypeless-boz
1931 @cindex prefix-radix constants
1932 @cindex constants, prefix-radix
1933 @cindex constants, types
1934 @cindex types, constants
1935 @item -ftypeless-boz
1936 Specifies that prefix-radix non-decimal constants, such as
1937 @samp{Z'ABCD'}, are typeless instead of @code{INTEGER(KIND=1)}.
1939 You can test for yourself whether a particular compiler treats
1940 the prefix form as @code{INTEGER(KIND=1)} or typeless by running the
1947 IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
1948 IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
1952 Reports indicate that many compilers process this form as
1953 @code{INTEGER(KIND=1)}, though a few as typeless, and at least one
1954 based on a command-line option specifying some kind of
1957 @cindex -fintrin-case-initcap option
1958 @cindex options, -fintrin-case-initcap
1959 @item -fintrin-case-initcap
1960 @cindex -fintrin-case-upper option
1961 @cindex options, -fintrin-case-upper
1962 @item -fintrin-case-upper
1963 @cindex -fintrin-case-lower option
1964 @cindex options, -fintrin-case-lower
1965 @item -fintrin-case-lower
1966 @cindex -fintrin-case-any option
1967 @cindex options, -fintrin-case-any
1968 @item -fintrin-case-any
1969 Specify expected case for intrinsic names.
1970 @samp{-fintrin-case-lower} is the default.
1972 @cindex -fmatch-case-initcap option
1973 @cindex options, -fmatch-case-initcap
1974 @item -fmatch-case-initcap
1975 @cindex -fmatch-case-upper option
1976 @cindex options, -fmatch-case-upper
1977 @item -fmatch-case-upper
1978 @cindex -fmatch-case-lower option
1979 @cindex options, -fmatch-case-lower
1980 @item -fmatch-case-lower
1981 @cindex -fmatch-case-any option
1982 @cindex options, -fmatch-case-any
1983 @item -fmatch-case-any
1984 Specify expected case for keywords.
1985 @samp{-fmatch-case-lower} is the default.
1987 @cindex -fsource-case-upper option
1988 @cindex options, -fsource-case-upper
1989 @item -fsource-case-upper
1990 @cindex -fsource-case-lower option
1991 @cindex options, -fsource-case-lower
1992 @item -fsource-case-lower
1993 @cindex -fsource-case-preserve option
1994 @cindex options, -fsource-case-preserve
1995 @item -fsource-case-preserve
1996 Specify whether source text other than character and Hollerith constants
1997 is to be translated to uppercase, to lowercase, or preserved as is.
1998 @samp{-fsource-case-lower} is the default.
2000 @cindex -fsymbol-case-initcap option
2001 @cindex options, -fsymbol-case-initcap
2002 @item -fsymbol-case-initcap
2003 @cindex -fsymbol-case-upper option
2004 @cindex options, -fsymbol-case-upper
2005 @item -fsymbol-case-upper
2006 @cindex -fsymbol-case-lower option
2007 @cindex options, -fsymbol-case-lower
2008 @item -fsymbol-case-lower
2009 @cindex -fsymbol-case-any option
2010 @cindex options, -fsymbol-case-any
2011 @item -fsymbol-case-any
2012 Specify valid cases for user-defined symbol names.
2013 @samp{-fsymbol-case-any} is the default.
2015 @cindex -fcase-strict-upper option
2016 @cindex options, -fcase-strict-upper
2017 @item -fcase-strict-upper
2018 Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
2019 -fsymbol-case-upper}.
2020 (Requires all pertinent source to be in uppercase.)
2022 @cindex -fcase-strict-lower option
2023 @cindex options, -fcase-strict-lower
2024 @item -fcase-strict-lower
2025 Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
2026 -fsymbol-case-lower}.
2027 (Requires all pertinent source to be in lowercase.)
2029 @cindex -fcase-initcap option
2030 @cindex options, -fcase-initcap
2031 @item -fcase-initcap
2032 Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
2033 -fsymbol-case-initcap}.
2034 (Requires all pertinent source to be in initial capitals,
2035 as in @samp{Print *,SqRt(Value)}.)
2037 @cindex -fcase-upper option
2038 @cindex options, -fcase-upper
2040 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
2042 (Maps all pertinent source to uppercase.)
2044 @cindex -fcase-lower option
2045 @cindex options, -fcase-lower
2047 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
2049 (Maps all pertinent source to lowercase.)
2051 @cindex -fcase-preserve option
2052 @cindex options, -fcase-preserve
2053 @item -fcase-preserve
2054 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
2056 (Preserves all case in user-defined symbols,
2057 while allowing any-case matching of intrinsics and keywords.
2058 For example, @samp{call Foo(i,I)} would pass two @emph{different}
2059 variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)
2061 @cindex -fbadu77-intrinsics-delete option
2062 @cindex options, -fbadu77-intrinsics-delete
2063 @item -fbadu77-intrinsics-delete
2064 @cindex -fbadu77-intrinsics-hide option
2065 @cindex options, -fbadu77-intrinsics-hide
2066 @item -fbadu77-intrinsics-hide
2067 @cindex -fbadu77-intrinsics-disable option
2068 @cindex options, -fbadu77-intrinsics-disable
2069 @item -fbadu77-intrinsics-disable
2070 @cindex -fbadu77-intrinsics-enable option
2071 @cindex options, -fbadu77-intrinsics-enable
2072 @item -fbadu77-intrinsics-enable
2073 @cindex badu77 intrinsics
2074 @cindex intrinsics, badu77
2075 Specify status of UNIX intrinsics having inappropriate forms.
2076 @samp{-fbadu77-intrinsics-enable} is the default.
2077 @xref{Intrinsic Groups}.
2079 @cindex -ff2c-intrinsics-delete option
2080 @cindex options, -ff2c-intrinsics-delete
2081 @item -ff2c-intrinsics-delete
2082 @cindex -ff2c-intrinsics-hide option
2083 @cindex options, -ff2c-intrinsics-hide
2084 @item -ff2c-intrinsics-hide
2085 @cindex -ff2c-intrinsics-disable option
2086 @cindex options, -ff2c-intrinsics-disable
2087 @item -ff2c-intrinsics-disable
2088 @cindex -ff2c-intrinsics-enable option
2089 @cindex options, -ff2c-intrinsics-enable
2090 @item -ff2c-intrinsics-enable
2091 @cindex f2c intrinsics
2092 @cindex intrinsics, f2c
2093 Specify status of f2c-specific intrinsics.
2094 @samp{-ff2c-intrinsics-enable} is the default.
2095 @xref{Intrinsic Groups}.
2097 @cindex -ff90-intrinsics-delete option
2098 @cindex options, -ff90-intrinsics-delete
2099 @item -ff90-intrinsics-delete
2100 @cindex -ff90-intrinsics-hide option
2101 @cindex options, -ff90-intrinsics-hide
2102 @item -ff90-intrinsics-hide
2103 @cindex -ff90-intrinsics-disable option
2104 @cindex options, -ff90-intrinsics-disable
2105 @item -ff90-intrinsics-disable
2106 @cindex -ff90-intrinsics-enable option
2107 @cindex options, -ff90-intrinsics-enable
2108 @item -ff90-intrinsics-enable
2109 @cindex Fortran 90 intrinsics
2110 @cindex intrinsics, Fortran 90
2111 Specify status of F90-specific intrinsics.
2112 @samp{-ff90-intrinsics-enable} is the default.
2113 @xref{Intrinsic Groups}.
2115 @cindex -fgnu-intrinsics-delete option
2116 @cindex options, -fgnu-intrinsics-delete
2117 @item -fgnu-intrinsics-delete
2118 @cindex -fgnu-intrinsics-hide option
2119 @cindex options, -fgnu-intrinsics-hide
2120 @item -fgnu-intrinsics-hide
2121 @cindex -fgnu-intrinsics-disable option
2122 @cindex options, -fgnu-intrinsics-disable
2123 @item -fgnu-intrinsics-disable
2124 @cindex -fgnu-intrinsics-enable option
2125 @cindex options, -fgnu-intrinsics-enable
2126 @item -fgnu-intrinsics-enable
2127 @cindex Digital Fortran features
2128 @cindex COMPLEX intrinsics
2129 @cindex intrinsics, COMPLEX
2130 Specify status of Digital's COMPLEX-related intrinsics.
2131 @samp{-fgnu-intrinsics-enable} is the default.
2132 @xref{Intrinsic Groups}.
2134 @cindex -fmil-intrinsics-delete option
2135 @cindex options, -fmil-intrinsics-delete
2136 @item -fmil-intrinsics-delete
2137 @cindex -fmil-intrinsics-hide option
2138 @cindex options, -fmil-intrinsics-hide
2139 @item -fmil-intrinsics-hide
2140 @cindex -fmil-intrinsics-disable option
2141 @cindex options, -fmil-intrinsics-disable
2142 @item -fmil-intrinsics-disable
2143 @cindex -fmil-intrinsics-enable option
2144 @cindex options, -fmil-intrinsics-enable
2145 @item -fmil-intrinsics-enable
2146 @cindex MIL-STD 1753
2147 @cindex intrinsics, MIL-STD 1753
2148 Specify status of MIL-STD-1753-specific intrinsics.
2149 @samp{-fmil-intrinsics-enable} is the default.
2150 @xref{Intrinsic Groups}.
2152 @cindex -funix-intrinsics-delete option
2153 @cindex options, -funix-intrinsics-delete
2154 @item -funix-intrinsics-delete
2155 @cindex -funix-intrinsics-hide option
2156 @cindex options, -funix-intrinsics-hide
2157 @item -funix-intrinsics-hide
2158 @cindex -funix-intrinsics-disable option
2159 @cindex options, -funix-intrinsics-disable
2160 @item -funix-intrinsics-disable
2161 @cindex -funix-intrinsics-enable option
2162 @cindex options, -funix-intrinsics-enable
2163 @item -funix-intrinsics-enable
2164 @cindex UNIX intrinsics
2165 @cindex intrinsics, UNIX
2166 Specify status of UNIX intrinsics.
2167 @samp{-funix-intrinsics-enable} is the default.
2168 @xref{Intrinsic Groups}.
2170 @cindex -fvxt-intrinsics-delete option
2171 @cindex options, -fvxt-intrinsics-delete
2172 @item -fvxt-intrinsics-delete
2173 @cindex -fvxt-intrinsics-hide option
2174 @cindex options, -fvxt-intrinsics-hide
2175 @item -fvxt-intrinsics-hide
2176 @cindex -fvxt-intrinsics-disable option
2177 @cindex options, -fvxt-intrinsics-disable
2178 @item -fvxt-intrinsics-disable
2179 @cindex -fvxt-intrinsics-enable option
2180 @cindex options, -fvxt-intrinsics-enable
2181 @item -fvxt-intrinsics-enable
2182 @cindex VXT intrinsics
2183 @cindex intrinsics, VXT
2184 Specify status of VXT intrinsics.
2185 @samp{-fvxt-intrinsics-enable} is the default.
2186 @xref{Intrinsic Groups}.
2188 @cindex -ffixed-line-length-@var{n} option
2189 @cindex options, -ffixed-line-length-@var{n}
2190 @item -ffixed-line-length-@var{n}
2191 @cindex source file format
2193 @cindex length of source lines
2194 @cindex fixed-form line length
2195 Set column after which characters are ignored in typical fixed-form
2196 lines in the source file, and through which spaces are assumed (as
2197 if padded to that length) after the ends of short fixed-form lines.
2200 @cindex extended-source option
2201 Popular values for @var{n} include 72 (the
2202 standard and the default), 80 (card image), and 132 (corresponds
2203 to ``extended-source'' options in some popular compilers).
2204 @var{n} may be @samp{none}, meaning that the entire line is meaningful
2205 and that continued character constants never have implicit spaces appended
2206 to them to fill out the line.
2207 @samp{-ffixed-line-length-0} means the same thing as
2208 @samp{-ffixed-line-length-none}.
2210 @xref{Source Form}, for more information.
2213 @node Warning Options
2214 @section Options to Request or Suppress Warnings
2215 @cindex options to control warnings
2216 @cindex warning messages
2217 @cindex messages, warning
2218 @cindex suppressing warnings
2220 Warnings are diagnostic messages that report constructions which
2221 are not inherently erroneous but which are risky or suggest there
2222 might have been an error.
2224 You can request many specific warnings with options beginning @samp{-W},
2225 for example @samp{-Wimplicit} to request warnings on implicit
2226 declarations. Each of these specific warning options also has a
2227 negative form beginning @samp{-Wno-} to turn off warnings;
2228 for example, @samp{-Wno-implicit}. This manual lists only one of the
2229 two forms, whichever is not the default.
2231 These options control the amount and kinds of warnings produced by GNU
2235 @cindex syntax checking
2236 @cindex -fsyntax-only option
2237 @cindex options, -fsyntax-only
2239 Check the code for syntax errors, but don't do anything beyond that.
2241 @cindex -pedantic option
2242 @cindex options, -pedantic
2244 Issue warnings for uses of extensions to ANSI FORTRAN 77.
2245 @samp{-pedantic} also applies to C-language constructs where they
2246 occur in GNU Fortran source files, such as use of @samp{\e} in a
2247 character constant within a directive like @samp{#include}.
2249 Valid ANSI FORTRAN 77 programs should compile properly with or without
2251 However, without this option, certain GNU extensions and traditional
2252 Fortran features are supported as well.
2253 With this option, many of them are rejected.
2255 Some users try to use @samp{-pedantic} to check programs for strict ANSI
2257 They soon find that it does not do quite what they want---it finds some
2258 non-ANSI practices, but not all.
2259 However, improvements to @code{g77} in this area are welcome.
2261 @cindex -pedantic-errors option
2262 @cindex options, -pedantic-errors
2263 @item -pedantic-errors
2264 Like @samp{-pedantic}, except that errors are produced rather than
2267 @cindex -fpedantic option
2268 @cindex options, -fpedantic
2270 Like @samp{-pedantic}, but applies only to Fortran constructs.
2275 Inhibit all warning messages.
2277 @cindex -Wno-globals option
2278 @cindex options, -Wno-globals
2280 @cindex global names, warning
2281 @cindex warnings, global names
2282 Inhibit warnings about use of a name as both a global name
2283 (a subroutine, function, or block data program unit, or a
2284 common block) and implicitly as the name of an intrinsic
2287 Also inhibit warnings about inconsistent invocations and/or
2288 definitions of global procedures (function and subroutines).
2289 Such inconsistencies include different numbers of arguments
2290 and different types of arguments.
2292 @cindex -Wimplicit option
2293 @cindex options, -Wimplicit
2295 @cindex implicit declaration, warning
2296 @cindex warnings, implicit declaration
2298 @cindex /WARNINGS=DECLARATIONS switch
2299 @cindex IMPLICIT NONE, similar effect
2300 @cindex effecting IMPLICIT NONE
2301 Warn whenever a variable, array, or function is implicitly
2303 Has an effect similar to using the @code{IMPLICIT NONE} statement
2304 in every program unit.
2305 (Some Fortran compilers provide this feature by an option
2306 named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)
2308 @cindex -Wunused option
2309 @cindex options, -Wunused
2311 @cindex unused variables
2312 @cindex variables, unused
2313 Warn whenever a variable is unused aside from its declaration.
2315 @cindex -Wuninitialized option
2316 @cindex options, -Wuninitialized
2317 @item -Wuninitialized
2318 @cindex uninitialized variables
2319 @cindex variables, uninitialized
2320 Warn whenever an automatic variable is used without first being initialized.
2322 These warnings are possible only in optimizing compilation,
2323 because they require data-flow information that is computed only
2324 when optimizing. If you don't specify @samp{-O}, you simply won't
2327 These warnings occur only for variables that are candidates for
2328 register allocation. Therefore, they do not occur for a variable
2329 @c that is declared @code{VOLATILE}, or
2330 whose address is taken, or whose size
2331 is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
2332 arrays, even when they are in registers.
2334 Note that there might be no warning about a variable that is used only
2335 to compute a value that itself is never used, because such
2336 computations may be deleted by data-flow analysis before the warnings
2339 These warnings are made optional because GNU Fortran is not smart
2340 enough to see all the reasons why the code might be correct
2341 despite appearing to have an error. Here is one example of how
2345 SUBROUTINE DISPAT(J)
2354 If the value of @code{J} is always 1, 2 or 3, then @code{I} is
2355 always initialized, but GNU Fortran doesn't know this. Here is
2356 another common case:
2359 SUBROUTINE MAYBE(FLAG)
2361 IF (FLAG) VALUE = 9.4
2363 IF (FLAG) PRINT *, VALUE
2368 This has no bug because @code{VALUE} is used only if it is set.
2370 @cindex -Wall option
2371 @cindex options, -Wall
2373 @cindex all warnings
2374 @cindex warnings, all
2375 The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
2377 options which pertain to usage that we recommend avoiding and that we
2378 believe is easy to avoid.
2379 (As more warnings are added to @code{g77}, some might
2380 be added to the list enabled by @samp{-Wall}.)
2383 The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
2384 because they warn about constructions that we consider reasonable to
2385 use, on occasion, in clean programs.
2389 @c Print extra warning messages for these events:
2393 @c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
2398 @cindex -Wsurprising option
2399 @cindex options, -Wsurprising
2401 Warn about ``suspicious'' constructs that are interpreted
2402 by the compiler in a way that might well be surprising to
2403 someone reading the code.
2404 These differences can result in subtle, compiler-dependent
2405 (even machine-dependent) behavioral differences.
2406 The constructs warned about include:
2410 Expressions having two arithmetic operators in a row, such
2412 Such a construct is nonstandard, and can produce
2413 unexpected results in more complicated situations such
2415 @code{g77}, along with many other compilers, interprets
2416 this example differently than many programmers, and a few
2418 Specifically, @code{g77} interprets @samp{X**-Y*Z} as
2419 @samp{(X**(-Y))*Z}, while others might think it should
2420 be interpreted as @samp{X**(-(Y*Z))}.
2422 A revealing example is the constant expression @samp{2**-2*1.},
2423 which @code{g77} evaluates to .25, while others might evaluate
2424 it to 0., the difference resulting from the way precedence affects
2427 (The @samp{-fpedantic} option also warns about expressions
2428 having two arithmetic operators in a row.)
2431 Expressions with a unary minus followed by an operand and then
2432 a binary operator other than plus or minus.
2433 For example, @samp{-2**2} produces a warning, because
2434 the precedence is @samp{-(2**2)}, yielding -4, not
2435 @samp{(-2)**2}, which yields 4, and which might represent
2436 what a programmer expects.
2438 An example of an expression producing different results
2439 in a surprising way is @samp{-I*S}, where @var{I} holds
2440 the value @samp{-2147483648} and @var{S} holds @samp{0.5}.
2441 On many systems, negating @var{I} results in the same
2442 value, not a positive number, because it is already the
2443 lower bound of what an @code{INTEGER(KIND=1)} variable can hold.
2444 So, the expression evaluates to a positive number, while
2445 the ``expected'' interpretation, @samp{(-I)*S}, would
2446 evaluate to a negative number.
2448 Even cases such as @samp{-I*J} produce warnings,
2449 even though, in most configurations and situations,
2450 there is no computational difference between the
2451 results of the two interpretations---the purpose
2452 of this warning is to warn about differing interpretations
2453 and encourage a better style of coding, not to identify
2454 only those places where bugs might exist in the user's
2457 @cindex DO statement
2458 @cindex statements, DO
2460 @code{DO} loops with @code{DO} variables that are not
2461 of integral type---that is, using @code{REAL}
2462 variables as loop control variables.
2463 Although such loops can be written to work in the
2464 ``obvious'' way, the way @code{g77} is required by the
2465 Fortran standard to interpret such code is likely to
2466 be quite different from the way many programmers expect.
2467 (This is true of all @code{DO} loops, but the differences
2468 are pronounced for non-integral loop control variables.)
2470 @xref{Loops}, for more information.
2473 @cindex -Werror option
2474 @cindex options, -Werror
2476 Make all warnings into errors.
2481 @cindex extra warnings
2482 @cindex warnings, extra
2483 Turns on ``extra warnings'' and, if optimization is specified
2484 via @samp{-O}, the @samp{-Wuninitialized} option.
2485 (This might change in future versions of @code{g77}.)
2487 ``Extra warnings'' are issued for:
2491 @cindex unused parameters
2492 @cindex parameters, unused
2493 @cindex unused arguments
2494 @cindex arguments, unused
2495 @cindex unused dummies
2496 @cindex dummies, unused
2497 Unused parameters to a procedure (when @samp{-Wunused} also is
2502 Overflows involving floating-point constants (not available
2503 for certain configurations).
2507 @xref{Warning Options,,Options to Request or Suppress Warnings,
2508 gcc,Using and Porting GNU CC}, for information on more options offered
2509 by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.
2511 Some of these have no effect when compiling programs written in Fortran:
2514 @cindex -Wcomment option
2515 @cindex options, -Wcomment
2517 @cindex -Wformat option
2518 @cindex options, -Wformat
2520 @cindex -Wparentheses option
2521 @cindex options, -Wparentheses
2523 @cindex -Wswitch option
2524 @cindex options, -Wswitch
2526 @cindex -Wtraditional option
2527 @cindex options, -Wtraditional
2529 @cindex -Wshadow option
2530 @cindex options, -Wshadow
2532 @cindex -Wid-clash-@var{len} option
2533 @cindex options, -Wid-clash-@var{len}
2534 @item -Wid-clash-@var{len}
2535 @cindex -Wlarger-than-@var{len} option
2536 @cindex options, -Wlarger-than-@var{len}
2537 @item -Wlarger-than-@var{len}
2538 @cindex -Wconversion option
2539 @cindex options, -Wconversion
2541 @cindex -Waggregate-return option
2542 @cindex options, -Waggregate-return
2543 @item -Waggregate-return
2544 @cindex -Wredundant-decls option
2545 @cindex options, -Wredundant-decls
2546 @item -Wredundant-decls
2547 @cindex unsupported warnings
2548 @cindex warnings, unsupported
2549 These options all could have some relevant meaning for
2550 GNU Fortran programs, but are not yet supported.
2553 @node Debugging Options
2554 @section Options for Debugging Your Program or GNU Fortran
2555 @cindex options, debugging
2556 @cindex debugging information options
2558 GNU Fortran has various special options that are used for debugging
2559 either your program or @code{g77}.
2565 Produce debugging information in the operating system's native format
2566 (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
2569 @cindex common blocks
2570 @cindex equivalence areas
2571 @cindex missing debug features
2572 Support for this option in Fortran programs is incomplete.
2573 In particular, names of variables and arrays in common blocks
2574 or that are storage-associated via @code{EQUIVALENCE} are
2575 unavailable to the debugger.
2577 However, version 0.5.19 of @code{g77} does provide this information
2578 in a rudimentary way, as controlled by the
2579 @samp{-fdebug-kludge} option.
2581 @xref{Code Gen Options,,Options for Code Generation Conventions},
2582 for more information.
2585 @xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
2586 gcc,Using and Porting GNU CC}, for more information on debugging options.
2588 @node Optimize Options
2589 @section Options That Control Optimization
2590 @cindex optimize options
2591 @cindex options, optimization
2593 Most Fortran users will want to use no optimization when
2594 developing and testing programs, and use @samp{-O} or @samp{-O2} when
2595 compiling programs for late-cycle testing and for production use.
2596 However, note that certain diagnostics---such as for uninitialized
2597 variables---depend on the flow analysis done by @samp{-O}, i.e.@: you
2598 must use @samp{-O} or @samp{-O2} to get such diagnostics.
2600 The following flags have particular applicability when
2601 compiling Fortran programs:
2604 @cindex -malign-double option
2605 @cindex options, -malign-double
2606 @item -malign-double
2607 (Intel x86 architecture only.)
2609 Noticeably improves performance of @code{g77} programs making
2610 heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data
2612 In particular, systems using Pentium, Pentium Pro, 586, and
2614 of the i386 architecture execute programs faster when
2615 @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data are
2616 aligned on 64-bit boundaries
2619 This option can, at least, make benchmark results more consistent
2620 across various system configurations, versions of the program,
2623 @emph{Note:} The warning in the @code{gcc} documentation about
2624 this option does not apply, generally speaking, to Fortran
2625 code compiled by @code{g77}.
2627 @emph{Also note:} @samp{-malign-double} applies only to
2628 statically-allocated data.
2629 Double-precision data on the stack can still
2630 cause problems due to misalignment.
2631 @xref{Aligned Data}.
2633 @emph{Also also note:} The negative form of @samp{-malign-double}
2634 is @samp{-mno-align-double}, not @samp{-benign-double}.
2636 @cindex -ffloat-store option
2637 @cindex options, -ffloat-store
2639 @cindex IEEE conformance
2640 @cindex conformance, IEEE
2641 Might help a Fortran program that depends on exact IEEE conformance
2642 on some machines, but might slow down a program that doesn't.
2644 @cindex -fforce-mem option
2645 @cindex options, -fforce-mem
2647 @cindex -fforce-addr option
2648 @cindex options, -fforce-addr
2650 @cindex loops, speeding up
2651 @cindex speeding up loops
2652 Might improve optimization of loops.
2654 @cindex -fno-inline option
2655 @cindex options, -fno-inline
2657 @cindex in-line compilation
2658 @cindex compilation, in-line
2659 @c DL: Only relevant for -O3?
2660 Don't compile statement functions inline.
2661 Might reduce the size of a program unit---which might be at
2662 expense of some speed (though it should compile faster).
2663 Note that if you are not optimizing, no functions can be expanded inline.
2665 @cindex -ffast-math option
2666 @cindex options, -ffast-math
2668 @cindex IEEE conformance
2669 @cindex conformance, IEEE
2670 Might allow some programs designed to not be too dependent
2671 on IEEE behavior for floating-point to run faster, or die trying.
2673 @cindex -fstrength-reduce option
2674 @cindex options, -fstrength-reduce
2675 @item -fstrength-reduce
2676 @cindex loops, speeding up
2677 @cindex speeding up loops
2678 @c DL: normally defaulted?
2679 Might make some loops run faster.
2681 @cindex -frerun-cse-after-loop option
2682 @cindex options, -frerun-cse-after-loop
2683 @item -frerun-cse-after-loop
2684 @cindex -fexpensive-optimizations option
2685 @cindex options, -fexpensive-optimizations
2687 @item -fexpensive-optimizations
2688 @cindex -fdelayed-branch option
2689 @cindex options, -fdelayed-branch
2690 @item -fdelayed-branch
2691 @cindex -fschedule-insns option
2692 @cindex options, -fschedule-insns
2693 @item -fschedule-insns
2694 @cindex -fschedule-insns2 option
2695 @cindex options, -fschedule-insns2
2696 @item -fschedule-insns2
2697 @cindex -fcaller-saves option
2698 @cindex options, -fcaller-saves
2699 @item -fcaller-saves
2700 Might improve performance on some code.
2702 @cindex -funroll-loops option
2703 @cindex options, -funroll-loops
2704 @item -funroll-loops
2705 @cindex loops, unrolling
2706 @cindex unrolling loops
2707 Definitely improves performance on some code.
2709 @cindex -funroll-all-loops option
2710 @cindex options, -funroll-all-loops
2711 @item -funroll-all-loops
2712 @c DL: Is this really true? What _are_ the semantics of this option?
2713 Improves performance on some code.
2715 @item -fno-move-all-movables
2716 @cindex -fno-move-all-movables option
2717 @cindex options, -fno-move-all-movables
2718 @item -fno-reduce-all-givs
2719 @cindex -fno-reduce-all-givs option
2720 @cindex options, -fno-reduce-all-givs
2721 @item -fno-rerun-loop-opt
2722 @cindex -fno-rerun-loop-opt option
2723 @cindex options, -fno-rerun-loop-opt
2724 @emph{Version info:}
2725 These options are not supported by
2726 versions of @code{g77} based on @code{gcc} version 2.8.
2728 Each of these might improve performance on some code.
2730 Analysis of Fortran code optimization and the resulting
2731 optimizations triggered by the above options were
2732 contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).
2734 These three options are intended to be removed someday, once
2735 they have helped determine the efficacy of various
2736 approaches to improving the performance of Fortran code.
2738 Please let us know how use of these options affects
2739 the performance of your production code.
2740 We're particularly interested in code that runs faster
2741 when these options are @emph{disabled}, and in
2742 non-Fortran code that benefits when they are
2743 @emph{enabled} via the above @code{gcc} command-line options.
2746 @xref{Optimize Options,,Options That Control Optimization,
2747 gcc,Using and Porting GNU CC}, for more information on options
2748 to optimize the generated machine code.
2750 @node Preprocessor Options
2751 @section Options Controlling the Preprocessor
2752 @cindex preprocessor options
2753 @cindex options, preprocessor
2755 @cindex programs, cpp
2757 These options control the C preprocessor, which is run on each C source
2758 file before actual compilation.
2760 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
2761 gcc,Using and Porting GNU CC}, for information on C preprocessor options.
2763 @cindex INCLUDE directive
2764 @cindex directive, INCLUDE
2765 Some of these options also affect how @code{g77} processes the
2766 @code{INCLUDE} directive.
2767 Since this directive is processed even when preprocessing
2768 is not requested, it is not described in this section.
2769 @xref{Directory Options,,Options for Directory Search}, for
2770 information on how @code{g77} processes the @code{INCLUDE} directive.
2772 However, the @code{INCLUDE} directive does not apply
2773 preprocessing to the contents of the included file itself.
2775 Therefore, any file that contains preprocessor directives
2776 (such as @code{#include}, @code{#define}, and @code{#if})
2777 must be included via the @code{#include} directive, not
2778 via the @code{INCLUDE} directive.
2779 Therefore, any file containing preprocessor directives,
2780 if included, is necessarily included by a file that itself
2781 contains preprocessor directives.
2783 @node Directory Options
2784 @section Options for Directory Search
2785 @cindex directory options
2786 @cindex options, directory search
2789 These options affect how the @code{cpp} preprocessor searches
2790 for files specified via the @code{#include} directive.
2791 Therefore, when compiling Fortran programs, they are meaningful
2792 when the preprocessor is used.
2794 @cindex INCLUDE directive
2795 @cindex directive, INCLUDE
2796 Some of these options also affect how @code{g77} searches
2797 for files specified via the @code{INCLUDE} directive,
2798 although files included by that directive are not,
2799 themselves, preprocessed.
2804 @cindex options, -I-
2806 @cindex -Idir option
2807 @cindex options, -Idir
2809 @cindex directory search paths for inclusion
2810 @cindex inclusion, directory search paths for
2811 @cindex searching for included files
2812 These affect interpretation of the @code{INCLUDE} directive
2813 (as well as of the @code{#include} directive of the @code{cpp}
2816 Note that @samp{-I@var{dir}} must be specified @emph{without} any
2817 spaces between @samp{-I} and the directory name---that is,
2818 @samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
2819 is rejected by the @code{g77} compiler (though the preprocessor supports
2821 @c this is due to toplev.c's inflexible option processing
2822 Also note that the general behavior of @samp{-I} and
2823 @code{INCLUDE} is pretty much the same as of @samp{-I} with
2824 @code{#include} in the @code{cpp} preprocessor, with regard to
2825 looking for @file{header.gcc} files and other such things.
2827 @xref{Directory Options,,Options for Directory Search,
2828 gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
2831 @node Code Gen Options
2832 @section Options for Code Generation Conventions
2833 @cindex code generation conventions
2834 @cindex options, code generation
2835 @cindex run-time options
2837 These machine-independent options control the interface conventions
2838 used in code generation.
2840 Most of them have both positive and negative forms; the negative form
2841 of @samp{-ffoo} would be @samp{-fno-foo}. In the table below, only
2842 one of the forms is listed---the one which is not the default. You
2843 can figure out the other form by either removing @samp{no-} or adding
2847 @cindex -fno-automatic option
2848 @cindex options, -fno-automatic
2849 @item -fno-automatic
2850 @cindex SAVE statement
2851 @cindex statements, SAVE
2852 Treat each program unit as if the @code{SAVE} statement was specified
2853 for every local variable and array referenced in it.
2854 Does not affect common blocks.
2855 (Some Fortran compilers provide this option under
2856 the name @samp{-static}.)
2858 @cindex -finit-local-zero option
2859 @cindex options, -finit-local-zero
2860 @item -finit-local-zero
2861 @cindex DATA statement
2862 @cindex statements, DATA
2863 @cindex initialization of local variables
2864 @cindex variables, initialization of
2865 @cindex uninitialized variables
2866 @cindex variables, uninitialized
2867 Specify that variables and arrays that are local to a program unit
2868 (not in a common block and not passed as an argument) are to be initialized
2871 Since there is a run-time penalty for initialization of variables
2872 that are not given the @code{SAVE} attribute, it might be a
2873 good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.
2875 @cindex -fno-f2c option
2876 @cindex options, -fno-f2c
2878 @cindex @code{f2c} compatibility
2879 @cindex compatibility, @code{f2c}
2880 Do not generate code designed to be compatible with code generated
2881 by @code{f2c}; use the GNU calling conventions instead.
2883 The @code{f2c} calling conventions require functions that return
2884 type @code{REAL(KIND=1)} to actually return the C type @code{double},
2885 and functions that return type @code{COMPLEX} to return the
2886 values via an extra argument in the calling sequence that points
2887 to where to store the return value.
2888 Under the GNU calling conventions, such functions simply return
2889 their results as they would in GNU C---@code{REAL(KIND=1)} functions
2890 return the C type @code{float}, and @code{COMPLEX} functions
2891 return the GNU C type @code{complex} (or its @code{struct}
2894 This does not affect the generation of code that interfaces with the
2895 @code{libg2c} library.
2897 However, because the @code{libg2c} library uses @code{f2c}
2898 calling conventions, @code{g77} rejects attempts to pass
2899 intrinsics implemented by routines in this library as actual
2900 arguments when @samp{-fno-f2c} is used, to avoid bugs when
2901 they are actually called by code expecting the GNU calling
2902 conventions to work.
2904 For example, @samp{INTRINSIC ABS;CALL FOO(ABS)} is
2905 rejected when @samp{-fno-f2c} is in force.
2906 (Future versions of the @code{g77} run-time library might
2907 offer routines that provide GNU-callable versions of the
2908 routines that implement the @code{f2c}-callable intrinsics
2909 that may be passed as actual arguments, so that
2910 valid programs need not be rejected when @samp{-fno-f2c}
2913 @strong{Caution:} If @samp{-fno-f2c} is used when compiling any
2914 source file used in a program, it must be used when compiling
2915 @emph{all} Fortran source files used in that program.
2917 @c seems kinda dumb to tell people about an option they can't use -- jcb
2918 @c then again, we want users building future-compatible libraries with it.
2919 @cindex -ff2c-library option
2920 @cindex options, -ff2c-library
2922 Specify that use of @code{libg2c} (or the original @code{libf2c})
2924 This is the default for the current version of @code{g77}.
2927 valid to specify @samp{-fno-f2c-library}.
2928 This option is provided so users can specify it in shell
2929 scripts that build programs and libraries that require the
2930 @code{libf2c} library, even when being compiled by future
2931 versions of @code{g77} that might otherwise default to
2932 generating code for an incompatible library.
2934 @cindex -fno-underscoring option
2935 @cindex options, -fno-underscoring
2936 @item -fno-underscoring
2938 @cindex symbol names, underscores
2939 @cindex transforming symbol names
2940 @cindex symbol names, transforming
2941 Do not transform names of entities specified in the Fortran
2942 source file by appending underscores to them.
2944 With @samp{-funderscoring} in effect, @code{g77} appends two underscores
2945 to names with underscores and one underscore to external names with
2946 no underscores. (@code{g77} also appends two underscores to internal
2947 names with underscores to avoid naming collisions with external names.
2948 The @samp{-fno-second-underscore} option disables appending of the
2949 second underscore in all cases.)
2951 This is done to ensure compatibility with code produced by many
2952 UNIX Fortran compilers, including @code{f2c}, which perform the
2953 same transformations.
2955 Use of @samp{-fno-underscoring} is not recommended unless you are
2956 experimenting with issues such as integration of (GNU) Fortran into
2957 existing system environments (vis-a-vis existing libraries, tools, and
2960 For example, with @samp{-funderscoring}, and assuming other defaults like
2961 @samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
2962 external functions while @samp{my_var} and @samp{lvar} are local variables,
2966 I = J() + MAX_COUNT (MY_VAR, LVAR)
2970 is implemented as something akin to:
2973 i = j_() + max_count__(&my_var__, &lvar);
2976 With @samp{-fno-underscoring}, the same statement is implemented as:
2979 i = j() + max_count(&my_var, &lvar);
2982 Use of @samp{-fno-underscoring} allows direct specification of
2983 user-defined names while debugging and when interfacing @code{g77}-compiled
2984 code with other languages.
2986 Note that just because the names match does @emph{not} mean that the
2987 interface implemented by @code{g77} for an external name matches the
2988 interface implemented by some other language for that same name.
2989 That is, getting code produced by @code{g77} to link to code produced
2990 by some other compiler using this or any other method can be only a
2991 small part of the overall solution---getting the code generated by
2992 both compilers to agree on issues other than naming can require
2993 significant effort, and, unlike naming disagreements, linkers normally
2994 cannot detect disagreements in these other areas.
2996 Also, note that with @samp{-fno-underscoring}, the lack of appended
2997 underscores introduces the very real possibility that a user-defined
2998 external name will conflict with a name in a system library, which
2999 could make finding unresolved-reference bugs quite difficult in some
3000 cases---they might occur at program run time, and show up only as
3001 buggy behavior at run time.
3003 In future versions of @code{g77}, we hope to improve naming and linking
3004 issues so that debugging always involves using the names as they appear
3005 in the source, even if the names as seen by the linker are mangled to
3006 prevent accidental linking between procedures with incompatible
3009 @cindex -fno-second-underscore option
3010 @cindex options, -fno-second-underscore
3011 @item -fno-second-underscore
3013 @cindex symbol names, underscores
3014 @cindex transforming symbol names
3015 @cindex symbol names, transforming
3016 Do not append a second underscore to names of entities specified
3017 in the Fortran source file.
3019 This option has no effect if @samp{-fno-underscoring} is
3022 Otherwise, with this option, an external name such as @samp{MAX_COUNT}
3023 is implemented as a reference to the link-time external symbol
3024 @samp{max_count_}, instead of @samp{max_count__}.
3026 @cindex -fno-ident option
3027 @cindex options, -fno-ident
3029 Ignore the @samp{#ident} directive.
3031 @cindex -fzeros option
3032 @cindex options, -fzeros
3034 Treat initial values of zero as if they were any other value.
3036 As of version 0.5.18, @code{g77} normally treats @code{DATA} and
3037 other statements that are used to specify initial values of zero
3038 for variables and arrays as if no values were actually specified,
3039 in the sense that no diagnostics regarding multiple initializations
3042 This is done to speed up compiling of programs that initialize
3043 large arrays to zeros.
3045 Use @samp{-fzeros} to revert to the simpler, slower behavior
3046 that can catch multiple initializations by keeping track of
3047 all initializations, zero or otherwise.
3049 @emph{Caution:} Future versions of @code{g77} might disregard this option
3050 (and its negative form, the default) or interpret it somewhat
3052 The interpretation changes will affect only non-standard
3053 programs; standard-conforming programs should not be affected.
3055 @cindex -fdebug-kludge option
3056 @cindex options, -fdebug-kludge
3057 @item -fdebug-kludge
3058 Emit information on @code{COMMON} and @code{EQUIVALENCE} members
3059 that might help users of debuggers work around lack of proper debugging
3060 information on such members.
3062 As of version 0.5.19, @code{g77} offers this option to emit
3063 information on members of aggregate areas to help users while debugging.
3064 This information consists of establishing the type and contents of each
3065 such member so that, when a debugger is asked to print the contents,
3066 the printed information provides rudimentary debugging information.
3067 This information identifies the name of the aggregate area (either the
3068 @code{COMMON} block name, or the @code{g77}-assigned name for the
3069 @code{EQUIVALENCE} name) and the offset, in bytes, of the member from
3070 the beginning of the area.
3072 Using @code{gdb}, this information is not coherently displayed in the Fortran
3073 language mode, so temporarily switching to the C language mode to display the
3074 information is suggested.
3075 Use @samp{set language c} and @samp{set language fortran} to accomplish this.
3083 EQUIVALENCE (I,XX(20:20))
3086 GDB is free software and you are welcome to distribute copies of it
3087 under certain conditions; type "show copying" to see the conditions.
3088 There is absolutely no warranty for GDB; type "show warranty" for details.
3089 GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
3091 Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
3093 Starting program: /home/user/a.out
3095 Breakpoint 1, MAIN__ () at cd.f:5
3096 Current language: auto; currently fortran
3097 (gdb) set language c
3098 Warning: the current language does not match this frame.
3100 $2 = "At (COMMON) `x_' plus 0 bytes"
3102 $3 = "At (COMMON) `x_' plus 4 bytes"
3104 $4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3106 $5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3108 $6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
3110 $7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
3111 (gdb) set language fortran
3116 Use @samp{-fdebug-kludge} to generate this information,
3117 which might make some programs noticeably larger.
3119 @emph{Caution:} Future versions of @code{g77} might disregard this option
3120 (and its negative form).
3121 Current plans call for this to happen when published versions of @code{g77}
3122 and @code{gdb} exist that provide proper access to debugging information on
3123 @code{COMMON} and @code{EQUIVALENCE} members.
3125 @cindex -fno-emulate-complex option
3126 @cindex options, -fno-emulate-complex
3127 @item -fno-emulate-complex
3128 Implement @code{COMPLEX} arithmetic using the facilities in
3129 the @code{gcc} back end that provide direct support of
3130 @code{complex} arithmetic, instead of emulating the arithmetic.
3132 @code{gcc} has some known problems in its back-end support
3133 for @code{complex} arithmetic, due primarily to the support not being
3134 completed as of version 2.7.2.2.
3135 Other front ends for the @code{gcc} back end avoid this problem
3136 by emulating @code{complex} arithmetic at a higher level, so the
3137 back end sees arithmetic on the real and imaginary components.
3138 To make @code{g77} more portable to systems where @code{complex}
3139 support in the @code{gcc} back end is particularly troublesome,
3140 @code{g77} now defaults to performing the same kinds of emulations
3141 done by these other front ends.
3143 Use @samp{-fno-emulate-complex} to try the @code{complex} support
3144 in the @code{gcc} back end, in case it works and produces faster
3146 So far, all the known bugs seem to involve compile-time crashes,
3147 rather than the generation of incorrect code.
3149 Use of this option should not affect how Fortran code compiled
3150 by @code{g77} works in terms of its interfaces to other code,
3151 e.g. that compiled by @code{f2c}.
3153 @emph{Caution:} Future versions of @code{g77} are likely to change
3154 the default for this option to
3155 @samp{-fno-emulate-complex}, and perhaps someday ignore both forms
3158 Also, it is possible that use of the @samp{-fno-emulate-complex} option
3159 could result in incorrect code being silently produced by @code{g77}.
3160 But, this is generally true of compilers anyway, so, as usual, test
3161 the programs you compile before assuming they are working.
3163 @cindex -falias-check option
3164 @cindex options, -falias-check
3165 @cindex -fargument-alias option
3166 @cindex options, -fargument-alias
3167 @cindex -fargument-noalias option
3168 @cindex options, -fargument-noalias
3169 @cindex -fno-argument-noalias-global option
3170 @cindex options, -fno-argument-noalias-global
3172 @item -fargument-alias
3173 @item -fargument-noalias
3174 @item -fno-argument-noalias-global
3175 @emph{Version info:}
3176 These options are not supported by
3177 versions of @code{g77} based on @code{gcc} version 2.8.
3179 These options specify to what degree aliasing
3181 is permitted between
3182 arguments (passed as pointers) and @code{COMMON} (external, or
3185 The default for Fortran code, as mandated by the FORTRAN 77 and
3186 Fortran 90 standards, is @samp{-fargument-noalias-global}.
3187 The default for code written in the C language family is
3188 @samp{-fargument-alias}.
3190 Note that, on some systems, compiling with @samp{-fforce-addr} in
3191 effect can produce more optimal code when the default aliasing
3192 options are in effect (and when optimization is enabled).
3194 @xref{Aliasing Assumed To Work}, for detailed information on the implications
3195 of compiling Fortran code that depends on the ability to alias dummy
3198 @cindex -fno-globals option
3199 @cindex options, -fno-globals
3201 @cindex global names, warning
3202 @cindex warnings, global names
3203 Disable diagnostics about inter-procedural
3204 analysis problems, such as disagreements about the
3205 type of a function or a procedure's argument,
3206 that might cause a compiler crash when attempting
3207 to inline a reference to a procedure within a
3209 (The diagnostics themselves are still produced, but
3210 as warnings, unless @samp{-Wno-globals} is specified,
3211 in which case no relevant diagnostics are produced.)
3213 Further, this option disables such inlining, to
3214 avoid compiler crashes resulting from incorrect
3215 code that would otherwise be diagnosed.
3217 As such, this option might be quite useful when
3218 compiling existing, ``working'' code that happens
3219 to have a few bugs that do not generally show
3220 themselves, but @code{g77} exposes via a
3223 Use of this option therefore has the effect of
3224 instructing @code{g77} to behave more like it did
3225 up through version 0.5.19.1, when it paid little or
3226 no attention to disagreements between program units
3227 about a procedure's type and argument information,
3228 and when it performed no inlining of procedures
3229 (except statement functions).
3231 Without this option, @code{g77} defaults to performing
3232 the potentially inlining procedures as it started doing
3233 in version 0.5.20, but as of version 0.5.21, it also
3234 diagnoses disagreements that might cause such inlining
3235 to crash the compiler.
3238 @xref{Code Gen Options,,Options for Code Generation Conventions,
3239 gcc,Using and Porting GNU CC}, for information on more options
3241 shared by @code{g77}, @code{gcc}, and other GNU compilers.
3243 Some of these do @emph{not} work when compiling programs written in Fortran:
3246 @cindex -fpcc-struct-return option
3247 @cindex options, -fpcc-struct-return
3248 @item -fpcc-struct-return
3249 @cindex -freg-struct-return option
3250 @cindex options, -freg-struct-return
3251 @item -freg-struct-return
3252 You should not use these except strictly the same way as you
3253 used them to build the version of @code{libg2c} with which
3254 you will be linking all code compiled by @code{g77} with the
3257 @cindex -fshort-double option
3258 @cindex options, -fshort-double
3259 @item -fshort-double
3260 This probably either has no effect on Fortran programs, or
3261 makes them act loopy.
3263 @cindex -fno-common option
3264 @cindex options, -fno-common
3266 Do not use this when compiling Fortran programs,
3267 or there will be Trouble.
3269 @cindex -fpack-struct option
3270 @cindex options, -fpack-struct
3272 This probably will break any calls to the @code{libg2c} library,
3273 at the very least, even if it is built with the same option.
3276 @node Environment Variables
3277 @section Environment Variables Affecting GNU Fortran
3278 @cindex environment variables
3280 GNU Fortran currently does not make use of any environment
3281 variables to control its operation above and beyond those
3282 that affect the operation of @code{gcc}.
3284 @xref{Environment Variables,,Environment Variables Affecting GNU CC,
3285 gcc,Using and Porting GNU CC}, for information on environment
3291 @chapter User-visible Changes
3292 @cindex versions, recent
3293 @cindex recent versions
3294 @cindex changes, user-visible
3295 @cindex user-visible changes
3297 This section describes changes to @code{g77} that are visible
3298 to the programmers who actually write and maintain Fortran
3299 code they compile with @code{g77}.
3300 Information on changes to installation procedures,
3301 changes to the documentation, and bug fixes is
3302 not provided here, unless it is likely to affect how
3303 users use @code{g77}.
3304 @xref{News,,News About GNU Fortran}, for information on
3305 such changes to @code{g77}.
3307 To find out about existing bugs and ongoing plans for GNU
3308 Fortran, retrieve @uref{ftp://alpha.gnu.org/g77.plan}
3309 or, if you cannot do that, email
3310 @email{fortran@@gnu.org} asking for a recent copy of the
3311 GNU Fortran @file{.plan} file.
3313 @heading In @code{egcs} 1.1:
3316 @code{g77} now treats @samp{%LOC(@var{expr})} and
3317 @samp{LOC(@var{expr})} as ``ordinary'' expressions
3318 when they are used as arguments in procedure calls.
3319 This change applies only to global (filewide) analysis,
3320 making it consistent with
3321 how @code{g77} actually generates code
3324 Previously, @code{g77} treated these expressions
3325 as denoting special ``pointer'' arguments
3326 for the purposes of filewide analysis.
3329 The @code{g77} driver now ensures that @samp{-lg2c}
3330 is specified in the link phase prior to any
3331 occurrence of @samp{-lm}.
3332 This prevents accidentally linking to a routine
3333 in the SunOS4 @samp{-lm} library
3334 when the generated code wants to link to the one
3335 in @code{libf2c} (@code{libg2c}).
3338 The F90 @samp{DATE_AND_TIME} intrinsic now is
3342 The F90 @samp{SYSTEM_CLOCK} intrinsic allows
3343 the optional arguments (except for the @samp{Count}
3344 argument) to be omitted.
3347 Upgrade to @code{libf2c} as of 1998-06-18.
3353 This release contains several regressions against
3354 version 0.5.22 of @code{g77}, due to using the
3355 ``vanilla'' @code{gcc} back end instead of patching
3356 it to fix a few bugs and improve performance in a
3359 @xref{Actual Bugs,,Actual Bugs We Haven't Fixed Yet},
3360 available in plain-text format in @code{gcc/f/BUGS},
3361 for information on the known bugs in this version,
3362 including the regressions.
3364 Features that have been dropped from this version
3365 of @code{g77} due to their being implemented
3366 via @code{g77}-specific patches to the @code{gcc}
3367 back end in previous releases include:
3371 Support for @code{__restrict__} keyword,
3372 the options @samp{-fargument-alias}, @samp{-fargument-noalias},
3373 and @samp{-fargument-noalias-global},
3374 and the corresponding alias-analysis code.
3376 (Version 1.0.1 of @code{egcs} has the alias-analysis
3377 code, but not the @code{__restrict__} keyword.
3378 @code{egcs} @code{g77} users benefit from the alias-analysis
3379 code despite the lack of the @code{__restrict__} keyword,
3380 which is a C-language construct.)
3383 Support for the GNU compiler options
3384 @samp{-fmove-all-movables},
3385 @samp{-freduce-all-givs},
3386 and @samp{-frerun-loop-opt}.
3388 (Version 1.0.1 of @code{egcs} supports these options.
3389 @code{g77} users of @code{egcs} benefit from them even if
3390 they are not explicitly specified,
3391 because the defaults are optimized for @code{g77} users.)
3394 Support for the @samp{-W} option warning about
3395 integer division by zero.
3398 The Intel x86-specific option @samp{-malign-double}
3399 applying to stack-allocated data
3400 as well as statically-allocate data.
3404 Support @code{gcc} version 2.8,
3405 and remove support for prior versions of @code{gcc}.
3407 @cindex -@w{}-driver option
3408 @cindex g77 options, -@w{}-driver
3409 @cindex options, -@w{}-driver
3411 Remove support for the @samp{--driver} option,
3412 as @code{g77} now does all the driving,
3413 just like @code{gcc}.
3416 The @code{g77} command now expects the run-time library
3417 to be named @code{libg2c.a} instead of @code{libf2c.a},
3418 to ensure that a version other than the one built and
3419 installed as part of the same @code{g77} version is picked up.
3422 @code{g77}'s version of @code{libf2c} separates out
3423 the setting of global state
3424 (such as command-line arguments and signal handling)
3425 from @file{main.o} into distinct, new library
3428 This should make it easier to write portable applications
3429 that have their own (non-Fortran) @code{main()} routine
3430 properly set up the @code{libf2c} environment, even
3431 when @code{libf2c} (now @code{libg2c}) is a shared library.
3434 Some diagnostics have been changed from warnings to errors,
3435 to prevent inadvertent use of the resulting, probably buggy,
3437 These mostly include diagnostics about use of unsupported features
3438 in the @code{OPEN}, @code{INQUIRE}, @code{READ}, and
3439 @code{WRITE} statements,
3440 and about truncations of various sorts of constants.
3446 Fix @code{SIGNAL} intrinsic so it offers portable
3447 support for 64-bit systems (such as Digital Alphas
3451 Support @samp{FORMAT(I<@var{expr}>)} when @var{expr} is a
3452 compile-time constant @code{INTEGER} expression.
3455 Fix @code{g77} @samp{-g} option so procedures that
3456 use @samp{ENTRY} can be stepped through, line by line,
3460 Allow any @code{REAL} argument to intrinsics
3461 @code{Second} and @code{CPU_Time}.
3464 Allow any numeric argument to intrinsics
3465 @code{Int2} and @code{Int8}.
3468 Use @code{tempnam}, if available, to open scratch files
3469 (as in @samp{OPEN(STATUS='SCRATCH')}
3470 so that the @code{TMPDIR} environment variable,
3471 if present, is used.
3474 Rename the @code{gcc} keyword @code{restrict} to
3475 @code{__restrict__}, to avoid rejecting valid, existing,
3477 Support for @code{restrict} is now more like support
3481 Fix @samp{-fugly-comma} to affect invocations of
3482 only external procedures.
3483 Restore rejection of gratuitous trailing omitted
3484 arguments to intrinsics, as in @samp{I=MAX(3,4,,)}.
3487 Fix compiler so it accepts @samp{-fgnu-intrinsics-*} and
3488 @samp{-fbadu77-intrinsics-*} options.
3494 When the @samp{-W} option is specified, @code{gcc}, @code{g77},
3495 and other GNU compilers that incorporate the @code{gcc}
3496 back end as modified by @code{g77}, issue
3497 a warning about integer division by constant zero.
3500 New option @samp{-Wno-globals} disables warnings
3501 about ``suspicious'' use of a name both as a global
3502 name and as the implicit name of an intrinsic, and
3503 warnings about disagreements over the number or natures of
3504 arguments passed to global procedures, or the
3505 natures of the procedures themselves.
3507 The default is to issue such warnings, which are
3508 new as of this version of @code{g77}.
3511 New option @samp{-fno-globals} disables diagnostics
3512 about potentially fatal disagreements
3513 analysis problems, such as disagreements over the
3514 number or natures of arguments passed to global
3515 procedures, or the natures of those procedures themselves.
3517 The default is to issue such diagnostics and flag
3518 the compilation as unsuccessful.
3519 With this option, the diagnostics are issued as
3520 warnings, or, if @samp{-Wno-globals} is specified,
3521 are not issued at all.
3523 This option also disables inlining of global procedures,
3524 to avoid compiler crashes resulting from coding errors
3525 that these diagnostics normally would identify.
3528 Fix @code{libU77} routines that accept file names
3529 to strip trailing spaces from them, for consistency
3530 with other implementations.
3533 Fix @code{SIGNAL} intrinsic so it accepts an
3534 optional third @samp{Status} argument.
3537 Make many changes to @code{libU77} intrinsics to
3538 support existing code more directly.
3540 Such changes include allowing both subroutine and
3541 function forms of many routines, changing @code{MCLOCK()}
3542 and @code{TIME()} to return @code{INTEGER(KIND=1)} values,
3543 introducing @code{MCLOCK8()} and @code{TIME8()} to
3544 return @code{INTEGER(KIND=2)} values,
3545 and placing functions that are intended to perform
3546 side effects in a new intrinsic group, @code{badu77}.
3549 Add options @samp{-fbadu77-intrinsics-delete},
3550 @samp{-fbadu77-intrinsics-hide}, and so on.
3553 Add @code{INT2} and @code{INT8} intrinsics.
3556 Add @code{CPU_TIME} intrinsic.
3559 @code{CTIME} intrinsic now accepts any @code{INTEGER}
3560 argument, not just @code{INTEGER(KIND=2)}.
3566 The @samp{-fno-typeless-boz} option is now the default.
3568 This option specifies that non-decimal-radix
3569 constants using the prefixed-radix form (such as @samp{Z'1234'})
3570 are to be interpreted as @code{INTEGER(KIND=1)} constants.
3571 Specify @samp{-ftypeless-boz} to cause such
3572 constants to be interpreted as typeless.
3574 (Version 0.5.19 introduced @samp{-fno-typeless-boz} and
3577 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
3578 for information on the @samp{-ftypeless-boz} option.
3581 Options @samp{-ff90-intrinsics-enable} and
3582 @samp{-fvxt-intrinsics-enable} now are the
3585 Some programs might use names that clash with
3586 intrinsic names defined (and now enabled) by these
3587 options or by the new @code{libU77} intrinsics.
3588 Users of such programs might need to compile them
3589 differently (using, for example, @samp{-ff90-intrinsics-disable})
3590 or, better yet, insert appropriate @code{EXTERNAL}
3591 statements specifying that these names are not intended
3592 to be names of intrinsics.
3595 The @samp{ALWAYS_FLUSH} macro is no longer defined when
3596 building @code{libf2c}, which should result in improved
3597 I/O performance, especially over NFS.
3599 @emph{Note:} If you have code that depends on the behavior
3600 of @code{libf2c} when built with @samp{ALWAYS_FLUSH} defined,
3601 you will have to modify @code{libf2c} accordingly before
3602 building it from this and future versions of @code{g77}.
3604 @xref{Output Assumed To Flush}, for more information.
3607 Dave Love's implementation of @code{libU77} has been
3608 added to the version of @code{libf2c} distributed with
3609 and built by @code{g77}.
3610 @code{g77} now knows about the routines in this library
3614 New option @samp{-fvxt} specifies that the
3615 source file is written in VXT Fortran, instead of GNU Fortran.
3617 @xref{VXT Fortran}, for more information on the constructs
3618 recognized when the @samp{-fvxt} option is specified.
3621 The @samp{-fvxt-not-f90} option has been deleted,
3622 along with its inverse, @samp{-ff90-not-vxt}.
3624 If you used one of these deleted options, you should
3625 re-read the pertinent documentation to determine which
3626 options, if any, are appropriate for compiling your
3627 code with this version of @code{g77}.
3629 @xref{Other Dialects}, for more information.
3632 The @samp{-fugly} option now issues a warning, as it
3633 likely will be removed in a future version.
3635 (Enabling all the @samp{-fugly-*} options is unlikely
3636 to be feasible, or sensible, in the future,
3637 so users should learn to specify only those
3638 @samp{-fugly-*} options they really need for a
3639 particular source file.)
3642 The @samp{-fugly-assumed} option, introduced in
3643 version 0.5.19, has been changed to
3644 better accommodate old and new code.
3645 @xref{Ugly Assumed-Size Arrays}, for more information.
3648 Related to supporting Alpha (AXP) machines, the @code{LOC()}
3649 intrinsic and @code{%LOC()} construct now return
3650 values of @code{INTEGER(KIND=0)} type,
3651 as defined by the GNU Fortran language.
3653 This type is wide enough
3654 (holds the same number of bits)
3655 as the character-pointer type on the machine.
3657 On most systems, this won't make a noticeable difference,
3658 whereas on Alphas and other systems with 64-bit pointers,
3659 the @code{INTEGER(KIND=0)} type is equivalent to @code{INTEGER(KIND=2)}
3660 (often referred to as @code{INTEGER*8})
3661 instead of the more common @code{INTEGER(KIND=1)}
3662 (often referred to as @code{INTEGER*4}).
3665 Emulate @code{COMPLEX} arithmetic in the @code{g77} front
3666 end, to avoid bugs in @code{complex} support in the
3667 @code{gcc} back end.
3668 New option @samp{-fno-emulate-complex}
3669 causes @code{g77} to revert the 0.5.19 behavior.
3672 Dummy arguments are no longer assumed to potentially alias
3674 other dummy arguments or @code{COMMON} areas when any of
3675 these are defined (assigned to) by Fortran code.
3677 This can result in faster and/or smaller programs when
3678 compiling with optimization enabled, though on some
3679 systems this effect is observed only when @samp{-fforce-addr}
3682 New options @samp{-falias-check}, @samp{-fargument-alias},
3683 @samp{-fargument-noalias},
3684 and @samp{-fno-argument-noalias-global} control the
3685 way @code{g77} handles potential aliasing.
3687 @xref{Aliasing Assumed To Work}, for detailed information on why the
3688 new defaults might result in some programs no longer working the way they
3689 did when compiled by previous versions of @code{g77}.
3692 New option @samp{-fugly-assign} specifies that the
3693 same memory locations are to be used to hold the
3694 values assigned by both statements @samp{I = 3} and
3695 @samp{ASSIGN 10 TO I}, for example.
3696 (Normally, @code{g77} uses a separate memory location
3697 to hold assigned statement labels.)
3699 @xref{Ugly Assigned Labels}, for more information.
3702 @code{FORMAT} and @code{ENTRY} statements now are allowed to
3703 precede @code{IMPLICIT NONE} statements.
3706 Enable full support of @code{INTEGER(KIND=2)}
3707 (often referred to as @code{INTEGER*8})
3709 @code{libf2c} and @file{f2c.h} so that @code{f2c} users
3710 may make full use of its features via the @code{g77}
3711 version of @file{f2c.h} and the @code{INTEGER(KIND=2)}
3712 support routines in the @code{g77} version of @code{libf2c}.
3715 Improve @code{g77} driver and @code{libf2c} so that @samp{g77 -v}
3716 yields version information on the library.
3719 The @code{SNGL} and @code{FLOAT} intrinsics now are
3720 specific intrinsics, instead of synonyms for the
3721 generic intrinsic @code{REAL}.
3724 New intrinsics have been added.
3725 These are @code{REALPART}, @code{IMAGPART},
3727 @code{LONG}, and @code{SHORT}.
3730 A new group of intrinsics, @samp{gnu}, has been added
3731 to contain the new @code{REALPART}, @code{IMAGPART},
3732 and @code{COMPLEX} intrinsics.
3733 An old group, @samp{dcp}, has been removed.
3740 A temporary kludge option provides bare-bones information on
3741 @code{COMMON} and @code{EQUIVALENCE} members at debug time.
3742 @xref{Code Gen Options,,Options for Code Generation Conventions},
3743 for information on the @samp{-fdebug-kludge} option.
3746 New @samp{-fonetrip} option specifies FORTRAN-66-style
3747 one-trip @code{DO} loops.
3750 New @samp{-fno-silent} option causes names of program units
3751 to be printed as they are compiled, in a fashion similar to
3752 UNIX @code{f77} and @code{f2c}.
3755 New @samp{-fugly-assumed} option specifies that arrays
3756 dimensioned via @samp{DIMENSION X(1)}, for example, are to be
3757 treated as assumed-size.
3760 New @samp{-fno-typeless-boz} option specifies that non-decimal-radix
3761 constants using the prefixed-radix form (such as @samp{Z'1234'})
3762 are to be interpreted as @code{INTEGER(KIND=1)} constants.
3765 New @samp{-ff66} option is a ``shorthand'' option that specifies
3766 behaviors considered appropriate for FORTRAN 66 programs.
3769 New @samp{-ff77} option is a ``shorthand'' option that specifies
3770 behaviors considered appropriate for UNIX @code{f77} programs.
3773 New @samp{-fugly-comma} and @samp{-fugly-logint} options provided
3774 to perform some of what @samp{-fugly} used to do.
3775 @samp{-fugly} and @samp{-fno-ugly} are now ``shorthand'' options,
3776 in that they do nothing more than enable (or disable) other
3777 @samp{-fugly-*} options.
3780 Change code generation for list-directed I/O so it allows
3781 for new versions of @code{libf2c} that might return non-zero
3782 status codes for some operations previously assumed to always
3785 This change not only affects how @code{IOSTAT=} variables
3786 are set by list-directed I/O, it also affects whether
3787 @code{END=} and @code{ERR=} labels are reached by these
3791 Add intrinsic support for new @code{FTELL} and @code{FSEEK}
3792 procedures in @code{libf2c}.
3795 Add options @samp{--help} and @samp{--version} to the
3796 @code{g77} command, to conform to GNU coding guidelines.
3797 Also add printing of @code{g77} version number when
3798 the @samp{--verbose} (@samp{-v}) option is used.
3805 The @code{BYTE} and @code{WORD} statements now are supported,
3806 to a limited extent.
3809 @code{INTEGER*1}, @code{INTEGER*2}, @code{INTEGER*8},
3810 and their @code{LOGICAL}
3811 equivalents, now are supported to a limited extent.
3812 Among the missing elements are complete intrinsic and constant
3816 Support automatic arrays in procedures.
3817 For example, @samp{REAL A(N)}, where @samp{A} is
3818 not a dummy argument, specifies that @samp{A} is
3820 The size of @samp{A} is calculated from the value
3821 of @samp{N} each time the procedure is called,
3822 that amount of space is allocated, and that space
3823 is freed when the procedure returns to its caller.
3826 Add @samp{-fno-zeros} option, enabled by default,
3827 to reduce compile-time CPU and memory usage for
3828 code that provides initial zero values for variables
3832 Introduce three new options that apply to all compilations
3833 by @code{g77}-aware GNU compilers---@samp{-fmove-all-movables},
3834 @samp{-freduce-all-givs}, and @samp{-frerun-loop-opt}---which
3835 can improve the run-time performance of some programs.
3838 Replace much of the existing documentation with a single
3842 New option @samp{-fno-second-underscore}.
3849 The @code{ERF()} and @code{ERFC()} intrinsics now are generic
3850 intrinsics, mapping to @code{ERF}/@code{DERF} and
3851 @code{ERFC}/@code{DERFC}, respectively.
3852 @emph{Note:} Use @samp{INTRINSIC ERF,ERFC} in any code that
3853 might reference these as generic intrinsics, to
3854 improve the likelihood of diagnostics (instead of subtle run-time
3855 bugs) when using compilers that don't support these as intrinsics.
3858 New option @samp{-Wsurprising}.
3861 DO loops with non-@code{INTEGER} variables now diagnosed only when
3862 @samp{-Wsurprising} specified.
3863 Previously, this was diagnosed @emph{unless} @samp{-fpedantic} or
3864 @samp{-fugly} was specified.
3871 @code{libf2c} changed to output a leading zero (0) digit for floating-point
3872 values output via list-directed and formatted output (to bring @code{g77}
3873 more into line with many existing Fortran implementations---the
3874 ANSI FORTRAN 77 standard leaves this choice to the implementation).
3877 @code{libf2c} no longer built with debugging information
3878 intact, making it much smaller.
3881 Automatic installation of the @code{g77} command now works.
3884 Diagnostic messages now more informative, a la @code{gcc},
3885 including messages like @samp{In function `foo':} and @samp{In file
3889 New group of intrinsics called @samp{unix}, including @code{ABORT},
3890 @code{DERF}, @code{DERFC}, @code{ERF}, @code{ERFC}, @code{EXIT},
3891 @code{FLUSH}, @code{GETARG}, @code{GETENV}, @code{SIGNAL}, and
3895 @samp{-funix-intrinsics-@{delete,hide,disable,enable@}}
3899 @samp{-fno-underscoring} option added.
3902 @samp{--driver} option added to the @code{g77} command.
3905 Support for the @code{gcc} options @samp{-fident} and @samp{-fno-ident}
3909 @samp{g77 -v} returns much more version info, making the submission
3910 of better bug reports easily.
3913 Many improvements to the @code{g77} command to better fulfill its role as
3914 a front-end to the @code{gcc} driver.
3915 For example, @code{g77} now
3916 recognizes @samp{--verbose} as a verbose way of specifying @samp{-v}.
3919 Compiling preprocessed (@file{*.F} and @file{*.fpp}) files now
3920 results in better diagnostics and debugging information, as the
3921 source-location info now is passed all the
3922 way through the compilation process instead of being lost.
3926 @chapter The GNU Fortran Language
3928 @cindex standard, ANSI FORTRAN 77
3929 @cindex ANSI FORTRAN 77 standard
3930 @cindex reference works
3931 GNU Fortran supports a variety of extensions to, and dialects
3932 of, the Fortran language.
3933 Its primary base is the ANSI FORTRAN 77 standard, currently available on
3935 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
3936 or as monolithic text at
3937 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
3938 It offers some extensions that are popular among users
3939 of UNIX @code{f77} and @code{f2c} compilers, some that
3940 are popular among users of other compilers (such as Digital
3941 products), some that are popular among users of the
3942 newer Fortran 90 standard, and some that are introduced
3946 (If you need a text on Fortran,
3947 a few freely available electronic references have pointers from
3948 @uref{http://www.fortran.com/fortran/Books/}.)
3950 Part of what defines a particular implementation of a Fortran
3951 system, such as @code{g77}, is the particular characteristics
3952 of how it supports types, constants, and so on.
3953 Much of this is left up to the implementation by the various
3954 Fortran standards and accepted practice in the industry.
3956 The GNU Fortran @emph{language} is described below.
3957 Much of the material is organized along the same lines
3958 as the ANSI FORTRAN 77 standard itself.
3960 @xref{Other Dialects}, for information on features @code{g77} supports
3961 that are not part of the GNU Fortran language.
3963 @emph{Note}: This portion of the documentation definitely needs a lot
3967 Relationship to the ANSI FORTRAN 77 standard:
3968 * Direction of Language Development:: Where GNU Fortran is headed.
3969 * Standard Support:: Degree of support for the standard.
3971 Extensions to the ANSI FORTRAN 77 standard:
3974 * Terms and Concepts::
3975 * Characters Lines Sequence::
3976 * Data Types and Constants::
3978 * Specification Statements::
3979 * Control Statements::
3980 * Functions and Subroutines::
3981 * Scope and Classes of Names::
3984 @node Direction of Language Development
3985 @section Direction of Language Development
3986 @cindex direction of language development
3987 @cindex features, language
3988 @cindex language features
3990 The purpose of the following description of the GNU Fortran
3991 language is to promote wide portability of GNU Fortran programs.
3993 GNU Fortran is an evolving language, due to the
3994 fact that @code{g77} itself is in beta test.
3995 Some current features of the language might later
3996 be redefined as dialects of Fortran supported by @code{g77}
3997 when better ways to express these features are added to @code{g77},
3999 Such features would still be supported by
4000 @code{g77}, but would be available only when
4001 one or more command-line options were used.
4003 The GNU Fortran @emph{language} is distinct from the
4004 GNU Fortran @emph{compilation system} (@code{g77}).
4006 For example, @code{g77} supports various dialects of
4007 Fortran---in a sense, these are languages other than
4008 GNU Fortran---though its primary
4009 purpose is to support the GNU Fortran language, which also is
4010 described in its documentation and by its implementation.
4012 On the other hand, non-GNU compilers might offer
4013 support for the GNU Fortran language, and are encouraged
4016 Currently, the GNU Fortran language is a fairly fuzzy object.
4017 It represents something of a cross between what @code{g77} accepts
4018 when compiling using the prevailing defaults and what this
4019 document describes as being part of the language.
4021 Future versions of @code{g77} are expected to clarify the
4022 definition of the language in the documentation.
4023 Often, this will mean adding new features to the language, in the form
4024 of both new documentation and new support in @code{g77}.
4025 However, it might occasionally mean removing a feature
4026 from the language itself to ``dialect'' status.
4027 In such a case, the documentation would be adjusted
4028 to reflect the change, and @code{g77} itself would likely be changed
4029 to require one or more command-line options to continue supporting
4032 The development of the GNU Fortran language is intended to strike
4037 Serving as a mostly-upwards-compatible language from the
4038 de facto UNIX Fortran dialect as supported by @code{f77}.
4041 Offering new, well-designed language features.
4042 Attributes of such features include
4043 not making existing code any harder to read
4044 (for those who might be unaware that the new
4045 features are not in use) and
4046 not making state-of-the-art
4047 compilers take longer to issue diagnostics,
4051 Supporting existing, well-written code without gratuitously
4052 rejecting non-standard constructs, regardless of the origin
4053 of the code (its dialect).
4056 Offering default behavior and command-line options to reduce
4057 and, where reasonable, eliminate the need for programmers to make
4058 any modifications to code that already works in existing
4059 production environments.
4062 Diagnosing constructs that have different meanings in different
4063 systems, languages, and dialects, while offering clear,
4064 less ambiguous ways to express each of the different meanings
4065 so programmers can change their code appropriately.
4068 One of the biggest practical challenges for the developers of the
4069 GNU Fortran language is meeting the sometimes contradictory demands
4072 For example, a feature might be widely used in one popular environment,
4073 but the exact same code that utilizes that feature might not work
4074 as expected---perhaps it might mean something entirely different---in
4075 another popular environment.
4077 Traditionally, Fortran compilers---even portable ones---have solved this
4078 problem by simply offering the appropriate feature to users of
4079 the respective systems.
4080 This approach treats users of various Fortran systems and dialects
4081 as remote ``islands'', or camps, of programmers, and assume that these
4082 camps rarely come into contact with each other (or,
4083 especially, with each other's code).
4085 Project GNU takes a radically different approach to software and language
4086 design, in that it assumes that users of GNU software do not necessarily
4087 care what kind of underlying system they are using, regardless
4088 of whether they are using software (at the user-interface
4089 level) or writing it (for example, writing Fortran or C code).
4091 As such, GNU users rarely need consider just what kind of underlying
4092 hardware (or, in many cases, operating system) they are using at any
4094 They can use and write software designed for a general-purpose,
4095 widely portable, heterogenous environment---the GNU environment.
4097 In line with this philosophy, GNU Fortran must evolve into a product
4098 that is widely ported and portable not only in the sense that it can
4099 be successfully built, installed, and run by users, but in the larger
4100 sense that its users can use it in the same way, and expect largely the
4101 same behaviors from it, regardless of the kind of system they are using
4102 at any particular time.
4104 This approach constrains the solutions @code{g77} can use to resolve
4105 conflicts between various camps of Fortran users.
4106 If these two camps disagree about what a particular construct should
4107 mean, @code{g77} cannot simply be changed to treat that particular construct as
4108 having one meaning without comment (such as a warning), lest the users
4109 expecting it to have the other meaning are unpleasantly surprised that
4110 their code misbehaves when executed.
4112 The use of the ASCII backslash character in character constants is
4113 an excellent (and still somewhat unresolved) example of this kind of
4115 @xref{Backslash in Constants}.
4116 Other examples are likely to arise in the future, as @code{g77} developers
4117 strive to improve its ability to accept an ever-wider variety of existing
4118 Fortran code without requiring significant modifications to said code.
4120 Development of GNU Fortran is further constrained by the desire
4121 to avoid requiring programmers to change their code.
4122 This is important because it allows programmers, administrators,
4123 and others to more faithfully evaluate and validate @code{g77}
4124 (as an overall product and as new versions are distributed)
4125 without having to support multiple versions of their programs
4126 so that they continue to work the same way on their existing
4127 systems (non-GNU perhaps, but possibly also earlier versions
4130 @node Standard Support
4131 @section ANSI FORTRAN 77 Standard Support
4132 @cindex ANSI FORTRAN 77 support
4133 @cindex standard support
4134 @cindex support for ANSI FORTRAN 77
4135 @cindex compatibility, FORTRAN 77
4136 @cindex FORTRAN 77 compatibility
4138 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
4139 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
4140 support are those that are probably rarely used in actual code,
4141 some of which are explicitly disallowed by the Fortran 90 standard.
4144 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
4145 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
4146 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
4147 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
4150 @node No Passing External Assumed-length
4151 @subsection No Passing External Assumed-length
4153 @code{g77} disallows passing of an external procedure
4154 as an actual argument if the procedure's
4155 type is declared @code{CHARACTER*(*)}. For example:
4165 It isn't clear whether the standard considers this conforming.
4167 @node No Passing Dummy Assumed-length
4168 @subsection No Passing Dummy Assumed-length
4170 @code{g77} disallows passing of a dummy procedure
4171 as an actual argument if the procedure's
4172 type is declared @code{CHARACTER*(*)}.
4175 SUBROUTINE BAR(CFUNC)
4183 It isn't clear whether the standard considers this conforming.
4185 @node No Pathological Implied-DO
4186 @subsection No Pathological Implied-DO
4188 The @code{DO} variable for an implied-@code{DO} construct in a
4189 @code{DATA} statement may not be used as the @code{DO} variable
4190 for an outer implied-@code{DO} construct. For example, this
4191 fragment is disallowed by @code{g77}:
4194 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
4198 This also is disallowed by Fortran 90, as it offers no additional
4199 capabilities and would have a variety of possible meanings.
4201 Note that it is @emph{very} unlikely that any production Fortran code
4202 tries to use this unsupported construct.
4204 @node No Useless Implied-DO
4205 @subsection No Useless Implied-DO
4207 An array element initializer in an implied-@code{DO} construct in a
4208 @code{DATA} statement must contain at least one reference to the @code{DO}
4209 variables of each outer implied-@code{DO} construct. For example,
4210 this fragment is disallowed by @code{g77}:
4213 DATA (A, I= 1, 1) /1./
4217 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
4218 requirements offer no additional capabilities.
4219 However, @code{g77} doesn't necessarily diagnose all cases
4220 where this requirement is not met.
4222 Note that it is @emph{very} unlikely that any production Fortran code
4223 tries to use this unsupported construct.
4226 @section Conformance
4228 (The following information augments or overrides the information in
4229 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4231 Chapter 1 of that document otherwise serves as the basis
4232 for the relevant aspects of GNU Fortran.)
4234 The definition of the GNU Fortran language is akin to that of
4235 the ANSI FORTRAN 77 language in that it does not generally require
4236 conforming implementations to diagnose cases where programs do
4237 not conform to the language.
4239 However, @code{g77} as a compiler is being developed in a way that
4240 is intended to enable it to diagnose such cases in an easy-to-understand
4243 A program that conforms to the GNU Fortran language should, when
4244 compiled, linked, and executed using a properly installed @code{g77}
4245 system, perform as described by the GNU Fortran language definition.
4246 Reasons for different behavior include, among others:
4250 Use of resources (memory---heap, stack, and so on; disk space; CPU
4251 time; etc.) exceeds those of the system.
4254 Range and/or precision of calculations required by the program
4255 exceeds that of the system.
4258 Excessive reliance on behaviors that are system-dependent
4259 (non-portable Fortran code).
4262 Bugs in the program.
4271 Despite these ``loopholes'', the availability of a clear specification
4272 of the language of programs submitted to @code{g77}, as this document
4273 is intended to provide, is considered an important aspect of providing
4274 a robust, clean, predictable Fortran implementation.
4276 The definition of the GNU Fortran language, while having no special
4277 legal status, can therefore be viewed as a sort of contract, or agreement.
4278 This agreement says, in essence, ``if you write a program in this language,
4279 and run it in an environment (such as a @code{g77} system) that supports
4280 this language, the program should behave in a largely predictable way''.
4283 @section Notation Used in This Chapter
4285 (The following information augments or overrides the information in
4286 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4288 Chapter 1 of that document otherwise serves as the basis
4289 for the relevant aspects of GNU Fortran.)
4291 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
4292 and ``must not'' and ``may not'' denote prohibition.
4293 Terms such as ``might'', ``should'', and ``can'' generally add little or
4294 nothing in the way of weight to the GNU Fortran language itself,
4295 but are used to explain or illustrate the language.
4300 ``The @code{FROBNITZ} statement must precede all executable
4301 statements in a program unit, and may not specify any dummy
4302 arguments. It may specify local or common variables and arrays.
4303 Its use should be limited to portions of the program designed to
4304 be non-portable and system-specific, because it might cause the
4305 containing program unit to behave quite differently on different
4309 Insofar as the GNU Fortran language is specified,
4310 the requirements and permissions denoted by the above sample statement
4311 are limited to the placement of the statement and the kinds of
4312 things it may specify.
4313 The rest of the statement---the content regarding non-portable portions
4314 of the program and the differing behavior of program units containing
4315 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
4317 That content offers advice and warnings about the @code{FROBNITZ}
4320 @emph{Remember:} The GNU Fortran language definition specifies
4321 both what constitutes a valid GNU Fortran program and how,
4322 given such a program, a valid GNU Fortran implementation is
4323 to interpret that program.
4325 It is @emph{not} incumbent upon a valid GNU Fortran implementation
4326 to behave in any particular way, any consistent way, or any
4327 predictable way when it is asked to interpret input that is
4328 @emph{not} a valid GNU Fortran program.
4330 Such input is said to have @dfn{undefined} behavior when
4331 interpreted by a valid GNU Fortran implementation, though
4332 an implementation may choose to specify behaviors for some
4333 cases of inputs that are not valid GNU Fortran programs.
4335 Other notation used herein is that of the GNU texinfo format,
4336 which is used to generate printed hardcopy, on-line hypertext
4337 (Info), and on-line HTML versions, all from a single source
4339 This notation is used as follows:
4343 Keywords defined by the GNU Fortran language are shown
4344 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
4347 Note that, in practice, many Fortran programs are written
4348 in lowercase---uppercase is used in this manual as a
4349 means to readily distinguish keywords and sample Fortran-related
4350 text from the prose in this document.
4353 Portions of actual sample program, input, or output text
4354 look like this: @samp{Actual program text}.
4356 Generally, uppercase is used for all Fortran-specific and
4357 Fortran-related text, though this does not always include
4358 literal text within Fortran code.
4360 For example: @samp{PRINT *, 'My name is Bob'}.
4363 A metasyntactic variable---that is, a name used in this document
4364 to serve as a placeholder for whatever text is used by the
4365 user or programmer--appears as shown in the following example:
4367 ``The @code{INTEGER @var{ivar}} statement specifies that
4368 @var{ivar} is a variable or array of type @code{INTEGER}.''
4370 In the above example, any valid text may be substituted for
4371 the metasyntactic variable @var{ivar} to make the statement
4372 apply to a specific instance, as long as the same text is
4373 substituted for @emph{both} occurrences of @var{ivar}.
4376 Ellipses (``@dots{}'') are used to indicate further text that
4377 is either unimportant or expanded upon further, elsewhere.
4380 Names of data types are in the style of Fortran 90, in most
4383 @xref{Kind Notation}, for information on the relationship
4384 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
4385 and the more traditional, less portably concise nomenclature
4386 (such as @code{INTEGER*4}).
4389 @node Terms and Concepts
4390 @section Fortran Terms and Concepts
4392 (The following information augments or overrides the information in
4393 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4395 Chapter 2 of that document otherwise serves as the basis
4396 for the relevant aspects of GNU Fortran.)
4400 * Statements Comments Lines::
4401 * Scope of Names and Labels::
4404 @node Syntactic Items
4405 @subsection Syntactic Items
4407 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
4409 In GNU Fortran, a symbolic name is at least one character long,
4410 and has no arbitrary upper limit on length.
4411 However, names of entities requiring external linkage (such as
4412 external functions, external subroutines, and @code{COMMON} areas)
4413 might be restricted to some arbitrary length by the system.
4414 Such a restriction is no more constrained than that of one
4415 through six characters.
4417 Underscores (@samp{_}) are accepted in symbol names after the first
4418 character (which must be a letter).
4420 @node Statements Comments Lines
4421 @subsection Statements, Comments, and Lines
4423 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
4425 @cindex comments, trailing
4426 @cindex trailing comments
4427 Use of an exclamation point (@samp{!}) to begin a
4428 trailing comment (a comment that extends to the end of the same
4429 source line) is permitted under the following conditions:
4433 The exclamation point does not appear in column 6.
4434 Otherwise, it is treated as an indicator of a continuation
4438 The exclamation point appears outside a character or hollerith
4440 Otherwise, the exclamation point is considered part of the
4444 The exclamation point appears to the left of any other possible
4446 That is, a trailing comment may contain exclamation points
4447 in their commentary text.
4451 @cindex statements, separated by semicolon
4452 Use of a semicolon (@samp{;}) as a statement separator
4453 is permitted under the following conditions:
4457 The semicolon appears outside a character or hollerith
4459 Otherwise, the semicolon is considered part of the
4463 The semicolon appears to the left of a trailing comment.
4464 Otherwise, the semicolon is considered part of that
4468 Neither a logical @code{IF} statement nor a non-construct
4469 @code{WHERE} statement (a Fortran 90 feature) may be
4470 followed (in the same, possibly continued, line) by
4471 a semicolon used as a statement separator.
4473 This restriction avoids the confusion
4474 that can result when reading a line such as:
4477 IF (VALIDP) CALL FOO; CALL BAR
4481 Some readers might think the @samp{CALL BAR} is executed
4482 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4483 assume its execution is unconditional.
4485 (At present, @code{g77} does not diagnose code that
4486 violates this restriction.)
4489 @node Scope of Names and Labels
4490 @subsection Scope of Symbolic Names and Statement Labels
4493 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4495 Included in the list of entities that have a scope of a
4496 program unit are construct names (a Fortran 90 feature).
4497 @xref{Construct Names}, for more information.
4499 @node Characters Lines Sequence
4500 @section Characters, Lines, and Execution Sequence
4502 (The following information augments or overrides the information in
4503 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4505 Chapter 3 of that document otherwise serves as the basis
4506 for the relevant aspects of GNU Fortran.)
4511 * Continuation Line::
4513 * Statement Labels::
4519 @subsection GNU Fortran Character Set
4522 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4524 Letters include uppercase letters (the twenty-six characters
4525 of the English alphabet) and lowercase letters (their lowercase
4527 Generally, lowercase letters may be used in place of uppercase
4528 letters, though in character and hollerith constants, they
4531 Special characters include:
4535 Semicolon (@samp{;})
4538 Exclamation point (@samp{!})
4541 Double quote (@samp{"})
4544 Backslash (@samp{\})
4547 Question mark (@samp{?})
4550 Hash mark (@samp{#})
4553 Ampersand (@samp{&})
4556 Percent sign (@samp{%})
4559 Underscore (@samp{_})
4562 Open angle (@samp{<})
4565 Close angle (@samp{>})
4568 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4569 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4570 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4574 @cindex blanks (spaces)
4575 Note that this document refers to @key{SPC} as @dfn{space},
4576 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4581 @cindex source file format
4583 @cindex files, source
4585 @cindex code, source
4589 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4591 The way a Fortran compiler views source files depends entirely on the
4592 implementation choices made for the compiler, since those choices
4593 are explicitly left to the implementation by the published Fortran
4596 The GNU Fortran language mandates a view applicable to UNIX-like
4597 text files---files that are made up of an arbitrary number of lines,
4598 each with an arbitrary number of characters (sometimes called stream-based
4601 This view does not apply to types of files that are specified as
4602 having a particular number of characters on every single line (sometimes
4603 referred to as record-based files).
4605 Because a ``line in a program unit is a sequence of 72 characters'',
4606 to quote X3.9-1978, the GNU Fortran language specifies that a
4607 stream-based text file is translated to GNU Fortran lines as follows:
4611 A newline in the file is the character that represents the end of
4612 a line of text to the underlying system.
4613 For example, on ASCII-based systems, a newline is the @key{NL}
4614 character, which has ASCII value 12 (decimal).
4617 Each newline in the file serves to end the line of text that precedes
4618 it (and that does not contain a newline).
4621 The end-of-file marker (@code{EOF}) also serves to end the line
4622 of text that precedes it (and that does not contain a newline).
4625 @cindex blanks (spaces)
4626 Any line of text that is shorter than 72 characters is padded to that length
4627 with spaces (called ``blanks'' in the standard).
4630 Any line of text that is longer than 72 characters is truncated to that
4631 length, but the truncated remainder must consist entirely of spaces.
4634 Characters other than newline and the GNU Fortran character set
4638 For the purposes of the remainder of this description of the GNU
4639 Fortran language, the translation described above has already
4640 taken place, unless otherwise specified.
4642 The result of the above translation is that the source file appears,
4643 in terms of the remainder of this description of the GNU Fortran language,
4644 as if it had an arbitrary
4645 number of 72-character lines, each character being among the GNU Fortran
4648 For example, if the source file itself has two newlines in a row,
4649 the second newline becomes, after the above translation, a single
4650 line containing 72 spaces.
4652 @node Continuation Line
4653 @subsection Continuation Line
4654 @cindex continuation lines, number of
4655 @cindex lines, continuation
4656 @cindex number of continuation lines
4657 @cindex limits on continuation lines
4659 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4661 A continuation line is any line that both
4665 Contains a continuation character, and
4668 Contains only spaces in columns 1 through 5
4671 A continuation character is any character of the GNU Fortran character set
4672 other than space (@key{SPC}) or zero (@samp{0})
4673 in column 6, or a digit (@samp{0} through @samp{9}) in column
4674 7 through 72 of a line that has only spaces to the left of that
4677 The continuation character is ignored as far as the content of
4678 the statement is concerned.
4680 The GNU Fortran language places no limit on the number of
4681 continuation lines in a statement.
4682 In practice, the limit depends on a variety of factors, such as
4683 available memory, statement content, and so on, but no
4684 GNU Fortran system may impose an arbitrary limit.
4687 @subsection Statements
4689 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4691 Statements may be written using an arbitrary number of continuation
4694 Statements may be separated using the semicolon (@samp{;}), except
4695 that the logical @code{IF} and non-construct @code{WHERE} statements
4696 may not be separated from subsequent statements using only a semicolon
4697 as statement separator.
4699 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4700 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4702 These alternatives may be written as normal statements---they are not
4703 subject to the restrictions of the @code{END} statement.
4705 However, no statement other than @code{END} may have an initial line
4706 that appears to be an @code{END} statement---even @code{END PROGRAM},
4707 for example, must not be written as:
4714 @node Statement Labels
4715 @subsection Statement Labels
4717 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4719 A statement separated from its predecessor via a semicolon may be
4724 The semicolon is followed by the label for the statement,
4725 which in turn follows the label.
4728 The label must be no more than five digits in length.
4731 The first digit of the label for the statement is not
4732 the first non-space character on a line.
4733 Otherwise, that character is treated as a continuation
4737 A statement may have only one label defined for it.
4740 @subsection Order of Statements and Lines
4742 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4744 Generally, @code{DATA} statements may precede executable statements.
4745 However, specification statements pertaining to any entities
4746 initialized by a @code{DATA} statement must precede that @code{DATA}
4749 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4750 @samp{INTEGER J} is permitted.
4752 The last line of a program unit may be an @code{END} statement,
4757 An @code{END PROGRAM} statement, if the program unit is a main program.
4760 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4763 An @code{END FUNCTION} statement, if the program unit is a function.
4766 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4770 @subsection Including Source Text
4773 Additional source text may be included in the processing of
4774 the source file via the @code{INCLUDE} directive:
4777 INCLUDE @var{filename}
4781 The source text to be included is identified by @var{filename},
4782 which is a literal GNU Fortran character constant.
4783 The meaning and interpretation of @var{filename} depends on the
4784 implementation, but typically is a filename.
4786 (@code{g77} treats it as a filename that it searches for
4787 in the current directory and/or directories specified
4788 via the @samp{-I} command-line option.)
4790 The effect of the @code{INCLUDE} directive is as if the
4791 included text directly replaced the directive in the source
4792 file prior to interpretation of the program.
4793 Included text may itself use @code{INCLUDE}.
4794 The depth of nested @code{INCLUDE} references depends on
4795 the implementation, but typically is a positive integer.
4797 This virtual replacement treats the statements and @code{INCLUDE}
4798 directives in the included text as syntactically distinct from
4799 those in the including text.
4801 Therefore, the first non-comment line of the included text
4802 must not be a continuation line.
4803 The included text must therefore have, after the non-comment
4804 lines, either an initial line (statement), an @code{INCLUDE}
4805 directive, or nothing (the end of the included text).
4807 Similarly, the including text may end the @code{INCLUDE}
4808 directive with a semicolon or the end of the line, but it
4809 cannot follow an @code{INCLUDE} directive at the end of its
4810 line with a continuation line.
4811 Thus, the last statement in an included text may not be
4814 Any statements between two @code{INCLUDE} directives on the
4815 same line are treated as if they appeared in between the
4816 respective included texts.
4820 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4824 If the text included by @samp{INCLUDE 'A'} constitutes
4825 a @samp{PRINT *, 'A'} statement and the text included by
4826 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4827 then the output of the above sample program would be
4836 (with suitable allowances for how an implementation defines
4837 its handling of output).
4839 Included text must not include itself directly or indirectly,
4840 regardless of whether the @var{filename} used to reference
4841 the text is the same.
4843 Note that @code{INCLUDE} is @emph{not} a statement.
4844 As such, it is neither a non-executable or executable
4846 However, if the text it includes constitutes one or more
4847 executable statements, then the placement of @code{INCLUDE}
4848 is subject to effectively the same restrictions as those
4849 on executable statements.
4851 An @code{INCLUDE} directive may be continued across multiple
4852 lines as if it were a statement.
4853 This permits long names to be used for @var{filename}.
4855 @node Data Types and Constants
4856 @section Data Types and Constants
4858 (The following information augments or overrides the information in
4859 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4861 Chapter 4 of that document otherwise serves as the basis
4862 for the relevant aspects of GNU Fortran.)
4864 To more concisely express the appropriate types for
4865 entities, this document uses the more concise
4866 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
4867 instead of the more traditional, but less portably concise,
4868 byte-size-based nomenclature such as @code{INTEGER*4},
4869 wherever reasonable.
4871 When referring to generic types---in contexts where the
4872 specific precision and range of a type are not important---this
4873 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
4874 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
4876 In some cases, the context requires specification of a
4878 This document uses the @samp{KIND=} notation to accomplish
4879 this throughout, sometimes supplying the more traditional
4880 notation for clarification, though the traditional notation
4881 might not work the same way on all GNU Fortran implementations.
4883 Use of @samp{KIND=} makes this document more concise because
4884 @code{g77} is able to define values for @samp{KIND=} that
4885 have the same meanings on all systems, due to the way the
4886 Fortran 90 standard specifies these values are to be used.
4888 (In particular, that standard permits an implementation to
4889 arbitrarily assign nonnegative values.
4890 There are four distinct sets of assignments: one to the @code{CHARACTER}
4891 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
4892 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
4893 Implementations are free to assign these values in any order,
4894 leave gaps in the ordering of assignments, and assign more than
4895 one value to a representation.)
4897 This makes @samp{KIND=} values superior to the values used
4898 in non-standard statements such as @samp{INTEGER*4}, because
4899 the meanings of the values in those statements vary from machine
4900 to machine, compiler to compiler, even operating system to
4903 However, use of @samp{KIND=} is @emph{not} generally recommended
4904 when writing portable code (unless, for example, the code is
4905 going to be compiled only via @code{g77}, which is a widely
4907 GNU Fortran does not yet have adequate language constructs to
4908 permit use of @samp{KIND=} in a fashion that would make the
4909 code portable to Fortran 90 implementations; and, this construct
4910 is known to @emph{not} be accepted by many popular FORTRAN 77
4911 implementations, so it cannot be used in code that is to be ported
4914 The distinction here is that this document is able to use
4915 specific values for @samp{KIND=} to concisely document the
4916 types of various operations and operands.
4918 A Fortran program should use the FORTRAN 77 designations for the
4919 appropriate GNU Fortran types---such as @code{INTEGER} for
4920 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
4921 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
4922 where no such designations exist, make use of appropriate
4923 techniques (preprocessor macros, parameters, and so on)
4924 to specify the types in a fashion that may be easily adjusted
4925 to suit each particular implementation to which the program
4927 (These types generally won't need to be adjusted for ports of
4930 Further details regarding GNU Fortran data types and constants
4941 @subsection Data Types
4943 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
4945 GNU Fortran supports these types:
4949 Integer (generic type @code{INTEGER})
4952 Real (generic type @code{REAL})
4958 Complex (generic type @code{COMPLEX})
4961 Logical (generic type @code{LOGICAL})
4964 Character (generic type @code{CHARACTER})
4970 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
4972 The generic types shown above are referred to in this document
4973 using only their generic type names.
4974 Such references usually indicate that any specific type (kind)
4975 of that generic type is valid.
4977 For example, a context described in this document as accepting
4978 the @code{COMPLEX} type also is likely to accept the
4979 @code{DOUBLE COMPLEX} type.
4981 The GNU Fortran language supports three ways to specify
4982 a specific kind of a generic type.
4985 * Double Notation:: As in @code{DOUBLE COMPLEX}.
4986 * Star Notation:: As in @code{INTEGER*4}.
4987 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
4990 @node Double Notation
4991 @subsubsection Double Notation
4993 The GNU Fortran language supports two uses of the keyword
4994 @code{DOUBLE} to specify a specific kind of type:
4998 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
5001 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
5004 Use one of the above forms where a type name is valid.
5006 While use of this notation is popular, it doesn't scale
5007 well in a language or dialect rich in intrinsic types,
5008 as is the case for the GNU Fortran language (especially
5009 planned future versions of it).
5011 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
5012 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
5013 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
5014 often are substituted for these, respectively, even though they
5015 do not always have the same meanings on all systems.
5016 (And, the fact that @samp{DOUBLE REAL} does not exist as such
5017 is an inconsistency.)
5019 Therefore, this document uses ``double notation'' only on occasion
5020 for the benefit of those readers who are accustomed to it.
5023 @subsubsection Star Notation
5024 @cindex *@var{n} notation
5026 The following notation specifies the storage size for a type:
5029 @var{generic-type}*@var{n}
5033 @var{generic-type} must be a generic type---one of
5034 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
5035 or @code{CHARACTER}.
5036 @var{n} must be one or more digits comprising a decimal
5037 integer number greater than zero.
5039 Use the above form where a type name is valid.
5041 The @samp{*@var{n}} notation specifies that the amount of storage
5042 occupied by variables and array elements of that type is @var{n}
5043 times the storage occupied by a @code{CHARACTER*1} variable.
5045 This notation might indicate a different degree of precision and/or
5046 range for such variables and array elements, and the functions that
5047 return values of types using this notation.
5048 It does not limit the precision or range of values of that type
5049 in any particular way---use explicit code to do that.
5051 Further, the GNU Fortran language requires no particular values
5052 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
5054 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
5055 on all systems, for example,
5056 but not all implementations are required to do so, and @code{g77}
5057 is known to not support @code{REAL*1} on most (or all) systems.
5059 As a result, except for @var{generic-type} of @code{CHARACTER},
5060 uses of this notation should be limited to isolated
5061 portions of a program that are intended to handle system-specific
5062 tasks and are expected to be non-portable.
5064 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
5065 only @code{CHARACTER}, where it signifies not only the amount
5066 of storage occupied, but the number of characters in entities
5068 However, almost all Fortran compilers have supported this
5069 notation for generic types, though with a variety of meanings
5072 Specifications of types using the @samp{*@var{n}} notation
5073 always are interpreted as specifications of the appropriate
5074 types described in this document using the @samp{KIND=@var{n}}
5075 notation, described below.
5077 While use of this notation is popular, it doesn't serve well
5078 in the context of a widely portable dialect of Fortran, such as
5079 the GNU Fortran language.
5081 For example, even on one particular machine, two or more popular
5082 Fortran compilers might well disagree on the size of a type
5083 declared @code{INTEGER*2} or @code{REAL*16}.
5085 is known to be disagreement over such things among Fortran
5086 compilers on @emph{different} systems.
5088 Further, this notation offers no elegant way to specify sizes
5089 that are not even multiples of the ``byte size'' typically
5090 designated by @code{INTEGER*1}.
5091 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
5092 certainly be possible, but would perhaps be stretching the original
5093 intent of this notation beyond the breaking point in terms
5094 of widespread readability of documentation and code making use
5097 Therefore, this document uses ``star notation'' only on occasion
5098 for the benefit of those readers who are accustomed to it.
5101 @subsubsection Kind Notation
5102 @cindex KIND= notation
5104 The following notation specifies the kind-type selector of a type:
5107 @var{generic-type}(KIND=@var{n})
5111 Use the above form where a type name is valid.
5113 @var{generic-type} must be a generic type---one of
5114 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
5115 or @code{CHARACTER}.
5116 @var{n} must be an integer initialization expression that
5117 is a positive, nonzero value.
5119 Programmers are discouraged from writing these values directly
5121 Future versions of the GNU Fortran language will offer
5122 facilities that will make the writing of code portable
5123 to @code{g77} @emph{and} Fortran 90 implementations simpler.
5125 However, writing code that ports to existing FORTRAN 77
5126 implementations depends on avoiding the @samp{KIND=} construct.
5128 The @samp{KIND=} construct is thus useful in the context
5129 of GNU Fortran for two reasons:
5133 It provides a means to specify a type in a fashion that
5134 is portable across all GNU Fortran implementations (though
5135 not other FORTRAN 77 and Fortran 90 implementations).
5138 It provides a sort of Rosetta stone for this document to use
5139 to concisely describe the types of various operations and
5143 The values of @var{n} in the GNU Fortran language are
5144 assigned using a scheme that:
5148 Attempts to maximize the ability of readers
5149 of this document to quickly familiarize themselves
5150 with assignments for popular types
5153 Provides a unique value for each specific desired
5157 Provides a means to automatically assign new values so
5158 they have a ``natural'' relationship to existing values,
5159 if appropriate, or, if no such relationship exists, will
5160 not interfere with future values assigned on the basis
5161 of such relationships
5164 Avoids using values that are similar to values used
5165 in the existing, popular @samp{*@var{n}} notation,
5166 to prevent readers from expecting that these implied
5167 correspondences work on all GNU Fortran implementations
5170 The assignment system accomplishes this by assigning
5171 to each ``fundamental meaning'' of a specific type a
5172 unique prime number.
5173 Combinations of fundamental meanings---for example, a type
5174 that is two times the size of some other type---are assigned
5175 values of @var{n} that are the products of the values for
5176 those fundamental meanings.
5178 A prime value of @var{n} is never given more than one fundamental
5179 meaning, to avoid situations where some code or system
5180 cannot reasonably provide those meanings in the form of a
5183 The values of @var{n} assigned so far are:
5187 This value is reserved for future use.
5189 The planned future use is for this value to designate,
5190 explicitly, context-sensitive kind-type selection.
5191 For example, the expression @samp{1D0 * 0.1_0} would
5192 be equivalent to @samp{1D0 * 0.1D0}.
5195 This corresponds to the default types for
5196 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
5197 and @code{CHARACTER}, as appropriate.
5199 These are the ``default'' types described in the Fortran 90 standard,
5200 though that standard does not assign any particular @samp{KIND=}
5201 value to these types.
5203 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
5204 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
5207 This corresponds to types that occupy twice as much
5208 storage as the default types.
5209 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
5210 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
5212 These are the ``double precision'' types described in the Fortran 90
5214 though that standard does not assign any particular @samp{KIND=}
5215 value to these types.
5217 @var{n} of 4 thus corresponds to types that occupy four times
5218 as much storage as the default types, @var{n} of 8 to types that
5219 occupy eight times as much storage, and so on.
5221 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
5222 are not necessarily supported by every GNU Fortran implementation.
5225 This corresponds to types that occupy as much
5226 storage as the default @code{CHARACTER} type,
5227 which is the same effective type as @code{CHARACTER(KIND=1)}
5228 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
5230 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
5232 @var{n} of 6 thus corresponds to types that occupy twice as
5233 much storage as the @var{n}=3 types, @var{n} of 12 to types
5234 that occupy four times as much storage, and so on.
5236 These are not necessarily supported by every GNU Fortran
5240 This corresponds to types that occupy half the
5241 storage as the default (@var{n}=1) types.
5243 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
5245 @var{n} of 25 thus corresponds to types that occupy one-quarter
5246 as much storage as the default types.
5248 These are not necessarily supported by every GNU Fortran
5253 This is valid only as @code{INTEGER(KIND=7)} and
5254 denotes the @code{INTEGER} type that has the smallest
5255 storage size that holds a pointer on the system.
5257 A pointer representable by this type is capable of uniquely
5258 addressing a @code{CHARACTER*1} variable, array, array element,
5261 (Typically this is equivalent to @code{INTEGER*4} or,
5262 on 64-bit systems, @code{INTEGER*8}.
5263 In a compatible C implementation, it typically would
5264 be the same size and semantics of the C type @code{void *}.)
5267 Note that these are @emph{proposed} correspondences and might change
5268 in future versions of @code{g77}---avoid writing code depending
5269 on them while @code{g77}, and therefore the GNU Fortran language
5270 it defines, is in beta testing.
5272 Values not specified in the above list are reserved to
5273 future versions of the GNU Fortran language.
5275 Implementation-dependent meanings will be assigned new,
5276 unique prime numbers so as to not interfere with other
5277 implementation-dependent meanings, and offer the possibility
5278 of increasing the portability of code depending on such
5279 types by offering support for them in other GNU Fortran
5282 Other meanings that might be given unique values are:
5286 Types that make use of only half their storage size for
5287 representing precision and range.
5289 For example, some compilers offer options that cause
5290 @code{INTEGER} types to occupy the amount of storage
5291 that would be needed for @code{INTEGER(KIND=2)} types, but the
5292 range remains that of @code{INTEGER(KIND=1)}.
5295 The IEEE single floating-point type.
5298 Types with a specific bit pattern (endianness), such as the
5299 little-endian form of @code{INTEGER(KIND=1)}.
5300 These could permit, conceptually, use of portable code and
5301 implementations on data files written by existing systems.
5304 Future @emph{prime} numbers should be given meanings in as incremental
5305 a fashion as possible, to allow for flexibility and
5306 expressiveness in combining types.
5308 For example, instead of defining a prime number for little-endian
5309 IEEE doubles, one prime number might be assigned the meaning
5310 ``little-endian'', another the meaning ``IEEE double'', and the
5311 value of @var{n} for a little-endian IEEE double would thus
5312 naturally be the product of those two respective assigned values.
5313 (It could even be reasonable to have IEEE values result from the
5314 products of prime values denoting exponent and fraction sizes
5315 and meanings, hidden bit usage, availability and representations
5316 of special values such as subnormals, infinities, and Not-A-Numbers
5319 This assignment mechanism, while not inherently required for
5320 future versions of the GNU Fortran language, is worth using
5321 because it could ease management of the ``space'' of supported
5322 types much easier in the long run.
5324 The above approach suggests a mechanism for specifying inheritance
5325 of intrinsic (built-in) types for an entire, widely portable
5327 It is certainly reasonable that, unlike programmers of other languages
5328 offering inheritance mechanisms that employ verbose names for classes
5329 and subclasses, along with graphical browsers to elucidate the
5330 relationships, Fortran programmers would employ
5331 a mechanism that works by multiplying prime numbers together
5332 and finding the prime factors of such products.
5334 Most of the advantages for the above scheme have been explained
5336 One disadvantage is that it could lead to the defining,
5337 by the GNU Fortran language, of some fairly large prime numbers.
5338 This could lead to the GNU Fortran language being declared
5339 ``munitions'' by the United States Department of Defense.
5342 @subsection Constants
5344 @cindex types, constants
5346 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
5348 A @dfn{typeless constant} has one of the following forms:
5351 '@var{binary-digits}'B
5352 '@var{octal-digits}'O
5353 '@var{hexadecimal-digits}'Z
5354 '@var{hexadecimal-digits}'X
5358 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5359 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5360 and @samp{0123456789ABCDEFabcdef}, respectively.
5361 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5364 Typeless constants have values that depend on the context in which
5367 All other constants, called @dfn{typed constants}, are interpreted---converted
5368 to internal form---according to their inherent type.
5369 Thus, context is @emph{never} a determining factor for the type, and hence
5370 the interpretation, of a typed constant.
5371 (All constants in the ANSI FORTRAN 77 language are typed constants.)
5373 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
5374 Fortran (called default INTEGER in Fortran 90),
5375 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
5376 additional precision specified is lost, and even when used in a
5377 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
5378 and @samp{1D0} is always type @code{REAL(KIND=2)}.
5381 @subsection Integer Type
5383 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
5385 An integer constant also may have one of the following forms:
5388 B'@var{binary-digits}'
5389 O'@var{octal-digits}'
5390 Z'@var{hexadecimal-digits}'
5391 X'@var{hexadecimal-digits}'
5395 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5396 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5397 and @samp{0123456789ABCDEFabcdef}, respectively.
5398 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5401 @node Character Type
5402 @subsection Character Type
5404 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
5406 A character constant may be delimited by a pair of double quotes
5407 (@samp{"}) instead of apostrophes.
5408 In this case, an apostrophe within the constant represents
5409 a single apostrophe, while a double quote is represented in
5410 the source text of the constant by two consecutive double
5411 quotes with no intervening spaces.
5413 @cindex zero-length CHARACTER
5414 @cindex null CHARACTER strings
5415 @cindex empty CHARACTER strings
5416 @cindex strings, empty
5417 @cindex CHARACTER, null
5418 A character constant may be empty (have a length of zero).
5420 A character constant may include a substring specification,
5421 The value of such a constant is the value of the substring---for
5422 example, the value of @samp{'hello'(3:5)} is the same
5423 as the value of @samp{'llo'}.
5426 @section Expressions
5428 (The following information augments or overrides the information in
5429 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5431 Chapter 6 of that document otherwise serves as the basis
5432 for the relevant aspects of GNU Fortran.)
5439 @subsection The @code{%LOC()} Construct
5440 @cindex %LOC() construct
5446 The @code{%LOC()} construct is an expression
5447 that yields the value of the location of its argument,
5448 @var{arg}, in memory.
5449 The size of the type of the expression depends on the system---typically,
5450 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5451 though it is actually type @code{INTEGER(KIND=7)}.
5453 The argument to @code{%LOC()} must be suitable as the
5454 left-hand side of an assignment statement.
5455 That is, it may not be a general expression involving
5456 operators such as addition, subtraction, and so on,
5457 nor may it be a constant.
5459 Use of @code{%LOC()} is recommended only for code that
5460 is accessing facilities outside of GNU Fortran, such as
5461 operating system or windowing facilities.
5462 It is best to constrain such uses to isolated portions of
5463 a program---portions that deal specifically and exclusively
5464 with low-level, system-dependent facilities.
5465 Such portions might well provide a portable interface for
5466 use by the program as a whole, but are themselves not
5467 portable, and should be thoroughly tested each time they
5468 are rebuilt using a new compiler or version of a compiler.
5470 Do not depend on @code{%LOC()} returning a pointer that
5471 can be safely used to @emph{define} (change) the argument.
5472 While this might work in some circumstances, it is hard
5473 to predict whether it will continue to work when a program
5474 (that works using this unsafe behavior)
5475 is recompiled using different command-line options or
5476 a different version of @code{g77}.
5478 Generally, @code{%LOC()} is safe when used as an argument
5479 to a procedure that makes use of the value of the corresponding
5480 dummy argument only during its activation, and only when
5481 such use is restricted to referencing (reading) the value
5482 of the argument to @code{%LOC()}.
5484 @emph{Implementation Note:} Currently, @code{g77} passes
5485 arguments (those not passed using a construct such as @code{%VAL()})
5486 by reference or descriptor, depending on the type of
5487 the actual argument.
5488 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5489 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5490 in fact might compile to identical code.
5492 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5493 ``pass, by value, the address of @samp{I} in memory''.
5494 While @samp{CALL FOO(I)} might use that same approach in a
5495 particular version of @code{g77}, another version or compiler
5496 might choose a different implementation, such as copy-in/copy-out,
5497 to effect the desired behavior---and which will therefore not
5498 necessarily compile to the same code as would
5499 @samp{CALL FOO(%VAL(%LOC(I)))}
5500 using the same version or compiler.
5502 @xref{Debugging and Interfacing}, for detailed information on
5503 how this particular version of @code{g77} implements various
5506 @node Specification Statements
5507 @section Specification Statements
5509 (The following information augments or overrides the information in
5510 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5512 Chapter 8 of that document otherwise serves as the basis
5513 for the relevant aspects of GNU Fortran.)
5521 @subsection @code{NAMELIST} Statement
5522 @cindex NAMELIST statement
5523 @cindex statements, NAMELIST
5525 The @code{NAMELIST} statement, and related I/O constructs, are
5526 supported by the GNU Fortran language in essentially the same
5527 way as they are by @code{f2c}.
5529 @node DOUBLE COMPLEX
5530 @subsection @code{DOUBLE COMPLEX} Statement
5531 @cindex DOUBLE COMPLEX
5533 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5534 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5536 @node Control Statements
5537 @section Control Statements
5539 (The following information augments or overrides the information in
5540 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5542 Chapter 11 of that document otherwise serves as the basis
5543 for the relevant aspects of GNU Fortran.)
5553 @subsection DO WHILE
5555 @cindex MIL-STD 1753
5557 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5558 Fortran 90 standards, is provided by the GNU Fortran language.
5563 @cindex MIL-STD 1753
5565 The @code{END DO} statement is provided by the GNU Fortran language.
5567 This statement is used in one of two ways:
5571 The Fortran 90 meaning, in which it specifies the termination
5572 point of a single @code{DO} loop started with a @code{DO} statement
5573 that specifies no termination label.
5576 The MIL-STD 1753 meaning, in which it specifies the termination
5577 point of one or more @code{DO} loops, all of which start with a
5578 @code{DO} statement that specify the label defined for the
5579 @code{END DO} statement.
5581 This kind of @code{END DO} statement is merely a synonym for
5582 @code{CONTINUE}, except it is permitted only when the statement
5583 is labeled and a target of one or more labeled @code{DO} loops.
5585 It is expected that this use of @code{END DO} will be removed from
5586 the GNU Fortran language in the future, though it is likely that
5587 it will long be supported by @code{g77} as a dialect form.
5590 @node Construct Names
5591 @subsection Construct Names
5592 @cindex construct names
5594 The GNU Fortran language supports construct names as defined
5595 by the Fortran 90 standard.
5596 These names are local to the program unit and are defined
5600 @var{construct-name}: @var{block-statement}
5604 Here, @var{construct-name} is the construct name itself;
5605 its definition is connoted by the single colon (@samp{:}); and
5606 @var{block-statement} is an @code{IF}, @code{DO},
5607 or @code{SELECT CASE} statement that begins a block.
5609 A block that is given a construct name must also specify the
5610 same construct name in its termination statement:
5613 END @var{block} @var{construct-name}
5617 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5620 @node CYCLE and EXIT
5621 @subsection The @code{CYCLE} and @code{EXIT} Statements
5623 The @code{CYCLE} and @code{EXIT} statements specify that
5624 the remaining statements in the current iteration of a
5625 particular active (enclosing) @code{DO} loop are to be skipped.
5627 @code{CYCLE} specifies that these statements are skipped,
5628 but the @code{END DO} statement that marks the end of the
5629 @code{DO} loop be executed---that is, the next iteration,
5630 if any, is to be started.
5631 If the statement marking the end of the @code{DO} loop is
5632 not @code{END DO}---in other words, if the loop is not
5633 a block @code{DO}---the @code{CYCLE} statement does not
5634 execute that statement, but does start the next iteration (if any).
5636 @code{EXIT} specifies that the loop specified by the
5637 @code{DO} construct is terminated.
5639 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5640 is the innermost enclosing @code{DO} loop when the following
5648 Otherwise, the following forms specify the construct name
5649 of the pertinent @code{DO} loop:
5652 CYCLE @var{construct-name}
5653 EXIT @var{construct-name}
5656 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5658 However, they cannot be easily thought of as @code{GO TO} statements
5659 in obscure cases involving FORTRAN 77 loops.
5668 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5673 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5674 above are equivalent to a @code{GO TO} statement to either label
5675 @samp{10} or @samp{20}.
5677 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5678 above fragment, it is helpful to first translate it to its equivalent
5679 using only block @code{DO} loops:
5687 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5694 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5695 to @code{GO TO} so they may be more easily understood by programmers
5696 accustomed to FORTRAN coding:
5701 IF (J .EQ. 5) GOTO 18
5703 IF (K .EQ. 3) GO TO 12
5704 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5712 Thus, the @code{CYCLE} statement in the innermost loop skips over
5713 the @code{PRINT} statement as it begins the next iteration of the
5714 loop, while the @code{EXIT} statement in the middle loop ends that
5715 loop but @emph{not} the outermost loop.
5717 @node Functions and Subroutines
5718 @section Functions and Subroutines
5720 (The following information augments or overrides the information in
5721 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5723 Chapter 15 of that document otherwise serves as the basis
5724 for the relevant aspects of GNU Fortran.)
5730 * Generics and Specifics::
5731 * REAL() and AIMAG() of Complex::
5732 * CMPLX() of DOUBLE PRECISION::
5734 * f77/f2c Intrinsics::
5735 * Table of Intrinsic Functions::
5739 @subsection The @code{%VAL()} Construct
5740 @cindex %VAL() construct
5746 The @code{%VAL()} construct specifies that an argument,
5747 @var{arg}, is to be passed by value, instead of by reference
5750 @code{%VAL()} is restricted to actual arguments in
5751 invocations of external procedures.
5753 Use of @code{%VAL()} is recommended only for code that
5754 is accessing facilities outside of GNU Fortran, such as
5755 operating system or windowing facilities.
5756 It is best to constrain such uses to isolated portions of
5757 a program---portions the deal specifically and exclusively
5758 with low-level, system-dependent facilities.
5759 Such portions might well provide a portable interface for
5760 use by the program as a whole, but are themselves not
5761 portable, and should be thoroughly tested each time they
5762 are rebuilt using a new compiler or version of a compiler.
5764 @emph{Implementation Note:} Currently, @code{g77} passes
5765 all arguments either by reference or by descriptor.
5767 Thus, use of @code{%VAL()} tends to be restricted to cases
5768 where the called procedure is written in a language other
5769 than Fortran that supports call-by-value semantics.
5770 (C is an example of such a language.)
5772 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5773 for detailed information on
5774 how this particular version of @code{g77} passes arguments
5778 @subsection The @code{%REF()} Construct
5779 @cindex %REF() construct
5785 The @code{%REF()} construct specifies that an argument,
5786 @var{arg}, is to be passed by reference, instead of by
5787 value or descriptor.
5789 @code{%REF()} is restricted to actual arguments in
5790 invocations of external procedures.
5792 Use of @code{%REF()} is recommended only for code that
5793 is accessing facilities outside of GNU Fortran, such as
5794 operating system or windowing facilities.
5795 It is best to constrain such uses to isolated portions of
5796 a program---portions the deal specifically and exclusively
5797 with low-level, system-dependent facilities.
5798 Such portions might well provide a portable interface for
5799 use by the program as a whole, but are themselves not
5800 portable, and should be thoroughly tested each time they
5801 are rebuilt using a new compiler or version of a compiler.
5803 Do not depend on @code{%REF()} supplying a pointer to the
5804 procedure being invoked.
5805 While that is a likely implementation choice, other
5806 implementation choices are available that preserve Fortran
5807 pass-by-reference semantics without passing a pointer to
5808 the argument, @var{arg}.
5809 (For example, a copy-in/copy-out implementation.)
5811 @emph{Implementation Note:} Currently, @code{g77} passes
5813 (other than variables and arrays of type @code{CHARACTER})
5815 Future versions of, or dialects supported by, @code{g77} might
5816 not pass @code{CHARACTER} functions by reference.
5818 Thus, use of @code{%REF()} tends to be restricted to cases
5819 where @var{arg} is type @code{CHARACTER} but the called
5820 procedure accesses it via a means other than the method
5821 used for Fortran @code{CHARACTER} arguments.
5823 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5824 how this particular version of @code{g77} passes arguments
5828 @subsection The @code{%DESCR()} Construct
5829 @cindex %DESCR() construct
5835 The @code{%DESCR()} construct specifies that an argument,
5836 @var{arg}, is to be passed by descriptor, instead of by
5839 @code{%DESCR()} is restricted to actual arguments in
5840 invocations of external procedures.
5842 Use of @code{%DESCR()} is recommended only for code that
5843 is accessing facilities outside of GNU Fortran, such as
5844 operating system or windowing facilities.
5845 It is best to constrain such uses to isolated portions of
5846 a program---portions the deal specifically and exclusively
5847 with low-level, system-dependent facilities.
5848 Such portions might well provide a portable interface for
5849 use by the program as a whole, but are themselves not
5850 portable, and should be thoroughly tested each time they
5851 are rebuilt using a new compiler or version of a compiler.
5853 Do not depend on @code{%DESCR()} supplying a pointer
5854 and/or a length passed by value
5855 to the procedure being invoked.
5856 While that is a likely implementation choice, other
5857 implementation choices are available that preserve the
5858 pass-by-reference semantics without passing a pointer to
5859 the argument, @var{arg}.
5860 (For example, a copy-in/copy-out implementation.)
5861 And, future versions of @code{g77} might change the
5862 way descriptors are implemented, such as passing a
5863 single argument pointing to a record containing the
5864 pointer/length information instead of passing that same
5865 information via two arguments as it currently does.
5867 @emph{Implementation Note:} Currently, @code{g77} passes
5868 all variables and arrays of type @code{CHARACTER}
5870 Future versions of, or dialects supported by, @code{g77} might
5871 pass @code{CHARACTER} functions by descriptor as well.
5873 Thus, use of @code{%DESCR()} tends to be restricted to cases
5874 where @var{arg} is not type @code{CHARACTER} but the called
5875 procedure accesses it via a means similar to the method
5876 used for Fortran @code{CHARACTER} arguments.
5878 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5879 how this particular version of @code{g77} passes arguments
5882 @node Generics and Specifics
5883 @subsection Generics and Specifics
5884 @cindex generic intrinsics
5885 @cindex intrinsics, generic
5887 The ANSI FORTRAN 77 language defines generic and specific
5889 In short, the distinctions are:
5893 @emph{Specific} intrinsics have
5894 specific types for their arguments and a specific return
5898 @emph{Generic} intrinsics are treated,
5899 on a case-by-case basis in the program's source code,
5900 as one of several possible specific intrinsics.
5902 Typically, a generic intrinsic has a return type that
5903 is determined by the type of one or more of its arguments.
5906 The GNU Fortran language generalizes these concepts somewhat,
5907 especially by providing intrinsic subroutines and generic
5908 intrinsics that are treated as either a specific intrinsic subroutine
5909 or a specific intrinsic function (e.g. @code{SECOND}).
5911 However, GNU Fortran avoids generalizing this concept to
5912 the point where existing code would be accepted as meaning
5913 something possibly different than what was intended.
5915 For example, @code{ABS} is a generic intrinsic, so all working
5916 code written using @code{ABS} of an @code{INTEGER} argument
5917 expects an @code{INTEGER} return value.
5918 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
5919 argument returns an @code{INTEGER*2} return value.
5921 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
5922 an @code{INTEGER(KIND=1)} argument.
5923 Code that passes something other than an @code{INTEGER(KIND=1)}
5924 argument to @code{IABS} is not valid GNU Fortran code, because
5925 it is not clear what the author intended.
5927 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
5928 is not defined by the GNU Fortran language, because the programmer
5929 might have used that construct to mean any of the following, subtly
5934 Convert @samp{J} to @code{INTEGER(KIND=1)} first
5935 (as if @samp{IABS(INT(J))} had been written).
5938 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
5939 (as if @samp{INT(ABS(J))} had been written).
5942 No conversion (as if @samp{ABS(J)} had been written).
5945 The distinctions matter especially when types and values wider than
5946 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
5947 operations performing more ``arithmetic'' than absolute-value, are involved.
5949 The following sample program is not a valid GNU Fortran program, but
5950 might be accepted by other compilers.
5951 If so, the output is likely to be revealing in terms of how a given
5952 compiler treats intrinsics (that normally are specific) when they
5953 are given arguments that do not conform to their stated requirements:
5955 @cindex JCB002 program
5959 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
5960 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
5963 C Written by James Craig Burley 1997-02-20.
5964 C Contact via Internet email: burley@@gnu.org
5967 C Determine how compilers handle non-standard IDIM
5968 C on INTEGER*2 operands, which presumably can be
5969 C extrapolated into understanding how the compiler
5970 C generally treats specific intrinsics that are passed
5971 C arguments not of the correct types.
5973 C If your compiler implements INTEGER*2 and INTEGER
5974 C as the same type, change all INTEGER*2 below to
5979 INTEGER*2 ISMALL, ILARGE
5980 INTEGER*2 ITOOLG, ITWO
5984 C Find smallest INTEGER*2 number.
5988 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
5993 C Find largest INTEGER*2 number.
5997 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
6002 C Multiplying by two adds stress to the situation.
6006 C Need a number that, added to -2, is too wide to fit in I*2.
6010 C Use IDIM the straightforward way.
6012 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
6014 C Calculate result for first interpretation.
6016 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
6018 C Calculate result for second interpretation.
6020 ITMP = ILARGE - ISMALL
6021 I3 = (INT (ITMP)) * ITWO + ITOOLG
6023 C Calculate result for third interpretation.
6025 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
6029 PRINT *, 'ILARGE=', ILARGE
6030 PRINT *, 'ITWO=', ITWO
6031 PRINT *, 'ITOOLG=', ITOOLG
6032 PRINT *, 'ISMALL=', ISMALL
6041 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
6042 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
6045 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
6046 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
6049 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
6050 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
6053 PRINT *, 'Results need careful analysis.'
6057 No future version of the GNU Fortran language
6058 will likely permit specific intrinsic invocations with wrong-typed
6059 arguments (such as @code{IDIM} in the above example), since
6060 it has been determined that disagreements exist among
6061 many production compilers on the interpretation of
6063 These disagreements strongly suggest that Fortran programmers,
6064 and certainly existing Fortran programs, disagree about the
6065 meaning of such invocations.
6067 The first version of @samp{JCB002} didn't accommodate some compilers'
6068 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
6070 In such a case, these compilers apparently convert both
6071 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
6072 instead of doing an @code{INTEGER*2} subtraction on the
6073 original values in @samp{I1} and @samp{I2}.
6075 However, the results of the careful analyses done on the outputs
6076 of programs compiled by these various compilers show that they
6077 all implement either @samp{Interp 1} or @samp{Interp 2} above.
6079 Specifically, it is believed that the new version of @samp{JCB002}
6080 above will confirm that:
6084 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
6085 @code{f77} compilers all implement @samp{Interp 1}.
6088 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
6091 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
6092 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
6095 If you get different results than the above for the stated
6096 compilers, or have results for other compilers that might be
6097 worth adding to the above list, please let us know the details
6098 (compiler product, version, machine, results, and so on).
6100 @node REAL() and AIMAG() of Complex
6101 @subsection @code{REAL()} and @code{AIMAG()} of Complex
6102 @cindex REAL intrinsic
6103 @cindex intrinsics, REAL
6104 @cindex AIMAG intrinsic
6105 @cindex intrinsics, AIMAG
6107 The GNU Fortran language disallows @code{REAL(@var{expr})}
6108 and @code{AIMAG(@var{expr})},
6109 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
6110 except when they are used in the following way:
6113 REAL(REAL(@var{expr}))
6114 REAL(AIMAG(@var{expr}))
6118 The above forms explicitly specify that the desired effect
6119 is to convert the real or imaginary part of @var{expr}, which might
6120 be some @code{REAL} type other than @code{REAL(KIND=1)},
6121 to type @code{REAL(KIND=1)},
6122 and have that serve as the value of the expression.
6124 The GNU Fortran language offers clearly named intrinsics to extract the
6125 real and imaginary parts of a complex entity without any
6129 REALPART(@var{expr})
6130 IMAGPART(@var{expr})
6133 To express the above using typical extended FORTRAN 77,
6134 use the following constructs
6135 (when @var{expr} is @code{COMPLEX(KIND=2)}):
6142 The FORTRAN 77 language offers no way
6143 to explicitly specify the real and imaginary parts of a complex expression of
6144 arbitrary type, apparently as a result of requiring support for
6145 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
6146 The concepts of converting an expression to type @code{REAL(KIND=1)} and
6147 of extracting the real part of a complex expression were
6148 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
6149 they happened to have the exact same effect in that language
6150 (due to having only one @code{COMPLEX} type).
6152 @emph{Note:} When @samp{-ff90} is in effect,
6153 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
6154 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
6155 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
6156 treated as @samp{REAL(REALPART(@var{expr}))}.
6158 @xref{Ugly Complex Part Extraction}, for more information.
6160 @node CMPLX() of DOUBLE PRECISION
6161 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
6162 @cindex CMPLX intrinsic
6163 @cindex intrinsics, CMPLX
6165 In accordance with Fortran 90 and at least some (perhaps all)
6166 other compilers, the GNU Fortran language defines @code{CMPLX()}
6167 as always returning a result that is type @code{COMPLEX(KIND=1)}.
6169 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
6170 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
6173 CMPLX(SNGL(D1), SNGL(D2))
6176 (It was necessary for Fortran 90 to specify this behavior
6177 for @code{DOUBLE PRECISION} arguments, since that is
6178 the behavior mandated by FORTRAN 77.)
6180 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
6181 which is provided by some FORTRAN 77 compilers to construct
6182 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
6184 However, this solution does not scale well when more @code{COMPLEX} types
6185 (having various precisions and ranges) are offered by Fortran implementations.
6187 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
6188 an extra argument used to specify the desired kind of complex
6190 However, this solution is somewhat awkward to use, and
6191 @code{g77} currently does not support it.
6193 The GNU Fortran language provides a simple way to build a complex
6194 value out of two numbers, with the precise type of the value
6195 determined by the types of the two numbers (via the usual
6196 type-promotion mechanism):
6199 COMPLEX(@var{real}, @var{imag})
6202 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
6203 performs no conversion other than to put them together to form a
6204 complex result of the same (complex version of real) type.
6206 @xref{Complex Intrinsic}, for more information.
6209 @subsection MIL-STD 1753 Support
6210 @cindex MIL-STD 1753
6212 The GNU Fortran language includes the MIL-STD 1753 intrinsics
6213 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
6214 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
6215 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
6217 @node f77/f2c Intrinsics
6218 @subsection @code{f77}/@code{f2c} Intrinsics
6220 The bit-manipulation intrinsics supported by traditional
6221 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
6222 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
6225 Also supported are the intrinsics @code{CDABS},
6226 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
6227 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
6228 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
6229 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
6232 @node Table of Intrinsic Functions
6233 @subsection Table of Intrinsic Functions
6234 @cindex intrinsics, table of
6235 @cindex table of intrinsics
6237 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
6239 The GNU Fortran language adds various functions, subroutines, types,
6240 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
6241 The complete set of intrinsics supported by the GNU Fortran language
6244 Note that a name is not treated as that of an intrinsic if it is
6245 specified in an @code{EXTERNAL} statement in the same program unit;
6246 if a command-line option is used to disable the groups to which
6247 the intrinsic belongs; or if the intrinsic is not named in an
6248 @code{INTRINSIC} statement and a command-line option is used to
6249 hide the groups to which the intrinsic belongs.
6251 So, it is recommended that any reference in a program unit to
6252 an intrinsic procedure that is not a standard FORTRAN 77
6253 intrinsic be accompanied by an appropriate @code{INTRINSIC}
6254 statement in that program unit.
6255 This sort of defensive programming makes it more
6256 likely that an implementation will issue a diagnostic rather
6257 than generate incorrect code for such a reference.
6259 The terminology used below is based on that of the Fortran 90
6260 standard, so that the text may be more concise and accurate:
6264 @code{OPTIONAL} means the argument may be omitted.
6267 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
6268 (generally named @samp{A}) may be specified.
6271 @samp{scalar} means the argument must not be an array (must
6272 be a variable or array element, or perhaps a constant if expressions
6276 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
6279 @code{INTENT(IN)} means the argument must be an expression
6280 (such as a constant or a variable that is defined upon invocation
6284 @code{INTENT(OUT)} means the argument must be definable by the
6285 invocation of the intrinsic (that is, must not be a constant nor
6286 an expression involving operators other than array reference and
6287 substring reference).
6290 @code{INTENT(INOUT)} means the argument must be defined prior to,
6291 and definable by, invocation of the intrinsic (a combination of
6292 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
6295 @xref{Kind Notation} for explanation of @code{KIND}.
6299 (Note that the empty lines appearing in the menu below
6300 are not intentional---they result from a bug in the
6301 GNU @code{makeinfo} program@dots{}a program that, if it
6302 did not exist, would leave this document in far worse shape!)
6305 @c The actual documentation for intrinsics comes from
6306 @c intdoc.texi, which in turn is automatically generated
6307 @c from the internal g77 tables in intrin.def _and_ the
6308 @c largely hand-written text in intdoc.h. So, if you want
6309 @c to change or add to existing documentation on intrinsics,
6310 @c you probably want to edit intdoc.h.
6322 @include intdoc.texi
6324 @node Scope and Classes of Names
6325 @section Scope and Classes of Symbolic Names
6326 @cindex symbolic names
6329 (The following information augments or overrides the information in
6330 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
6332 Chapter 18 of that document otherwise serves as the basis
6333 for the relevant aspects of GNU Fortran.)
6336 * Underscores in Symbol Names::
6339 @node Underscores in Symbol Names
6340 @subsection Underscores in Symbol Names
6343 Underscores (@samp{_}) are accepted in symbol names after the first
6344 character (which must be a letter).
6346 @node Other Dialects
6347 @chapter Other Dialects
6349 GNU Fortran supports a variety of features that are not
6350 considered part of the GNU Fortran language itself, but
6351 are representative of various dialects of Fortran that
6352 @code{g77} supports in whole or in part.
6354 Any of the features listed below might be disallowed by
6355 @code{g77} unless some command-line option is specified.
6356 Currently, some of the features are accepted using the
6357 default invocation of @code{g77}, but that might change
6360 @emph{Note: This portion of the documentation definitely needs a lot
6364 * Source Form:: Details of fixed-form and free-form source.
6365 * Trailing Comment:: Use of @samp{/*} to start a comment.
6366 * Debug Line:: Use of @samp{D} in column 1.
6367 * Dollar Signs:: Use of @samp{$} in symbolic names.
6368 * Case Sensitivity:: Uppercase and lowercase in source files.
6369 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6370 * Fortran 90:: @dots{}versus the GNU Fortran language.
6371 * Pedantic Compilation:: Enforcing the standard.
6372 * Distensions:: Misfeatures supported by GNU Fortran.
6376 @section Source Form
6377 @cindex source file format
6379 @cindex files, source
6381 @cindex code, source
6385 GNU Fortran accepts programs written in either fixed form or
6389 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6390 allowing tabs) and Fortran 90's fixed form.
6392 Free form corresponds to
6393 Fortran 90's free form (though possibly not entirely up-to-date, and
6394 without complaining about some things that for which Fortran 90 requires
6395 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6397 The way a Fortran compiler views source files depends entirely on the
6398 implementation choices made for the compiler, since those choices
6399 are explicitly left to the implementation by the published Fortran
6401 GNU Fortran currently tries to be somewhat like a few popular compilers
6402 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6403 definition along with more
6404 flexibility offered by command-line options is likely to be offered
6407 This section describes how @code{g77} interprets source lines.
6410 * Carriage Returns:: Carriage returns ignored.
6411 * Tabs:: Tabs converted to spaces.
6412 * Short Lines:: Short lines padded with spaces (fixed-form only).
6413 * Long Lines:: Long lines truncated.
6414 * Ampersands:: Special Continuation Lines.
6417 @node Carriage Returns
6418 @subsection Carriage Returns
6419 @cindex carriage returns
6421 Carriage returns (@samp{\r}) in source lines are ignored.
6422 This is somewhat different from @code{f2c}, which seems to treat them as
6423 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6424 inside such constants.
6428 @cindex tab characters
6430 A source line with a @key{TAB} character anywhere in it is treated as
6431 entirely significant---however long it is---instead of ending in
6432 column 72 (for fixed-form source) or 132 (for free-form source).
6433 This also is different from @code{f2c}, which encodes tabs as
6434 @samp{\t} (the ASCII @key{TAB} character) inside character
6435 and Hollerith constants, but nevertheless seems to treat the column
6436 position as if it had been affected by the canonical tab positioning.
6438 @code{g77} effectively
6439 translates tabs to the appropriate number of spaces (a la the default
6440 for the UNIX @code{expand} command) before doing any other processing, other
6441 than (currently) noting whether a tab was found on a line and using this
6442 information to decide how to interpret the length of the line and continued
6445 Note that this default behavior probably will change for version 0.6,
6446 when it will presumably be available via a command-line option.
6447 The default as of version 0.6 is planned to be a ``pure visual''
6448 model, where tabs are immediately
6449 converted to spaces and otherwise have no effect, so the way a typical
6450 user sees source lines produces a consistent result no matter how the
6451 spacing in those source lines is actually implemented via tabs, spaces,
6452 and trailing tabs/spaces before newline.
6453 Command-line options are likely to be added to specify whether all or
6454 just-tabbed lines are to be extended to 132 or full input-line length,
6455 and perhaps even an option will be added to specify the truncated-line
6456 behavior to which some Digital compilers default (and which affects
6457 the way continued character/Hollerith constants are interpreted).
6460 @subsection Short Lines
6461 @cindex short source lines
6462 @cindex space-padding
6464 @cindex source lines, short
6465 @cindex lines, short
6467 Source lines shorter than the applicable fixed-form length are treated as
6468 if they were padded with spaces to that length.
6469 (None of this is relevant to source files written in free form.)
6472 continued character and Hollerith constants, and is a different
6473 interpretation than provided by some other popular compilers
6474 (although a bit more consistent with the traditional punched-card
6475 basis of Fortran and the way the Fortran standard expressed fixed
6478 @code{g77} might someday offer an option to warn about cases where differences
6479 might be seen as a result of this treatment, and perhaps an option to
6480 specify the alternate behavior as well.
6482 Note that this padding cannot apply to lines that are effectively of
6483 infinite length---such lines are specified using command-line options
6484 like @samp{-ffixed-line-length-none}, for example.
6487 @subsection Long Lines
6488 @cindex long source lines
6491 @cindex source lines, long
6493 Source lines longer than the applicable length are truncated to that
6495 Currently, @code{g77} does not warn if the truncated characters are
6496 not spaces, to accommodate existing code written for systems that
6497 treated truncated text as commentary (especially in columns 73 through 80).
6499 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6500 for information on the @samp{-ffixed-line-length-@var{n}} option,
6501 which can be used to set the line length applicable to fixed-form
6505 @subsection Ampersand Continuation Line
6506 @cindex ampersand continuation line
6507 @cindex continuation line, ampersand
6509 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6510 continuation line, imitating the behavior of @code{f2c}.
6512 @node Trailing Comment
6513 @section Trailing Comment
6515 @code{g77} supports use of @samp{/*} to start a trailing
6517 In the GNU Fortran language, @samp{!} is used for this purpose.
6519 @samp{/*} is not in the GNU Fortran language
6520 because the use of @samp{/*} in a program might
6521 suggest to some readers that a block, not trailing, comment is
6522 started (and thus ended by @samp{*/}, not end of line),
6523 since that is the meaning of @samp{/*} in C.
6525 Also, such readers might think they can use @samp{//} to start
6526 a trailing comment as an alternative to @samp{/*}, but
6527 @samp{//} already denotes concatenation, and such a ``comment''
6528 might actually result in a program that compiles without
6529 error (though it would likely behave incorrectly).
6535 Use of @samp{D} or @samp{d} as the first character (column 1) of
6536 a source line denotes a debug line.
6538 In turn, a debug line is treated as either a comment line
6539 or a normal line, depending on whether debug lines are enabled.
6541 When treated as a comment line, a line beginning with @samp{D} or
6542 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6543 When treated as a normal line, such a line is treated as if
6544 the first character was @key{SPC} (space).
6546 (Currently, @code{g77} provides no means for treating debug
6547 lines as normal lines.)
6550 @section Dollar Signs in Symbol Names
6554 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6555 when the @samp{-fdollar-ok} option is specified.
6557 @node Case Sensitivity
6558 @section Case Sensitivity
6559 @cindex case sensitivity
6560 @cindex source file format
6561 @cindex code, source
6563 @cindex uppercase letters
6564 @cindex lowercase letters
6565 @cindex letters, uppercase
6566 @cindex letters, lowercase
6568 GNU Fortran offers the programmer way too much flexibility in deciding
6569 how source files are to be treated vis-a-vis uppercase and lowercase
6571 There are 66 useful settings that affect case sensitivity, plus 10
6572 settings that are nearly useless, with the remaining 116 settings
6573 being either redundant or useless.
6575 None of these settings have any effect on the contents of comments
6576 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6577 or of character or Hollerith constants.
6578 Note that things like the @samp{E} in the statement
6579 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6580 are considered built-in keywords, and so are affected by
6583 Low-level switches are identified in this section as follows:
6587 Source Case Conversion:
6591 Preserve (see Note 1)
6593 Convert to Upper Case
6595 Convert to Lower Case
6599 Built-in Keyword Matching:
6603 Match Any Case (per-character basis)
6605 Match Upper Case Only
6607 Match Lower Case Only
6609 Match InitialCaps Only (see tables for spellings)
6613 Built-in Intrinsic Matching:
6617 Match Any Case (per-character basis)
6619 Match Upper Case Only
6621 Match Lower Case Only
6623 Match InitialCaps Only (see tables for spellings)
6627 User-defined Symbol Possibilities (warnings only):
6631 Allow Any Case (per-character basis)
6633 Allow Upper Case Only
6635 Allow Lower Case Only
6637 Allow InitialCaps Only (see Note 2)
6641 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6642 consistent with these source switches---in the sense that input will be
6643 expected to meet the same requirements as source code in terms
6644 of matching symbol names and keywords (for the exponent letters).
6646 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6647 which uppercases @code{NAMELIST} input and symbol names for matching.
6648 This means not only that @code{NAMELIST} output currently shows symbol
6649 (and keyword) names in uppercase even if lower-case source
6650 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6651 adequately supported when source case preservation (option A0)
6654 If A0 is selected, a warning message will be
6655 output for each @code{NAMELIST} statement to this effect.
6657 of the program is undefined at run time if two or more symbol names
6658 appear in a given @code{NAMELIST} such that the names are identical
6659 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6660 For complete and total elegance, perhaps there should be a warning
6661 when option A2 is selected, since the output of NAMELIST is currently
6662 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6663 but that seems to be overkill for a product in beta test.
6665 Note 2: Rules for InitialCaps names are:
6669 Must be a single uppercase letter, @strong{or}
6671 Must start with an uppercase letter and contain at least one
6675 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6676 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6678 Note that most, but not all, built-in names meet these
6679 requirements---the exceptions are some of the two-letter format
6680 specifiers, such as @samp{BN} and @samp{BZ}.
6682 Here are the names of the corresponding command-line options:
6685 A0: -fsource-case-preserve
6686 A1: -fsource-case-upper
6687 A2: -fsource-case-lower
6689 B0: -fmatch-case-any
6690 B1: -fmatch-case-upper
6691 B2: -fmatch-case-lower
6692 B3: -fmatch-case-initcap
6694 C0: -fintrin-case-any
6695 C1: -fintrin-case-upper
6696 C2: -fintrin-case-lower
6697 C3: -fintrin-case-initcap
6699 D0: -fsymbol-case-any
6700 D1: -fsymbol-case-upper
6701 D2: -fsymbol-case-lower
6702 D3: -fsymbol-case-initcap
6705 Useful combinations of the above settings, along with abbreviated
6706 option names that set some of these combinations all at once:
6709 1: A0-- B0--- C0--- D0--- -fcase-preserve
6710 2: A0-- B0--- C0--- D-1--
6711 3: A0-- B0--- C0--- D--2-
6712 4: A0-- B0--- C0--- D---3
6713 5: A0-- B0--- C-1-- D0---
6714 6: A0-- B0--- C-1-- D-1--
6715 7: A0-- B0--- C-1-- D--2-
6716 8: A0-- B0--- C-1-- D---3
6717 9: A0-- B0--- C--2- D0---
6718 10: A0-- B0--- C--2- D-1--
6719 11: A0-- B0--- C--2- D--2-
6720 12: A0-- B0--- C--2- D---3
6721 13: A0-- B0--- C---3 D0---
6722 14: A0-- B0--- C---3 D-1--
6723 15: A0-- B0--- C---3 D--2-
6724 16: A0-- B0--- C---3 D---3
6725 17: A0-- B-1-- C0--- D0---
6726 18: A0-- B-1-- C0--- D-1--
6727 19: A0-- B-1-- C0--- D--2-
6728 20: A0-- B-1-- C0--- D---3
6729 21: A0-- B-1-- C-1-- D0---
6730 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6731 23: A0-- B-1-- C-1-- D--2-
6732 24: A0-- B-1-- C-1-- D---3
6733 25: A0-- B-1-- C--2- D0---
6734 26: A0-- B-1-- C--2- D-1--
6735 27: A0-- B-1-- C--2- D--2-
6736 28: A0-- B-1-- C--2- D---3
6737 29: A0-- B-1-- C---3 D0---
6738 30: A0-- B-1-- C---3 D-1--
6739 31: A0-- B-1-- C---3 D--2-
6740 32: A0-- B-1-- C---3 D---3
6741 33: A0-- B--2- C0--- D0---
6742 34: A0-- B--2- C0--- D-1--
6743 35: A0-- B--2- C0--- D--2-
6744 36: A0-- B--2- C0--- D---3
6745 37: A0-- B--2- C-1-- D0---
6746 38: A0-- B--2- C-1-- D-1--
6747 39: A0-- B--2- C-1-- D--2-
6748 40: A0-- B--2- C-1-- D---3
6749 41: A0-- B--2- C--2- D0---
6750 42: A0-- B--2- C--2- D-1--
6751 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6752 44: A0-- B--2- C--2- D---3
6753 45: A0-- B--2- C---3 D0---
6754 46: A0-- B--2- C---3 D-1--
6755 47: A0-- B--2- C---3 D--2-
6756 48: A0-- B--2- C---3 D---3
6757 49: A0-- B---3 C0--- D0---
6758 50: A0-- B---3 C0--- D-1--
6759 51: A0-- B---3 C0--- D--2-
6760 52: A0-- B---3 C0--- D---3
6761 53: A0-- B---3 C-1-- D0---
6762 54: A0-- B---3 C-1-- D-1--
6763 55: A0-- B---3 C-1-- D--2-
6764 56: A0-- B---3 C-1-- D---3
6765 57: A0-- B---3 C--2- D0---
6766 58: A0-- B---3 C--2- D-1--
6767 59: A0-- B---3 C--2- D--2-
6768 60: A0-- B---3 C--2- D---3
6769 61: A0-- B---3 C---3 D0---
6770 62: A0-- B---3 C---3 D-1--
6771 63: A0-- B---3 C---3 D--2-
6772 64: A0-- B---3 C---3 D---3 -fcase-initcap
6773 65: A-1- B01-- C01-- D01-- -fcase-upper
6774 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6777 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6778 (except comments, character constants, and Hollerith strings) must
6779 be entered in uppercase.
6780 Use @samp{-fcase-strict-upper} to specify this
6783 Number 43 is like Number 22 except all input must be lowercase. Use
6784 @samp{-fcase-strict-lower} to specify this combination.
6786 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6787 non-UNIX machines whereby all the source is translated to uppercase.
6788 Use @samp{-fcase-upper} to specify this combination.
6790 Number 66 is the ``canonical'' UNIX model whereby all the source is
6791 translated to lowercase.
6792 Use @samp{-fcase-lower} to specify this combination.
6794 There are a few nearly useless combinations:
6797 67: A-1- B01-- C01-- D--2-
6798 68: A-1- B01-- C01-- D---3
6799 69: A-1- B01-- C--23 D01--
6800 70: A-1- B01-- C--23 D--2-
6801 71: A-1- B01-- C--23 D---3
6802 72: A--2 B01-- C0-2- D-1--
6803 73: A--2 B01-- C0-2- D---3
6804 74: A--2 B01-- C-1-3 D0-2-
6805 75: A--2 B01-- C-1-3 D-1--
6806 76: A--2 B01-- C-1-3 D---3
6809 The above allow some programs to be compiled but with restrictions that
6810 make most useful programs impossible: Numbers 67 and 72 warn about
6811 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6813 68 and 73 warn about any user-defined symbol names longer than one
6814 character that don't have at least one non-alphabetic character after
6816 Numbers 69 and 74 disallow any references to intrinsics;
6817 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6818 67+69, 68+69, 72+74, and 73+74, respectively.
6820 All redundant combinations are shown in the above tables anyplace
6821 where more than one setting is shown for a low-level switch.
6822 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6823 The ``proper'' setting in such a case is the one that copies the setting
6824 of switch A---any other setting might slightly reduce the speed of
6825 the compiler, though possibly to an unmeasurable extent.
6827 All remaining combinations are useless in that they prevent successful
6828 compilation of non-null source files (source files with something other
6832 @section VXT Fortran
6834 @cindex VXT extensions
6835 @cindex extensions, VXT
6836 @code{g77} supports certain constructs that
6837 have different meanings in VXT Fortran than they
6838 do in the GNU Fortran language.
6840 Generally, this manual uses the invented term VXT Fortran to refer
6841 VAX FORTRAN (circa v4).
6842 That compiler offered many popular features, though not necessarily
6843 those that are specific to the VAX processor architecture,
6844 the VMS operating system,
6845 or Digital Equipment Corporation's Fortran product line.
6846 (VAX and VMS probably are trademarks of Digital Equipment
6849 An extension offered by a Digital Fortran product that also is
6850 offered by several other Fortran products for different kinds of
6851 systems is probably going to be considered for inclusion in @code{g77}
6852 someday, and is considered a VXT Fortran feature.
6854 The @samp{-fvxt} option generally specifies that, where
6855 the meaning of a construct is ambiguous (means one thing
6856 in GNU Fortran and another in VXT Fortran), the VXT Fortran
6857 meaning is to be assumed.
6860 * Double Quote Meaning:: @samp{"2000} as octal constant.
6861 * Exclamation Point:: @samp{!} in column 6.
6864 @node Double Quote Meaning
6865 @subsection Meaning of Double Quote
6866 @cindex double quotes
6867 @cindex character constants
6868 @cindex constants, character
6869 @cindex octal constants
6870 @cindex constants, octal
6872 @code{g77} treats double-quote (@samp{"})
6873 as beginning an octal constant of @code{INTEGER(KIND=1)} type
6874 when the @code{-fvxt} option is specified.
6875 The form of this octal constant is
6882 where @var{octal-digits} is a nonempty string of characters in
6883 the set @samp{01234567}.
6885 For example, the @code{-fvxt} option permits this:
6893 The above program would print the value @samp{16}.
6895 @xref{Integer Type}, for information on the preferred construct
6896 for integer constants specified using GNU Fortran's octal notation.
6898 (In the GNU Fortran language, the double-quote character (@samp{"})
6899 delimits a character constant just as does apostrophe (@samp{'}).
6900 There is no way to allow
6901 both constructs in the general case, since statements like
6902 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
6904 @node Exclamation Point
6905 @subsection Meaning of Exclamation Point in Column 6
6906 @cindex exclamation points
6907 @cindex continuation character
6908 @cindex characters, continuation
6909 @cindex comment character
6910 @cindex characters, comment
6912 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
6913 a fixed-form source file
6914 as a continuation character rather than
6915 as the beginning of a comment
6916 (as it does in any other column)
6917 when the @code{-fvxt} option is specified.
6919 The following program, when run, prints a message indicating
6920 whether it is interpreted according to GNU Fortran (and Fortran 90)
6921 rules or VXT Fortran rules:
6924 C234567 (This line begins in column 1.)
6927 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
6928 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
6929 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
6933 (In the GNU Fortran and Fortran 90 languages, exclamation point is
6934 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
6935 marks a line as a continuation line when it appears in column 6.)
6939 @cindex compatibility, Fortran 90
6940 @cindex Fortran 90 compatibility
6942 The GNU Fortran language includes a number of features that are
6943 part of Fortran 90, even when the @samp{-ff90} option is not specified.
6944 The features enabled by @samp{-ff90} are intended to be those that,
6945 when @samp{-ff90} is not specified, would have another
6946 meaning to @code{g77}---usually meaning something invalid in the
6947 GNU Fortran language.
6949 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
6950 to gratuitously reject Fortran 90 constructs.
6951 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
6952 to do that, although its implementation is certainly incomplete at
6955 When @samp{-ff90} is specified:
6959 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
6960 where @var{expr} is @code{COMPLEX} type,
6961 is the same type as the real part of @var{expr}.
6963 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
6964 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
6965 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
6968 @node Pedantic Compilation
6969 @section Pedantic Compilation
6970 @cindex pedantic compilation
6971 @cindex compilation, pedantic
6973 The @samp{-fpedantic} command-line option specifies that @code{g77}
6974 is to warn about code that is not standard-conforming.
6975 This is useful for finding
6976 some extensions @code{g77} accepts that other compilers might not accept.
6977 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
6978 always imply @samp{-fpedantic}.)
6980 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
6981 for conforming code.
6982 With @samp{-ff90} in force, Fortran 90 is used.
6984 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
6985 and @samp{-fno-f90} are in force are:
6989 Automatic arrays, as in
6998 where @samp{A} is not listed in any @code{ENTRY} statement,
6999 and thus is not a dummy argument.
7002 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
7004 These commas are disallowed by FORTRAN 77, but, while strictly
7005 superfluous, are syntactically elegant,
7006 especially given that commas are required in statements such
7007 as @samp{READ 99, I} and @samp{PRINT *, J}.
7008 Many compilers permit the superfluous commas for this reason.
7011 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
7013 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
7014 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
7016 An example of an implicit use is the expression @samp{C*D},
7017 where @samp{C} is @code{COMPLEX(KIND=1)}
7018 and @samp{D} is @code{DOUBLE PRECISION}.
7019 This expression is prohibited by ANSI FORTRAN 77
7020 because the rules of promotion would suggest that it
7021 produce a @code{DOUBLE COMPLEX} result---a type not
7022 provided for by that standard.
7025 Automatic conversion of numeric
7026 expressions to @code{INTEGER(KIND=1)} in contexts such as:
7030 Array-reference indexes.
7032 Alternate-return values.
7034 Computed @code{GOTO}.
7036 @code{FORMAT} run-time expressions (not yet supported).
7038 Dimension lists in specification statements.
7040 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
7042 Sizes of @code{CHARACTER} entities in specification statements.
7044 Kind types in specification entities (a Fortran 90 feature).
7046 Initial, terminal, and incrementation parameters for implied-@code{DO}
7047 constructs in @code{DATA} statements.
7051 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
7052 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
7053 expressions are disallowed anyway).
7056 Zero-size array dimensions, as in:
7059 INTEGER I(10,20,4:2)
7063 Zero-length @code{CHARACTER} entities, as in:
7070 Substring operators applied to character constants and named
7074 PRINT *, 'hello'(3:5)
7078 Null arguments passed to statement function, as in:
7085 Disagreement among program units regarding whether a given @code{COMMON}
7086 area is @code{SAVE}d (for targets where program units in a single source
7087 file are ``glued'' together as they typically are for UNIX development
7091 Disagreement among program units regarding the size of a
7092 named @code{COMMON} block.
7095 Specification statements following first @code{DATA} statement.
7097 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
7098 but not @samp{INTEGER I}.
7099 The @samp{-fpedantic} option disallows both of these.)
7102 Semicolon as statement separator, as in:
7109 @c Comma before list of I/O items in @code{WRITE}
7110 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
7111 @c statements, as with @code{READ} (as explained above).
7114 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
7117 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
7121 Expressions having two arithmetic operators in a row, such
7125 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
7126 following constructs result in diagnostics:
7130 Use of semicolon as a statement separator on a line
7131 that has an @code{INCLUDE} directive.
7135 @section Distensions
7137 @cindex ugly features
7138 @cindex features, ugly
7140 The @samp{-fugly-*} command-line options determine whether certain
7141 features supported by VAX FORTRAN and other such compilers, but considered
7142 too ugly to be in code that can be changed to use safer and/or more
7143 portable constructs, are accepted.
7144 These are humorously referred to as ``distensions'',
7145 extensions that just plain look ugly in the harsh light of day.
7147 @emph{Note:} The @samp{-fugly} option, which currently serves
7148 as shorthand to enable all of the distensions below, is likely to
7149 be removed in a future version of @code{g77}.
7150 That's because it's likely new distensions will be added that
7151 conflict with existing ones in terms of assigning meaning to
7152 a given chunk of code.
7153 (Also, it's pretty clear that users should not use @samp{-fugly}
7154 as shorthand when the next release of @code{g77} might add a
7155 distension to that that causes their existing code, when recompiled,
7156 to behave differently---perhaps even fail to compile or run
7160 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
7161 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
7162 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
7163 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
7164 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
7165 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
7166 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
7169 @node Ugly Implicit Argument Conversion
7170 @subsection Implicit Argument Conversion
7171 @cindex Hollerith constants
7172 @cindex constants, Hollerith
7174 The @samp{-fno-ugly-args} option disables
7175 passing typeless and Hollerith constants as actual arguments
7176 in procedure invocations.
7185 These constructs can be too easily used to create non-portable
7186 code, but are not considered as ``ugly'' as others.
7187 Further, they are widely used in existing Fortran source code
7188 in ways that often are quite portable.
7189 Therefore, they are enabled by default.
7191 @node Ugly Assumed-Size Arrays
7192 @subsection Ugly Assumed-Size Arrays
7193 @cindex arrays, assumed-size
7194 @cindex assumed-size arrays
7195 @cindex DIMENSION X(1)
7197 The @samp{-fugly-assumed} option enables
7198 the treatment of any array with a final dimension specified as @samp{1}
7199 as an assumed-size array, as if @samp{*} had been specified
7202 For example, @samp{DIMENSION X(1)} is treated as if it
7203 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
7204 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
7205 or @code{ENTRY} statement in the same program unit.
7207 Use an explicit lower bound to avoid this interpretation.
7208 For example, @samp{DIMENSION X(1:1)} is never treated as if
7209 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
7210 Nor is @samp{DIMENSION X(2-1)} affected by this option,
7211 since that kind of expression is unlikely to have been
7212 intended to designate an assumed-size array.
7214 This option is used to prevent warnings being issued about apparent
7215 out-of-bounds reference such as @samp{X(2) = 99}.
7217 It also prevents the array from being used in contexts that
7218 disallow assumed-size arrays, such as @samp{PRINT *,X}.
7219 In such cases, a diagnostic is generated and the source file is
7222 The construct affected by this option is used only in old code
7223 that pre-exists the widespread acceptance of adjustable and assumed-size
7224 arrays in the Fortran community.
7226 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
7227 treated if @samp{X} is listed as a dummy argument only
7228 @emph{after} the @code{DIMENSION} statement (presumably in
7229 an @code{ENTRY} statement).
7230 For example, @samp{-fugly-assumed} has no effect on the
7231 following program unit:
7242 @node Ugly Complex Part Extraction
7243 @subsection Ugly Complex Part Extraction
7244 @cindex complex values
7246 @cindex imaginary part
7248 The @samp{-fugly-complex} option enables
7249 use of the @code{REAL()} and @code{AIMAG()}
7250 intrinsics with arguments that are
7251 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
7253 With @samp{-ff90} in effect, these intrinsics return
7254 the unconverted real and imaginary parts (respectively)
7257 With @samp{-fno-f90} in effect, these intrinsics convert
7258 the real and imaginary parts to @code{REAL(KIND=1)}, and return
7259 the result of that conversion.
7261 Due to this ambiguity, the GNU Fortran language defines
7262 these constructs as invalid, except in the specific
7263 case where they are entirely and solely passed as an
7264 argument to an invocation of the @code{REAL()} intrinsic.
7272 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7273 and @samp{-fno-ugly-complex} is in effect, because the
7276 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7277 is specified, in which case the appropriate interpretation is
7278 chosen and no diagnostic is issued.
7280 @xref{CMPAMBIG}, for information on how to cope with existing
7281 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7282 with @code{COMPLEX(KIND=2)} arguments.
7284 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7285 intrinsic, used to extract the real part of a complex expression
7287 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7288 intrinsic, used to extract the imaginary part of a complex expression
7291 @node Ugly Null Arguments
7292 @subsection Ugly Null Arguments
7293 @cindex trailing commas
7294 @cindex commas, trailing
7295 @cindex null arguments
7296 @cindex arguments, null
7298 The @samp{-fugly-comma} option enables use of a single trailing comma
7299 to mean ``pass an extra trailing null argument''
7300 in a list of actual arguments to an external procedure,
7301 and use of an empty list of arguments to such a procedure
7302 to mean ``pass a single null argument''.
7304 @cindex omitting arguments
7305 @cindex arguments, omitting
7306 (Null arguments often are used in some procedure-calling
7307 schemes to indicate omitted arguments.)
7309 For example, @samp{CALL FOO(,)} means ``pass
7310 two null arguments'', rather than ``pass one null argument''.
7311 Also, @samp{CALL BAR()} means ``pass one null argument''.
7313 This construct is considered ``ugly'' because it does not
7314 provide an elegant way to pass a single null argument
7315 that is syntactically distinct from passing no arguments.
7316 That is, this construct changes the meaning of code that
7317 makes no use of the construct.
7319 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7320 and @samp{I = JFUNC()} pass a single null argument, instead
7321 of passing no arguments as required by the Fortran 77 and
7324 @emph{Note:} Many systems gracefully allow the case
7325 where a procedure call passes one extra argument that the
7326 called procedure does not expect.
7328 So, in practice, there might be no difference in
7329 the behavior of a program that does @samp{CALL FOO()}
7330 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7331 in force as compared to its behavior when compiled
7332 with the default, @samp{-fno-ugly-comma}, in force,
7333 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7334 arguments to be passed.
7336 @node Ugly Conversion of Initializers
7337 @subsection Ugly Conversion of Initializers
7339 The constructs disabled by @samp{-fno-ugly-init} are:
7342 @cindex Hollerith constants
7343 @cindex constants, Hollerith
7345 Use of Hollerith and typeless constants in contexts where they set
7346 initial (compile-time) values for variables, arrays, and named
7347 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7348 type-declaration statements specifying initial values.
7350 Here are some sample initializations that are disabled by the
7351 @samp{-fno-ugly-init} option:
7354 PARAMETER (VAL='9A304FFE'X)
7355 REAL*8 STRING/8HOUTPUT00/
7359 @cindex character constants
7360 @cindex constants, character
7362 In the same contexts as above, use of character constants to initialize
7363 numeric items and vice versa (one constant per item).
7365 Here are more sample initializations that are disabled by the
7366 @samp{-fno-ugly-init} option:
7371 PARAMETER (IA = 'A')
7372 PARAMETER (BELL = 7)
7376 Use of Hollerith and typeless constants on the right-hand side
7377 of assignment statements to numeric types, and in other
7378 contexts (such as passing arguments in invocations of
7379 intrinsic procedures and statement functions) that
7380 are treated as assignments to known types (the dummy
7381 arguments, in these cases).
7383 Here are sample statements that are disabled by the
7384 @samp{-fno-ugly-init} option:
7388 PRINT *, IMAX0(2HAB, 2HBA)
7392 The above constructs, when used,
7393 can tend to result in non-portable code.
7394 But, they are widely used in existing Fortran code in ways
7395 that often are quite portable.
7396 Therefore, they are enabled by default.
7398 @node Ugly Integer Conversions
7399 @subsection Ugly Integer Conversions
7401 The constructs enabled via @samp{-fugly-logint} are:
7405 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7407 context (typically implies nonportable dependencies on how a
7408 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7411 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7415 The above constructs are disabled by default because use
7416 of them tends to lead to non-portable code.
7417 Even existing Fortran code that uses that often turns out
7418 to be non-portable, if not outright buggy.
7420 Some of this is due to differences among implementations as
7421 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7422 @code{INTEGER} values---Fortran code that assumes a particular
7423 coding is likely to use one of the above constructs, and is
7424 also likely to not work correctly on implementations using
7425 different encodings.
7427 @xref{Equivalence Versus Equality}, for more information.
7429 @node Ugly Assigned Labels
7430 @subsection Ugly Assigned Labels
7431 @cindex ASSIGN statement
7432 @cindex statements, ASSIGN
7433 @cindex assigned labels
7436 The @samp{-fugly-assign} option forces @code{g77} to use the
7437 same storage for assigned labels as it would for a normal
7438 assignment to the same variable.
7440 For example, consider the following code fragment:
7448 Normally, for portability and improved diagnostics, @code{g77}
7449 reserves distinct storage for a ``sibling'' of @samp{I}, used
7450 only for @code{ASSIGN} statements to that variable (along with
7451 the corresponding assigned-@code{GOTO} and assigned-@samp{FORMAT}-I/O
7452 statements that reference the variable).
7454 However, some code (that violates the ANSI FORTRAN 77 standard)
7455 attempts to copy assigned labels among variables involved with
7456 @code{ASSIGN} statements, as in:
7467 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7468 is specified on the command-line, ensuring that the value of @code{I}
7469 referenced in the second line is whatever value @code{g77} uses
7470 to designate statement label @samp{10}, so the value may be
7471 copied into the @samp{ISTATE} array, later retrieved into a
7472 variable of the appropriate type (@samp{J}), and used as the target of
7473 an assigned-@code{GOTO} statement.
7475 @emph{Note:} To avoid subtle program bugs,
7476 when @samp{-fugly-assign} is specified,
7477 @code{g77} requires the type of variables
7478 specified in assigned-label contexts
7479 @emph{must} be the same type returned by @code{%LOC()}.
7480 On many systems, this type is effectively the same
7481 as @code{INTEGER(KIND=1)}, while, on others, it is
7482 effectively the same as @code{INTEGER(KIND=2)}.
7484 Do @emph{not} depend on @code{g77} actually writing valid pointers
7485 to these variables, however.
7486 While @code{g77} currently chooses that implementation, it might
7487 be changed in the future.
7489 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7490 for implementation details on assigned-statement labels.
7493 @chapter The GNU Fortran Compiler
7495 The GNU Fortran compiler, @code{g77}, supports programs written
7496 in the GNU Fortran language and in some other dialects of Fortran.
7498 Some aspects of how @code{g77} works are universal regardless
7499 of dialect, and yet are not properly part of the GNU Fortran
7501 These are described below.
7503 @emph{Note: This portion of the documentation definitely needs a lot
7509 * Compiler Constants::
7510 * Compiler Intrinsics::
7513 @node Compiler Limits
7514 @section Compiler Limits
7515 @cindex limits, compiler
7516 @cindex compiler limits
7518 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7519 on lengths of identifiers, number of continuation lines, number of external
7520 symbols in a program, and so on.
7522 @cindex options, -Nl
7524 @cindex options, -Nx
7526 For example, some other Fortran compiler have an option
7527 (such as @samp{-Nl@var{x}}) to increase the limit on the
7528 number of continuation lines.
7529 Also, some Fortran compilation systems have an option
7530 (such as @samp{-Nx@var{x}}) to increase the limit on the
7531 number of external symbols.
7533 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7534 no equivalent options, since they do not impose arbitrary
7535 limits in these areas.
7537 @cindex rank, maximum
7538 @cindex maximum rank
7539 @cindex number of dimensions, maximum
7540 @cindex maximum number of dimensions
7541 @code{g77} does currently limit the number of dimensions in an array
7542 to the same degree as do the Fortran standards---seven (7).
7543 This restriction might well be lifted in a future version.
7545 @node Compiler Types
7546 @section Compiler Types
7547 @cindex types, of data
7550 Fortran implementations have a fair amount of freedom given them by the
7551 standard as far as how much storage space is used and how much precision
7552 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7553 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7554 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7555 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7556 the interpretation of @var{n} varies across compilers and target architectures.
7558 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7559 and @code{REAL(KIND=1)}
7560 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7561 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7562 Further, it requires that @code{COMPLEX(KIND=1)}
7563 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7564 storage-associated (such as via @code{EQUIVALENCE})
7565 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7566 corresponds to the real element and @samp{R(2)} to the imaginary
7567 element of the @code{COMPLEX(KIND=1)} variable.
7569 (Few requirements as to precision or ranges of any of these are
7570 placed on the implementation, nor is the relationship of storage sizes of
7571 these types to the @code{CHARACTER} type specified, by the standard.)
7573 @code{g77} follows the above requirements, warning when compiling
7574 a program requires placement of items in memory that contradict the
7575 requirements of the target architecture.
7576 (For example, a program can require placement of a @code{REAL(KIND=2)}
7577 on a boundary that is not an even multiple of its size, but still an
7578 even multiple of the size of a @code{REAL(KIND=1)} variable.
7579 On some target architectures, using the canonical
7580 mapping of Fortran types to underlying architectural types, such
7581 placement is prohibited by the machine definition or
7582 the Application Binary Interface (ABI) in force for
7583 the configuration defined for building @code{gcc} and @code{g77}.
7584 @code{g77} warns about such
7585 situations when it encounters them.)
7587 @code{g77} follows consistent rules for configuring the mapping between Fortran
7588 types, including the @samp{*@var{n}} notation, and the underlying architectural
7589 types as accessed by a similarly-configured applicable version of the
7590 @code{gcc} compiler.
7591 These rules offer a widely portable, consistent Fortran/C
7592 environment, although they might well conflict with the expectations of
7593 users of Fortran compilers designed and written for particular
7596 These rules are based on the configuration that is in force for the
7597 version of @code{gcc} built in the same release as @code{g77} (and
7598 which was therefore used to build both the @code{g77} compiler
7599 components and the @code{libg2c} run-time library):
7602 @cindex REAL(KIND=1) type
7603 @cindex types, REAL(KIND=1)
7605 Same as @code{float} type.
7607 @cindex REAL(KIND=2) type
7608 @cindex types, REAL(KIND=2)
7610 Same as whatever floating-point type that is twice the size
7611 of a @code{float}---usually, this is a @code{double}.
7613 @cindex INTEGER(KIND=1) type
7614 @cindex types, INTEGER(KIND=1)
7615 @item INTEGER(KIND=1)
7616 Same as an integral type that is occupies the same amount
7617 of memory storage as @code{float}---usually, this is either
7618 an @code{int} or a @code{long int}.
7620 @cindex LOGICAL(KIND=1) type
7621 @cindex types, LOGICAL(KIND=1)
7622 @item LOGICAL(KIND=1)
7623 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7625 @cindex INTEGER(KIND=2) type
7626 @cindex types, INTEGER(KIND=2)
7627 @item INTEGER(KIND=2)
7628 Twice the size, and usually nearly twice the range,
7629 as @code{INTEGER(KIND=1)}---usually, this is either
7630 a @code{long int} or a @code{long long int}.
7632 @cindex LOGICAL(KIND=2) type
7633 @cindex types, LOGICAL(KIND=2)
7634 @item LOGICAL(KIND=2)
7635 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7637 @cindex INTEGER(KIND=3) type
7638 @cindex types, INTEGER(KIND=3)
7639 @item INTEGER(KIND=3)
7640 Same @code{gcc} type as signed @code{char}.
7642 @cindex LOGICAL(KIND=3) type
7643 @cindex types, LOGICAL(KIND=3)
7644 @item LOGICAL(KIND=3)
7645 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7647 @cindex INTEGER(KIND=6) type
7648 @cindex types, INTEGER(KIND=6)
7649 @item INTEGER(KIND=6)
7650 Twice the size, and usually nearly twice the range,
7651 as @code{INTEGER(KIND=3)}---usually, this is
7654 @cindex LOGICAL(KIND=6) type
7655 @cindex types, LOGICAL(KIND=6)
7656 @item LOGICAL(KIND=6)
7657 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7659 @cindex COMPLEX(KIND=1) type
7660 @cindex types, COMPLEX(KIND=1)
7661 @item COMPLEX(KIND=1)
7662 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7663 one for the imaginary part).
7665 @cindex COMPLEX(KIND=2) type
7666 @cindex types, COMPLEX(KIND=2)
7667 @item COMPLEX(KIND=2)
7668 Two @code{REAL(KIND=2)} scalars.
7670 @cindex *@var{n} notation
7671 @item @var{numeric-type}*@var{n}
7672 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7673 Same as whatever @code{gcc} type occupies @var{n} times the storage
7674 space of a @code{gcc} @code{char} item.
7676 @cindex DOUBLE PRECISION type
7677 @cindex types, DOUBLE PRECISION
7678 @item DOUBLE PRECISION
7679 Same as @code{REAL(KIND=2)}.
7681 @cindex DOUBLE COMPLEX type
7682 @cindex types, DOUBLE COMPLEX
7683 @item DOUBLE COMPLEX
7684 Same as @code{COMPLEX(KIND=2)}.
7687 Note that the above are proposed correspondences and might change
7688 in future versions of @code{g77}---avoid writing code depending
7691 Other types supported by @code{g77}
7692 are derived from gcc types such as @code{char}, @code{short},
7693 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7695 That is, whatever types @code{gcc} already supports, @code{g77} supports
7696 now or probably will support in a future version.
7697 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7698 apply to these types,
7699 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7700 assigned in a way that encourages clarity, consistency, and portability.
7702 @node Compiler Constants
7703 @section Compiler Constants
7705 @cindex types, constants
7707 @code{g77} strictly assigns types to @emph{all} constants not
7708 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7710 Many other Fortran compilers attempt to assign types to typed constants
7711 based on their context.
7712 This results in hard-to-find bugs, nonportable
7713 code, and is not in the spirit (though it strictly follows the letter)
7714 of the 77 and 90 standards.
7716 @code{g77} might offer, in a future release, explicit constructs by
7717 which a wider variety of typeless constants may be specified, and/or
7718 user-requested warnings indicating places where @code{g77} might differ
7719 from how other compilers assign types to constants.
7721 @xref{Context-Sensitive Constants}, for more information on this issue.
7723 @node Compiler Intrinsics
7724 @section Compiler Intrinsics
7726 @code{g77} offers an ever-widening set of intrinsics.
7727 Currently these all are procedures (functions and subroutines).
7729 Some of these intrinsics are unimplemented, but their names reserved
7730 to reduce future problems with existing code as they are implemented.
7731 Others are implemented as part of the GNU Fortran language, while
7732 yet others are provided for compatibility with other dialects of
7733 Fortran but are not part of the GNU Fortran language.
7735 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7736 a facility that is simply an extension of the intrinsic groups provided
7737 by the GNU Fortran language.
7740 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7741 * Other Intrinsics:: Intrinsics other than those in the GNU
7745 @node Intrinsic Groups
7746 @subsection Intrinsic Groups
7747 @cindex groups of intrinsics
7748 @cindex intrinsics, groups
7750 A given specific intrinsic belongs in one or more groups.
7751 Each group is deleted, disabled, hidden, or enabled
7752 by default or a command-line option.
7753 The meaning of each term follows.
7756 @cindex deleted intrinsics
7757 @cindex intrinsics, deleted
7759 No intrinsics are recognized as belonging to that group.
7761 @cindex disabled intrinsics
7762 @cindex intrinsics, disabled
7764 Intrinsics are recognized as belonging to the group, but
7765 references to them (other than via the @code{INTRINSIC} statement)
7766 are disallowed through that group.
7768 @cindex hidden intrinsics
7769 @cindex intrinsics, hidden
7771 Intrinsics in that group are recognized and enabled (if implemented)
7772 @emph{only} if the first mention of the actual name of an intrinsic
7773 in a program unit is in an @code{INTRINSIC} statement.
7775 @cindex enabled intrinsics
7776 @cindex intrinsics, enabled
7778 Intrinsics in that group are recognized and enabled (if implemented).
7781 The distinction between deleting and disabling a group is illustrated
7782 by the following example.
7783 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7784 If group @samp{FGR} is deleted, the following program unit will
7785 successfully compile, because @samp{FOO()} will be seen as a
7786 reference to an external function named @samp{FOO}:
7794 If group @samp{FGR} is disabled, compiling the above program will produce
7795 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7796 or, if properly invoked, it is not enabled.
7797 To change the above program so it references an external function @samp{FOO}
7798 instead of the disabled @samp{FOO} intrinsic,
7799 add the following line to the top:
7806 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7807 that group do not exist at all, whereas disabling it tells @code{g77} to
7808 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7810 Hiding a group is like enabling it, but the intrinsic must be first
7811 named in an @code{INTRINSIC} statement to be considered a reference to the
7812 intrinsic rather than to an external procedure.
7813 This might be the ``safest'' way to treat a new group of intrinsics
7815 code, because it allows the old code to be generally written as if
7816 those new intrinsics never existed, but to be changed to use them
7817 by inserting @code{INTRINSIC} statements in the appropriate places.
7818 However, it should be the goal of development to use @code{EXTERNAL}
7819 for all names of external procedures that might be intrinsic names.
7821 If an intrinsic is in more than one group, it is enabled if any of its
7822 containing groups are enabled; if not so enabled, it is hidden if
7823 any of its containing groups are hidden; if not so hidden, it is disabled
7824 if any of its containing groups are disabled; if not so disabled, it is
7826 This extra complication is necessary because some intrinsics,
7827 such as @code{IBITS}, belong to more than one group, and hence should be
7828 enabled if any of the groups to which they belong are enabled, and so
7833 @cindex intrinsics, groups of
7834 @cindex groups of intrinsics
7836 @cindex @code{badu77} intrinsics group
7838 UNIX intrinsics having inappropriate forms (usually functions that
7839 have intended side effects).
7841 @cindex @code{gnu} intrinsics group
7843 Intrinsics the GNU Fortran language supports that are extensions to
7844 the Fortran standards (77 and 90).
7846 @cindex @code{f2c} intrinsics group
7848 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
7850 @cindex @code{f90} intrinsics group
7852 Fortran 90 intrinsics.
7854 @cindex @code{mil} intrinsics group
7856 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
7858 @cindex @code{mil} intrinsics group
7860 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
7862 @cindex @code{mil} intrinsics group
7864 VAX/VMS FORTRAN (current as of v4) intrinsics.
7867 @node Other Intrinsics
7868 @subsection Other Intrinsics
7869 @cindex intrinsics, others
7870 @cindex other intrinsics
7872 @code{g77} supports intrinsics other than those in the GNU Fortran
7874 This set of intrinsics is described below.
7877 (Note that the empty lines appearing in the menu below
7878 are not intentional---they result from a bug in the
7879 @code{makeinfo} program.)
7882 @c The actual documentation for intrinsics comes from
7883 @c intdoc.texi, which in turn is automatically generated
7884 @c from the internal g77 tables in intrin.def _and_ the
7885 @c largely hand-written text in intdoc.h. So, if you want
7886 @c to change or add to existing documentation on intrinsics,
7887 @c you probably want to edit intdoc.h.
7899 @include intdoc.texi
7901 @node Other Compilers
7902 @chapter Other Compilers
7904 An individual Fortran source file can be compiled to
7905 an object (@file{*.o}) file instead of to the final
7907 This allows several portions of a program to be compiled
7908 at different times and linked together whenever a new
7909 version of the program is needed.
7910 However, it introduces the issue of @dfn{object compatibility}
7911 across the various object files (and libraries, or @file{*.a}
7912 files) that are linked together to produce any particular
7915 Object compatibility is an issue when combining, in one
7916 program, Fortran code compiled by more than one compiler
7917 (or more than one configuration of a compiler).
7919 disagree on how to transform the names of procedures, there
7920 will normally be errors when linking such programs.
7921 Worse, if the compilers agree on naming, but disagree on issues
7922 like how to pass parameters, return arguments, and lay out
7923 @code{COMMON} areas, the earliest detected errors might be the
7924 incorrect results produced by the program (and that assumes
7925 these errors are detected, which is not always the case).
7927 Normally, @code{g77} generates code that is
7928 object-compatible with code generated by a version of
7929 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
7930 to be generally compatible with @code{g77} as built by @code{gcc}.
7931 (Normally, @code{f2c} will, by default, conform to the appropriate
7932 configuration, but it is possible that older or perhaps even newer
7933 versions of @code{f2c}, or versions having certain configuration changes
7934 to @code{f2c} internals, will produce object files that are
7935 incompatible with @code{g77}.)
7937 For example, a Fortran string subroutine
7938 argument will become two arguments on the C side: a @code{char *}
7939 and an @code{int} length.
7941 Much of this compatibility results from the fact that
7942 @code{g77} uses the same run-time library,
7943 @code{libf2c}, used by @code{f2c},
7944 though @code{g77} gives its version the name @code{libg2c}
7945 so as to avoid conflicts when linking,
7946 installing them in the same directories,
7949 Other compilers might or might not generate code that
7950 is object-compatible with @code{libg2c} and current @code{g77},
7951 and some might offer such compatibility only when explicitly
7952 selected via a command-line option to the compiler.
7954 @emph{Note: This portion of the documentation definitely needs a lot
7958 * Dropping f2c Compatibility:: When speed is more important.
7959 * Compilers Other Than f2c:: Interoperation with code from other compilers.
7962 @node Dropping f2c Compatibility
7963 @section Dropping @code{f2c} Compatibility
7965 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
7966 some cases, faster code, by not needing to allow to the possibility
7967 of linking with code compiled by @code{f2c}.
7969 For example, this affects how @code{REAL(KIND=1)},
7970 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
7971 With @samp{-fno-f2c}, they are
7972 compiled as returning the appropriate @code{gcc} type
7973 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
7974 in many configurations).
7976 With @samp{-ff2c} in force, they
7977 are compiled differently (with perhaps slower run-time performance)
7978 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
7979 C as an intermediate language---@code{REAL(KIND=1)} functions
7980 return C's @code{double} type, while @code{COMPLEX} functions return
7981 @code{void} and use an extra argument pointing to a place for the functions to
7982 return their values.
7984 It is possible that, in some cases, leaving @samp{-ff2c} in force
7985 might produce faster code than using @samp{-fno-f2c}.
7986 Feel free to experiment, but remember to experiment with changing the way
7987 @emph{entire programs and their Fortran libraries are compiled} at
7988 a time, since this sort of experimentation affects the interface
7989 of code generated for a Fortran source file---that is, it affects
7990 object compatibility.
7992 Note that @code{f2c} compatibility is a fairly static target to achieve,
7993 though not necessarily perfectly so, since, like @code{g77}, it is
7994 still being improved.
7995 However, specifying @samp{-fno-f2c} causes @code{g77}
7996 to generate code that will probably be incompatible with code
7997 generated by future versions of @code{g77} when the same option
7999 You should make sure you are always able to recompile complete
8000 programs from source code when upgrading to new versions of @code{g77}
8001 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8003 Therefore, if you are using @code{g77} to compile libraries and other
8004 object files for possible future use and you don't want to require
8005 recompilation for future use with subsequent versions of @code{g77},
8006 you might want to stick with @code{f2c} compatibility for now, and
8007 carefully watch for any announcements about changes to the
8008 @code{f2c}/@code{libf2c} interface that might affect existing programs
8009 (thus requiring recompilation).
8011 It is probable that a future version of @code{g77} will not,
8012 by default, generate object files compatible with @code{f2c},
8013 and that version probably would no longer use @code{libf2c}.
8014 If you expect to depend on this compatibility in the
8015 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8016 all of the applicable code.
8017 This should cause future versions of @code{g77} either to produce
8018 compatible code (at the expense of the availability of some features and
8019 performance), or at the very least, to produce diagnostics.
8021 (The library @code{g77} produces will no longer be named @file{libg2c}
8022 when it is no longer generally compatible with @file{libf2c}.
8023 It will likely be referred to, and, if installed as a distinct
8024 library, named @code{libg77}, or some other as-yet-unused name.)
8026 @node Compilers Other Than f2c
8027 @section Compilers Other Than @code{f2c}
8029 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8030 code compiled by @code{g77} is not expected to work
8031 well with code compiled by the native compiler.
8032 (This is true for @code{f2c}-compiled objects as well.)
8033 Libraries compiled with the native compiler probably will have
8034 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8036 Reasons for such incompatibilities include:
8040 There might be differences in the way names of Fortran procedures
8041 are translated for use in the system's object-file format.
8042 For example, the statement @samp{CALL FOO} might be compiled
8043 by @code{g77} to call a procedure the linker @code{ld} sees
8044 given the name @samp{_foo_}, while the apparently corresponding
8045 statement @samp{SUBROUTINE FOO} might be compiled by the
8046 native compiler to define the linker-visible name @samp{_foo},
8047 or @samp{_FOO_}, and so on.
8050 There might be subtle type mismatches which cause subroutine arguments
8051 and function return values to get corrupted.
8053 This is why simply getting @code{g77} to
8054 transform procedure names the same way a native
8055 compiler does is not usually a good idea---unless
8056 some effort has been made to ensure that, aside
8057 from the way the two compilers transform procedure
8058 names, everything else about the way they generate
8059 code for procedure interfaces is identical.
8063 use libraries of private I/O routines which will not be available
8064 at link time unless you have the native compiler---and you would
8065 have to explicitly ask for them.
8067 For example, on the Sun you
8068 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8072 @node Other Languages
8073 @chapter Other Languages
8075 @emph{Note: This portion of the documentation definitely needs a lot
8079 * Interoperating with C and C++::
8082 @node Interoperating with C and C++
8083 @section Tools and advice for interoperating with C and C++
8085 @cindex C, linking with
8086 @cindex C++, linking with
8087 @cindex linking with C
8088 The following discussion assumes that you are running @code{g77} in @code{f2c}
8089 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8091 advice about quick and simple techniques for linking Fortran and C (or
8092 C++), the most common requirement.
8093 For the full story consult the
8094 description of code generation.
8095 @xref{Debugging and Interfacing}.
8097 When linking Fortran and C, it's usually best to use @code{g77} to do
8098 the linking so that the correct libraries are included (including the
8100 If you're linking with C++ you will want to add
8101 @samp{-lstdc++}, @samp{-lg++} or whatever.
8102 If you need to use another
8103 driver program (or @code{ld} directly),
8104 you can find out what linkage
8105 options @code{g77} passes by running @samp{g77 -v}.
8108 * C Interfacing Tools::
8109 * C Access to Type Information::
8110 * f2c Skeletons and Prototypes::
8111 * C++ Considerations::
8115 @node C Interfacing Tools
8116 @subsection C Interfacing Tools
8120 Even if you don't actually use it as a compiler, @samp{f2c} from
8121 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8122 interfacing (linking) Fortran and C@.
8123 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8125 To use @code{f2c} for this purpose you only need retrieve and
8126 build the @file{src} directory from the distribution, consult the
8127 @file{README} instructions there for machine-specifics, and install the
8128 @code{f2c} program on your path.
8130 Something else that might be useful is @samp{cfortran.h} from
8131 @uref{ftp://zebra/desy.de/cfortran}.
8132 This is a fairly general tool which
8133 can be used to generate interfaces for calling in both directions
8134 between Fortran and C@.
8135 It can be used in @code{f2c} mode with
8136 @code{g77}---consult its documentation for details.
8138 @node C Access to Type Information
8139 @subsection Accessing Type Information in C
8141 @cindex types, Fortran/C
8142 Generally, C code written to link with
8143 @code{g77} code---calling and/or being
8144 called from Fortran---should @samp{#include <g2c.h>} to define the C
8145 versions of the Fortran types.
8146 Don't assume Fortran @code{INTEGER} types
8147 correspond to C @samp{int}s, for instance; instead, declare them as
8148 @code{integer}, a type defined by @file{g2c.h}.
8149 @file{g2c.h} is installed where @code{gcc} will find it by
8150 default, assuming you use a copy of @code{gcc} compatible with
8151 @code{g77}, probably built at the same time as @code{g77}.
8153 @node f2c Skeletons and Prototypes
8154 @subsection Generating Skeletons and Prototypes with @code{f2c}
8157 @cindex -fno-second-underscore
8158 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8159 interface with an existing library---is to write a file (named, for
8160 example, @file{fred.f}) of dummy Fortran
8161 skeletons comprising just the declaration of the routine(s) and dummy
8162 arguments plus @samp{END} statements.
8163 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8164 into which you can edit
8165 useful code, confident the calling sequence is correct, at least.
8166 (There are some errors otherwise commonly made in generating C
8167 interfaces with @code{f2c} conventions,
8168 such as not using @code{doublereal}
8169 as the return type of a @code{REAL} @code{FUNCTION}.)
8172 @code{f2c} also can help with calling Fortran from C, using its
8173 @samp{-P} option to generate C prototypes appropriate for calling the
8174 Fortran.@footnote{The files generated like this can also be used for
8175 inter-unit consistency checking of dummy and actual arguments, although
8176 the @samp{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8177 or @uref{ftp://ftp.dsm.fordham.edu} is
8178 probably better for this purpose.}
8179 If the Fortran code containing any
8180 routines to be called from C is in file @file{joe.f}, use the command
8181 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8182 prototype information.
8183 @code{#include} this in the C which has to call
8184 the Fortran routines to make sure you get it right.
8186 @xref{Arrays,,Arrays (DIMENSION}, for information on the differences
8187 between the way Fortran (including compilers like @code{g77}) and
8190 @node C++ Considerations
8191 @subsection C++ Considerations
8194 @code{f2c} can be used to generate suitable code for compilation with a
8195 C++ system using the @samp{-C++} option.
8196 The important thing about linking @code{g77}-compiled
8197 code with C++ is that the prototypes for the @code{g77}
8198 routines must specify C linkage to avoid name mangling.
8199 So, use an @samp{extern "C"} declaration.
8200 @code{f2c}'s @samp{-C++} option will take care
8201 of this when generating skeletons or prototype files as above, and also
8202 avoid clashes with C++ reserved words in addition to those in C@.
8205 @subsection Startup Code
8207 @cindex startup code
8208 @cindex runtime initialization
8209 @cindex initialization, runtime
8210 Unlike with some runtime systems,
8211 it shouldn't be necessary
8212 (unless there are bugs)
8213 to use a Fortran main program unit to ensure the
8214 runtime---specifically the I/O system---is initialized.
8216 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8217 either the @code{main} routine from the @file{libg2c} library must be used,
8218 or the @code{f_setarg} routine
8219 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8220 must be called with the appropriate @code{argc} and @code{argv} arguments
8221 prior to the program calling @code{GETARG} or @code{IARGC}.
8223 To provide more flexibility for mixed-language programming
8224 involving @code{g77} while allowing for shared libraries,
8225 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8226 @code{g77}'s @code{main} routine in @code{libg2c}
8227 does the following, in order:
8231 Calls @code{f_setarg}
8232 with the incoming @code{argc} and @code{argv} arguments,
8233 in the same order as for @code{main} itself.
8235 This sets up the command-line environment
8236 for @code{GETARG} and @code{IARGC}.
8239 Calls @code{f_setsig} (with no arguments).
8241 This sets up the signaling and exception environment.
8244 Calls @code{f_init} (with no arguments).
8246 This initializes the I/O environment,
8247 though that should not be necessary,
8248 as all I/O functions in @code{libf2c}
8249 are believed to call @code{f_init} automatically,
8252 (A future version of @code{g77} might skip this explicit step,
8253 to speed up normal exit of a program.)
8256 Arranges for @code{f_exit} to be called (with no arguments)
8257 when the program exits.
8259 This ensures that the I/O environment is properly shut down
8260 before the program exits normally.
8261 Otherwise, output buffers might not be fully flushed,
8262 scratch files might not be deleted, and so on.
8264 The simple way @code{main} does this is
8265 to call @code{f_exit} itself after calling
8266 @code{MAIN__} (in the next step).
8268 However, this does not catch the cases where the program
8269 might call @code{exit} directly,
8270 instead of using the @code{EXIT} intrinsic
8271 (implemented as @code{exit_} in @code{libf2c}).
8273 So, @code{main} attempts to use
8274 the operating environment's @code{onexit} or @code{atexit}
8275 facility, if available,
8276 to cause @code{f_exit} to be called automatically
8277 upon any invocation of @code{exit}.
8280 Calls @code{MAIN__} (with no arguments).
8282 This starts executing the Fortran main program unit for
8284 (Both @code{g77} and @code{f2c} currently compile a main
8285 program unit so that its global name is @code{MAIN__}.)
8288 If no @code{onexit} or @code{atexit} is provided by the system,
8289 calls @code{f_exit}.
8292 Calls @code{exit} with a zero argument,
8293 to signal a successful program termination.
8296 Returns a zero value to the caller,
8297 to signal a successful program termination,
8298 in case @code{exit} doesn't exit on the system.
8301 All of the above names are C @code{extern} names,
8304 When using the @code{main} procedure provided by @code{g77}
8305 without a Fortran main program unit,
8306 you need to provide @code{MAIN__}
8307 as the entry point for your C code.
8308 (Make sure you link the object file that defines that
8309 entry point with the rest of your program.)
8311 To provide your own @code{main} procedure
8312 in place of @code{g77}'s,
8313 make sure you specify the object file defining that procedure
8314 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8315 Since the @samp{-lg2c} option is implicitly provided,
8316 this is usually straightforward.
8317 (Use the @samp{--verbose} option to see how and where
8318 @code{g77} implicitly adds @samp{-lg2c} in a command line
8319 that will link the program.
8320 Feel free to specify @samp{-lg2c} explicitly,
8323 However, when providing your own @code{main},
8324 make sure you perform the appropriate tasks in the
8326 For example, if your @code{main} does not call @code{f_setarg},
8327 make sure the rest of your application does not call
8328 @code{GETARG} or @code{IARGC}.
8330 And, if your @code{main} fails to ensure that @code{f_exit}
8331 is called upon program exit,
8332 some files might end up incompletely written,
8333 some scratch files might be left lying around,
8334 and some existing files being written might be left
8335 with old data not properly truncated at the end.
8337 Note that, generally, the @code{g77} operating environment
8338 does not depend on a procedure named @code{MAIN__} actually
8339 being called prior to any other @code{g77}-compiled code.
8340 That is, @code{MAIN__} does not, itself,
8341 set up any important operating-environment characteristics
8342 upon which other code might depend.
8343 This might change in future versions of @code{g77},
8344 with appropriate notification in the release notes.
8346 For more information, consult the source code for the above routines.
8347 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8348 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8350 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8351 uses to open-code (inline) references to @code{IARGC}.
8353 @include g77install.texi
8355 @node Debugging and Interfacing
8356 @chapter Debugging and Interfacing
8359 @cindex calling C routines
8360 @cindex C routines calling Fortran
8361 @cindex f2c compatibility
8363 GNU Fortran currently generates code that is object-compatible with
8364 the @code{f2c} converter.
8365 Also, it avoids limitations in the current GBE, such as the
8366 inability to generate a procedure with
8367 multiple entry points, by generating code that is structured
8368 differently (in terms of procedure names, scopes, arguments, and
8369 so on) than might be expected.
8371 As a result, writing code in other languages that calls on, is
8372 called by, or shares in-memory data with @code{g77}-compiled code generally
8373 requires some understanding of the way @code{g77} compiles code for
8376 Similarly, using a debugger to debug @code{g77}-compiled
8377 code, even if that debugger supports native Fortran debugging, generally
8378 requires this sort of information.
8380 This section describes some of the basic information on how
8381 @code{g77} compiles code for constructs involving interfaces to other
8382 languages and to debuggers.
8384 @emph{Caution:} Much or all of this information pertains to only the current
8385 release of @code{g77}, sometimes even to using certain compiler options
8386 with @code{g77} (such as @samp{-fno-f2c}).
8387 Do not write code that depends on this
8388 information without clearly marking said code as nonportable and
8389 subject to review for every new release of @code{g77}.
8391 is provided primarily to make debugging of code generated by this
8392 particular release of @code{g77} easier for the user, and partly to make
8393 writing (generally nonportable) interface code easier.
8395 activities require tracking changes in new version of @code{g77} as they
8396 are installed, because new versions can change the behaviors
8397 described in this section.
8400 * Main Program Unit:: How @code{g77} compiles a main program unit.
8401 * Procedures:: How @code{g77} constructs parameter lists
8403 * Functions:: Functions returning floating-point or character data.
8404 * Names:: Naming of user-defined variables, procedures, etc.
8405 * Common Blocks:: Accessing common variables while debugging.
8406 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8407 * Complex Variables:: How @code{g77} performs complex arithmetic.
8408 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8409 * Adjustable Arrays:: Special consideration for adjustable arrays.
8410 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8411 * Alternate Returns:: How @code{g77} handles alternate returns.
8412 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8413 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8416 @node Main Program Unit
8417 @section Main Program Unit (PROGRAM)
8418 @cindex PROGRAM statement
8419 @cindex statements, PROGRAM
8421 When @code{g77} compiles a main program unit, it gives it the public
8422 procedure name @samp{MAIN__}.
8423 The @code{libg2c} library has the actual @code{main()} procedure
8424 as is typical of C-based environments, and
8425 it is this procedure that performs some initial start-up
8426 activity and then calls @samp{MAIN__}.
8428 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8429 include a main program unit written in Fortran in your program---it
8430 can be written in C or some other language.
8431 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8432 includes a bug fix for @code{libg2c} that solved a problem with using the
8433 @code{OPEN} statement as the first Fortran I/O activity in a program
8434 without a Fortran main program unit.
8436 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8437 your main program unit---that is, if you intend to compile a @code{main()}
8438 procedure using some other language---you should carefully
8439 examine the code for @code{main()} in @code{libg2c}, found in the source
8440 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8441 might need to be done by your @code{main()} in order to provide the
8442 Fortran environment your Fortran code is expecting.
8444 @cindex IARGC() intrinsic
8445 @cindex intrinsics, IARGC()
8446 @cindex GETARG() intrinsic
8447 @cindex intrinsics, GETARG()
8448 For example, @code{libg2c}'s @code{main()} sets up the information used by
8449 the @code{IARGC} and @code{GETARG} intrinsics.
8450 Bypassing @code{libg2c}'s @code{main()}
8451 without providing a substitute for this activity would mean
8452 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8456 @cindex main program unit, debugging
8460 When debugging, one implication of the fact that @code{main()}, which
8461 is the place where the debugged program ``starts'' from the
8462 debugger's point of view, is in @code{libg2c} is that you won't be
8463 starting your Fortran program at a point you recognize as your
8466 The standard way to get around this problem is to set a break
8467 point (a one-time, or temporary, break point will do) at
8468 the entrance to @samp{MAIN__}, and then run the program.
8469 A convenient way to do so is to add the @code{gdb} command
8476 to the file @file{.gdbinit} in the directory in which you're debugging
8479 After doing this, the debugger will see the current execution
8480 point of the program as at the beginning of the main program
8481 unit of your program.
8483 Of course, if you really want to set a break point at some
8484 other place in your program and just start the program
8485 running, without first breaking at @samp{MAIN__},
8486 that should work fine.
8489 @section Procedures (SUBROUTINE and FUNCTION)
8491 @cindex SUBROUTINE statement
8492 @cindex statements, SUBROUTINE
8493 @cindex FUNCTION statement
8494 @cindex statements, FUNCTION
8495 @cindex signature of procedures
8497 Currently, @code{g77} passes arguments via reference---specifically,
8498 by passing a pointer to the location in memory of a variable, array,
8499 array element, a temporary location that holds the result of evaluating an
8500 expression, or a temporary or permanent location that holds the value
8503 Procedures that accept @code{CHARACTER} arguments are implemented by
8504 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8506 The first argument occupies the expected position in the
8507 argument list and has the user-specified name.
8509 is a pointer to an array of characters, passed by the caller.
8511 The second argument is appended to the end of the user-specified
8512 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8513 is the user-specified name.
8514 This argument is of the C type @code{ftnlen}
8515 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8516 is the number of characters the caller has allocated in the
8517 array pointed to by the first argument.
8519 A procedure will ignore the length argument if @samp{X} is not declared
8520 @code{CHARACTER*(*)}, because for other declarations, it knows the
8522 Not all callers necessarily ``know'' this, however, which
8523 is why they all pass the extra argument.
8525 The contents of the @code{CHARACTER} argument are specified by the
8526 address passed in the first argument (named after it).
8527 The procedure can read or write these contents as appropriate.
8529 When more than one @code{CHARACTER} argument is present in the argument
8530 list, the length arguments are appended in the order
8531 the original arguments appear.
8532 So @samp{CALL FOO('HI','THERE')} is implemented in
8533 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8534 does not provide the trailing null bytes on the constant
8535 strings (@code{f2c} does provide them, but they are unnecessary in
8536 a Fortran environment, and you should not expect them to be
8539 Note that the above information applies to @code{CHARACTER} variables and
8540 arrays @strong{only}.
8541 It does @strong{not} apply to external @code{CHARACTER}
8542 functions or to intrinsic @code{CHARACTER} functions.
8543 That is, no second length argument is passed to @samp{FOO} in this case:
8552 Nor does @samp{FOO} expect such an argument in this case:
8560 Because of this implementation detail, if a program has a bug
8561 such that there is disagreement as to whether an argument is
8562 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8563 symptoms might appear.
8566 @section Functions (FUNCTION and RETURN)
8568 @cindex FUNCTION statement
8569 @cindex statements, FUNCTION
8570 @cindex RETURN statement
8571 @cindex statements, RETURN
8572 @cindex return type of functions
8574 @code{g77} handles in a special way functions that return the following
8586 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8587 returning @code{void})
8588 with two arguments prepended: @samp{__g77_result}, which the caller passes
8589 as a pointer to a @code{char} array expected to hold the return value,
8590 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8591 specifying the length of the return value as declared in the calling
8593 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8594 to determine the size of the array that @samp{__g77_result} points to;
8595 otherwise, it ignores that argument.
8597 For @code{COMPLEX}, when @samp{-ff2c} is in
8598 force, @code{g77} implements
8599 a subroutine with one argument prepended: @samp{__g77_result}, which the
8600 caller passes as a pointer to a variable of the type of the function.
8601 The called function writes the return value into this variable instead
8602 of returning it as a function value.
8603 When @samp{-fno-f2c} is in force,
8604 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8605 @samp{__complex__ float} or @samp{__complex__ double} function
8606 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8607 returning the result of the function in the same way as @code{gcc} would.
8609 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8610 a function that actually returns @code{REAL(KIND=2)} (typically
8611 C's @code{double} type).
8612 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8613 functions return @code{float}.
8617 @cindex symbol names
8618 @cindex transformation of symbol names
8620 Fortran permits each implementation to decide how to represent
8621 names as far as how they're seen in other contexts, such as debuggers
8622 and when interfacing to other languages, and especially as far
8623 as how casing is handled.
8625 External names---names of entities that are public, or ``accessible'',
8626 to all modules in a program---normally have an underscore (@samp{_})
8627 appended by @code{g77},
8628 to generate code that is compatible with @code{f2c}.
8629 External names include names of Fortran things like common blocks,
8630 external procedures (subroutines and functions, but not including
8631 statement functions, which are internal procedures), and entry point
8634 However, use of the @samp{-fno-underscoring} option
8635 disables this kind of transformation of external names (though inhibiting
8636 the transformation certainly improves the chances of colliding with
8637 incompatible externals written in other languages---but that
8638 might be intentional.
8640 @cindex -fno-underscoring option
8641 @cindex options, -fno-underscoring
8642 @cindex -fno-second-underscore option
8643 @cindex options, -fno-underscoring
8644 When @samp{-funderscoring} is in force, any name (external or local)
8645 that already has at least one underscore in it is
8646 implemented by @code{g77} by appending two underscores.
8647 (This second underscore can be disabled via the
8648 @samp{-fno-second-underscore} option.)
8649 External names are changed this way for @code{f2c} compatibility.
8650 Local names are changed this way to avoid collisions with external names
8651 that are different in the source code---@code{f2c} does the same thing, but
8652 there's no compatibility issue there except for user expectations while
8663 Here, a user would, in the debugger, refer to this variable using the
8664 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8665 as described below).
8666 (We hope to improve @code{g77} in this regard in the future---don't
8667 write scripts depending on this behavior!
8668 Also, consider experimenting with the @samp{-fno-underscoring}
8669 option to try out debugging without having to massage names by
8672 @code{g77} provides a number of command-line options that allow the user
8673 to control how case mapping is handled for source files.
8674 The default is the traditional UNIX model for Fortran compilers---names
8675 are mapped to lower case.
8676 Other command-line options can be specified to map names to upper
8677 case, or to leave them exactly as written in the source file.
8686 Here, it is normally the case that the variable assigned will be named
8688 This would be the name to enter when using a debugger to
8689 access the variable.
8691 However, depending on the command-line options specified, the
8692 name implemented by @code{g77} might instead be @samp{FOO} or even
8693 @samp{Foo}, thus affecting how debugging is done.
8702 This would normally call a procedure that, if it were in a separate C program,
8703 be defined starting with the line:
8710 However, @code{g77} command-line options could be used to change the casing
8711 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8712 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8713 could be used to inhibit the appending of the underscore to the name.
8716 @section Common Blocks (COMMON)
8717 @cindex common blocks
8718 @cindex COMMON statement
8719 @cindex statements, COMMON
8721 @code{g77} names and lays out @code{COMMON} areas
8722 the same way @code{f2c} does,
8723 for compatibility with @code{f2c}.
8725 Currently, @code{g77} does not emit ``true'' debugging information for
8726 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8728 (As of Version 0.5.19, @code{g77} emits debugging information for such
8729 members in the form of a constant string specifying the base name of
8730 the aggregate area and the offset of the member in bytes from the start
8732 Use the @samp{-fdebug-kludge} option to enable this behavior.
8733 In @code{gdb}, use @samp{set language c} before printing the value
8734 of the member, then @samp{set language fortran} to restore the default
8735 language, since @code{gdb} doesn't provide a way to print a readable
8736 version of a character string in Fortran language mode.
8738 This kludge will be removed in a future version of @code{g77} that,
8739 in conjunction with a contemporary version of @code{gdb},
8740 properly supports Fortran-language debugging, including access
8741 to members of @code{COMMON} areas.)
8743 @xref{Code Gen Options,,Options for Code Generation Conventions},
8744 for information on the @samp{-fdebug-kludge} option.
8746 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8747 type is an array of the C @code{char} data type.
8749 So, when debugging, you must know the offset into a @code{COMMON} area
8750 for a particular item in that area, and you have to take into
8751 account the appropriate multiplier for the respective sizes
8752 of the types (as declared in your code) for the items preceding
8753 the item in question as compared to the size of the @code{char} type.
8755 For example, using default implicit typing, the statement
8758 COMMON I(15), R(20), T
8762 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8763 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8764 and @samp{T} at @samp{_BLNK__[140]}.
8765 (This is assuming that the target machine for
8766 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8769 @node Local Equivalence Areas
8770 @section Local Equivalence Areas (EQUIVALENCE)
8771 @cindex equivalence areas
8772 @cindex local equivalence areas
8773 @cindex EQUIVALENCE statement
8774 @cindex statements, EQUIVALENCE
8776 @code{g77} treats storage-associated areas involving a @code{COMMON}
8777 block as explained in the section on common blocks.
8779 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8780 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8781 listed in a @code{COMMON} statement.
8783 Currently, @code{g77} does not emit ``true'' debugging information for
8784 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8786 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8787 members in the form of a constant string specifying the base name of
8788 the aggregate area and the offset of the member in bytes from the start
8790 Use the @samp{-fdebug-kludge} option to enable this behavior.
8791 In @code{gdb}, use @samp{set language c} before printing the value
8792 of the member, then @samp{set language fortran} to restore the default
8793 language, since @code{gdb} doesn't provide a way to print a readable
8794 version of a character string in Fortran language mode.
8796 This kludge will be removed in a future version of @code{g77} that,
8797 in conjunction with a contemporary version of @code{gdb},
8798 properly supports Fortran-language debugging, including access
8799 to members of @code{EQUIVALENCE} areas.)
8801 @xref{Code Gen Options,,Options for Code Generation Conventions},
8802 for information on the @samp{-fdebug-kludge} option.
8804 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8805 type is an array of the C @code{char} data type.
8807 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8808 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8810 If more than one such item is placed at the beginning, @var{x} is
8811 the name that sorts to the top in an alphabetical sort of the list of
8814 When debugging, you must therefore access members of @code{EQUIVALENCE}
8815 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8816 array section with the appropriate offset.
8817 See the explanation of debugging @code{COMMON} blocks
8818 for info applicable to debugging local @code{EQUIVALENCE} areas.
8820 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8821 for @var{x} using a different method when more than one name was
8822 in the list of names of entities placed at the beginning of the
8824 Though the documentation specified that the first name listed in
8825 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8826 in fact chose the name using a method that was so complicated,
8827 it seemed easier to change it to an alphabetical sort than to describe the
8828 previous method in the documentation.)
8830 @node Complex Variables
8831 @section Complex Variables (COMPLEX)
8832 @cindex complex variables
8833 @cindex imaginary part of complex
8834 @cindex COMPLEX statement
8835 @cindex statements, COMPLEX
8837 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8838 (and related intrinsics, constants, functions, and so on)
8840 makes direct debugging involving these types in Fortran
8841 language mode difficult.
8843 Essentially, @code{g77} implements these types using an
8844 internal construct similar to C's @code{struct}, at least
8845 as seen by the @code{gcc} back end.
8847 Currently, the back end, when outputting debugging info with
8848 the compiled code for the assembler to digest, does not detect
8849 these @code{struct} types as being substitutes for Fortran
8851 As a result, the Fortran language modes of debuggers such as
8852 @code{gdb} see these types as C @code{struct} types, which
8853 they might or might not support.
8855 Until this is fixed, switch to C language mode to work with
8856 entities of @code{COMPLEX} type and then switch back to Fortran language
8858 (In @code{gdb}, this is accomplished via @samp{set lang c} and
8859 either @samp{set lang fortran} or @samp{set lang auto}.)
8861 @emph{Note:} Compiling with the @samp{-fno-emulate-complex} option
8862 avoids the debugging problem, but is known to cause other problems
8863 like compiler crashes and generation of incorrect code, so it is
8867 @section Arrays (DIMENSION)
8868 @cindex DIMENSION statement
8869 @cindex statements, DIMENSION
8870 @cindex array ordering
8871 @cindex ordering, array
8872 @cindex column-major ordering
8873 @cindex row-major ordering
8876 Fortran uses ``column-major ordering'' in its arrays.
8877 This differs from other languages, such as C, which use ``row-major ordering''.
8878 The difference is that, with Fortran, array elements adjacent to
8879 each other in memory differ in the @emph{first} subscript instead of
8880 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
8881 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
8884 affects not only interfacing with and debugging Fortran code,
8885 it can greatly affect how code is designed and written, especially
8886 when code speed and size is a concern.
8888 Fortran also differs from C, a popular language for interfacing and
8889 to support directly in debuggers, in the way arrays are treated.
8890 In C, arrays are single-dimensional and have interesting relationships
8891 to pointers, neither of which is true for Fortran.
8892 As a result, dealing with Fortran arrays from within
8893 an environment limited to C concepts can be challenging.
8895 For example, accessing the array element @samp{A(5,10,20)} is easy enough
8896 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
8898 First, C would treat the A array as a single-dimension array.
8899 Second, C does not understand low bounds for arrays as does Fortran.
8900 Third, C assumes a low bound of zero (0), while Fortran defaults to a
8901 low bound of one (1) and can supports an arbitrary low bound.
8902 Therefore, calculations must be done
8903 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
8904 calculations require knowing the dimensions of @samp{A}.
8906 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
8907 @samp{A(5,10,20)} would be:
8912 + (20-0)*(11-2+1)*(21-1+1)
8917 So the C equivalent in this case would be @samp{a[4293]}.
8919 When using a debugger directly on Fortran code, the C equivalent
8920 might not work, because some debuggers cannot understand the notion
8921 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
8922 does inform the GBE that a multi-dimensional array (like @samp{A}
8923 in the above example) is really multi-dimensional, rather than a
8924 single-dimensional array, so at least the dimensionality of the array
8927 Debuggers that understand Fortran should have no trouble with
8928 non-zero low bounds, but for non-Fortran debuggers, especially
8929 C debuggers, the above example might have a C equivalent of
8931 This calculation is arrived at by eliminating the subtraction
8932 of the lower bound in the first parenthesized expression on each
8933 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
8934 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
8935 Actually, the implication of
8936 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
8937 but that @samp{a[20][10][5]} produces the equivalent of
8938 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
8940 Come to think of it, perhaps
8941 the behavior is due to the debugger internally compensating for
8942 the lower bounds by offsetting the base address of @samp{a}, leaving
8943 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
8944 its first element as identified by subscripts equal to the
8945 corresponding lower bounds).
8947 You know, maybe nobody really needs to use arrays.
8949 @node Adjustable Arrays
8950 @section Adjustable Arrays (DIMENSION)
8951 @cindex arrays, adjustable
8952 @cindex adjustable arrays
8953 @cindex arrays, automatic
8954 @cindex automatic arrays
8955 @cindex DIMENSION statement
8956 @cindex statements, DIMENSION
8957 @cindex dimensioning arrays
8958 @cindex arrays, dimensioning
8960 Adjustable and automatic arrays in Fortran require the implementation
8962 case, the @code{g77} compiler) to ``memorize'' the expressions that
8963 dimension the arrays each time the procedure is invoked.
8964 This is so that subsequent changes to variables used in those
8965 expressions, made during execution of the procedure, do not
8966 have any effect on the dimensions of those arrays.
8983 Here, the implementation should, when running the program, print something
8991 Note that this shows that while the value of @samp{N} was successfully
8992 changed, the size of the @samp{A} array remained at 5 elements.
8994 To support this, @code{g77} generates code that executes before any user
8995 code (and before the internally generated computed @code{GOTO} to handle
8996 alternate entry points, as described below) that evaluates each
8997 (nonconstant) expression in the list of subscripts for an
8998 array, and saves the result of each such evaluation to be used when
8999 determining the size of the array (instead of re-evaluating the
9002 So, in the above example, when @samp{X} is first invoked, code is
9003 executed that copies the value of @samp{N} to a temporary.
9004 And that same temporary serves as the actual high bound for the single
9005 dimension of the @samp{A} array (the low bound being the constant 1).
9006 Since the user program cannot (legitimately) change the value
9007 of the temporary during execution of the procedure, the size
9008 of the array remains constant during each invocation.
9010 For alternate entry points, the code @code{g77} generates takes into
9011 account the possibility that a dummy adjustable array is not actually
9012 passed to the actual entry point being invoked at that time.
9013 In that case, the public procedure implementing the entry point
9014 passes to the master private procedure implementing all the
9015 code for the entry points a @code{NULL} pointer where a pointer to that
9016 adjustable array would be expected.
9017 The @code{g77}-generated code
9018 doesn't attempt to evaluate any of the expressions in the subscripts
9019 for an array if the pointer to that array is @code{NULL} at run time in
9021 (Don't depend on this particular implementation
9022 by writing code that purposely passes @code{NULL} pointers where the
9023 callee expects adjustable arrays, even if you know the callee
9024 won't reference the arrays---nor should you pass @code{NULL} pointers
9025 for any dummy arguments used in calculating the bounds of such
9026 arrays or leave undefined any values used for that purpose in
9027 COMMON---because the way @code{g77} implements these things might
9028 change in the future!)
9030 @node Alternate Entry Points
9031 @section Alternate Entry Points (ENTRY)
9032 @cindex alternate entry points
9033 @cindex entry points
9034 @cindex ENTRY statement
9035 @cindex statements, ENTRY
9037 The GBE does not understand the general concept of
9038 alternate entry points as Fortran provides via the ENTRY statement.
9039 @code{g77} gets around this by using an approach to compiling procedures
9040 having at least one @code{ENTRY} statement that is almost identical to the
9041 approach used by @code{f2c}.
9042 (An alternate approach could be used that
9043 would probably generate faster, but larger, code that would also
9044 be a bit easier to debug.)
9046 Information on how @code{g77} implements @code{ENTRY} is provided for those
9047 trying to debug such code.
9048 The choice of implementation seems
9049 unlikely to affect code (compiled in other languages) that interfaces
9052 @code{g77} compiles exactly one public procedure for the primary entry
9053 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9054 That is, in terms of the public interface, there is no difference
9073 The difference between the above two cases lies in the code compiled
9074 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9075 for the second case, an extra internal procedure is compiled.
9077 For every Fortran procedure with at least one @code{ENTRY}
9078 statement, @code{g77} compiles an extra procedure
9079 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9080 the name of the primary entry point (which, in the above case,
9081 using the standard compiler options, would be @samp{x_} in C).
9083 This extra procedure is compiled as a private procedure---that is,
9084 a procedure not accessible by name to separately compiled modules.
9085 It contains all the code in the program unit, including the code
9086 for the primary entry point plus for every entry point.
9087 (The code for each public procedure is quite short, and explained later.)
9089 The extra procedure has some other interesting characteristics.
9091 The argument list for this procedure is invented by @code{g77}.
9093 a single integer argument named @samp{__g77_which_entrypoint},
9094 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9095 entry point index---0 for the primary entry point, 1 for the
9096 first entry point (the first @code{ENTRY} statement encountered), 2 for
9097 the second entry point, and so on.
9099 It also contains, for functions returning @code{CHARACTER} and
9100 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9101 and for functions returning different types among the
9102 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9103 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9104 is expected at run time to contain a pointer to where to store
9105 the result of the entry point.
9106 For @code{CHARACTER} functions, this
9107 storage area is an array of the appropriate number of characters;
9108 for @code{COMPLEX} functions, it is the appropriate area for the return
9109 type; for multiple-return-type functions, it is a union of all the supported return
9110 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9111 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9112 is not supported by @code{g77}).
9114 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9115 by yet another argument named @samp{__g77_length} that, at run time,
9116 specifies the caller's expected length of the returned value.
9117 Note that only @code{CHARACTER*(*)} functions and entry points actually
9118 make use of this argument, even though it is always passed by
9119 all callers of public @code{CHARACTER} functions (since the caller does not
9120 generally know whether such a function is @code{CHARACTER*(*)} or whether
9121 there are any other callers that don't have that information).
9123 The rest of the argument list is the union of all the arguments
9124 specified for all the entry points (in their usual forms, e.g.
9125 @code{CHARACTER} arguments have extra length arguments, all appended at
9126 the end of this list).
9127 This is considered the ``master list'' of
9130 The code for this procedure has, before the code for the first
9131 executable statement, code much like that for the following Fortran
9135 GOTO (100000,100001,100002), __g77_which_entrypoint
9136 100000 @dots{}code for primary entry point@dots{}
9137 100001 @dots{}code immediately following first ENTRY statement@dots{}
9138 100002 @dots{}code immediately following second ENTRY statement@dots{}
9142 (Note that invalid Fortran statement labels and variable names
9143 are used in the above example to highlight the fact that it
9144 represents code generated by the @code{g77} internals, not code to be
9145 written by the user.)
9147 It is this code that, when the procedure is called, picks which
9148 entry point to start executing.
9150 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9151 example), those procedures are fairly simple.
9153 are just like they would be if they were self-contained procedures
9154 (without @code{ENTRY}), of course, since that is what the callers
9156 Their code consists of simply calling the private
9157 procedure, described above, with the appropriate extra arguments
9158 (the entry point index, and perhaps a pointer to a multiple-type-
9159 return variable, local to the public procedure, that contains
9160 all the supported returnable non-character types).
9162 that are not listed for a given entry point that are listed for
9163 other entry points, and therefore that are in the ``master list''
9164 for the private procedure, null pointers (in C, the @code{NULL} macro)
9166 Also, for entry points that are part of a multiple-type-
9167 returning function, code is compiled after the call of the private
9168 procedure to extract from the multi-type union the appropriate result,
9169 depending on the type of the entry point in question, returning
9170 that result to the original caller.
9172 When debugging a procedure containing alternate entry points, you
9173 can either set a break point on the public procedure itself (e.g.
9174 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9175 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9176 If you do the former, you should use the debugger's command to
9177 ``step into'' the called procedure to get to the actual code; with
9178 the latter approach, the break point leaves you right at the
9179 actual code, skipping over the public entry point and its call
9180 to the private procedure (unless you have set a break point there
9181 as well, of course).
9183 Further, the list of dummy arguments that is visible when the
9184 private procedure is active is going to be the expanded version
9185 of the list for whichever particular entry point is active,
9186 as explained above, and the way in which return values are
9187 handled might well be different from how they would be handled
9188 for an equivalent single-entry function.
9190 @node Alternate Returns
9191 @section Alternate Returns (SUBROUTINE and RETURN)
9193 @cindex alternate returns
9194 @cindex SUBROUTINE statement
9195 @cindex statements, SUBROUTINE
9196 @cindex RETURN statement
9197 @cindex statements, RETURN
9199 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9200 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9201 the C @code{int} type.
9202 The actual alternate-return arguments are omitted from the calling sequence.
9203 Instead, the caller uses
9204 the return value to do a rough equivalent of the Fortran
9205 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9206 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9207 function), and the callee just returns whatever integer
9208 is specified in the @code{RETURN} statement for the subroutine
9209 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9211 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9213 @node Assigned Statement Labels
9214 @section Assigned Statement Labels (ASSIGN and GOTO)
9215 @cindex assigned statement labels
9216 @cindex statement labels, assigned
9217 @cindex ASSIGN statement
9218 @cindex statements, ASSIGN
9219 @cindex GOTO statement
9220 @cindex statements, GOTO
9222 For portability to machines where a pointer (such as to a label,
9223 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9224 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9225 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9226 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9227 than it does the numerical value in that variable, unless the
9228 variable is wide enough (can hold enough bits).
9230 In particular, while @code{g77} implements
9237 as, in C notation, @samp{i = 10;}, it implements
9244 as, in GNU's extended C notation (for the label syntax),
9245 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9246 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9247 actually generate the name @samp{L10} or any other name like that,
9248 since debuggers cannot access labels anyway).
9250 While this currently means that an @code{ASSIGN} statement does not
9251 overwrite the numeric contents of its target variable, @emph{do not}
9252 write any code depending on this feature.
9253 @code{g77} has already changed this implementation across
9254 versions and might do so in the future.
9255 This information is provided only to make debugging Fortran programs
9256 compiled with the current version of @code{g77} somewhat easier.
9257 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9258 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9259 means @code{g77} has decided it can store the pointer to the label directly
9260 into @samp{I} itself.
9262 @xref{Ugly Assigned Labels}, for information on a command-line option
9263 to force @code{g77} to use the same storage for both normal and
9264 assigned-label uses of a variable.
9266 @node Run-time Library Errors
9267 @section Run-time Library Errors
9269 @cindex error values
9270 @cindex error messages
9271 @cindex messages, run-time
9274 The @code{libg2c} library currently has the following table to relate
9275 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9276 This information should, in future versions of this document, be
9277 expanded upon to include detailed descriptions of each message.
9279 In line with good coding practices, any of the numbers in the
9280 list below should @emph{not} be directly written into Fortran
9282 Instead, make a separate @code{INCLUDE} file that defines
9283 @code{PARAMETER} names for them, and use those in your code,
9284 so you can more easily change the actual numbers in the future.
9286 The information below is culled from the definition
9287 of @samp{F_err} in @file{f/runtime/libI77/err.c} in the
9288 @code{g77} source tree.
9291 100: "error in format"
9292 101: "illegal unit number"
9293 102: "formatted io not allowed"
9294 103: "unformatted io not allowed"
9295 104: "direct io not allowed"
9296 105: "sequential io not allowed"
9297 106: "can't backspace file"
9298 107: "null file name"
9299 108: "can't stat file"
9300 109: "unit not connected"
9301 110: "off end of record"
9302 111: "truncation failed in endfile"
9303 112: "incomprehensible list input"
9304 113: "out of free space"
9305 114: "unit not connected"
9306 115: "read unexpected character"
9307 116: "bad logical input field"
9308 117: "bad variable type"
9309 118: "bad namelist name"
9310 119: "variable not in namelist"
9311 120: "no end record"
9312 121: "variable count incorrect"
9313 122: "subscript for scalar variable"
9314 123: "invalid array section"
9315 124: "substring out of bounds"
9316 125: "subscript out of bounds"
9317 126: "can't read file"
9318 127: "can't write file"
9319 128: "'new' file exists"
9320 129: "can't append to file"
9321 130: "non-positive record number"
9322 131: "I/O started while already doing I/O"
9325 @node Collected Fortran Wisdom
9326 @chapter Collected Fortran Wisdom
9329 @cindex code, legacy
9330 @cindex writing code
9331 @cindex code, writing
9333 Most users of @code{g77} can be divided into two camps:
9337 Those writing new Fortran code to be compiled by @code{g77}.
9340 Those using @code{g77} to compile existing, ``legacy'' code.
9343 Users writing new code generally understand most of the necessary
9344 aspects of Fortran to write ``mainstream'' code, but often need
9345 help deciding how to handle problems, such as the construction
9346 of libraries containing @code{BLOCK DATA}.
9348 Users dealing with ``legacy'' code sometimes don't have much
9349 experience with Fortran, but believe that the code they're compiling
9350 already works when compiled by other compilers (and might
9351 not understand why, as is sometimes the case, it doesn't work
9352 when compiled by @code{g77}).
9354 The following information is designed to help users do a better job
9355 coping with existing, ``legacy'' Fortran code, and with writing
9359 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9360 * Block Data and Libraries:: How @code{g77} solves a common problem.
9361 * Loops:: Fortran @code{DO} loops surprise many people.
9362 * Working Programs:: Getting programs to work should be done first.
9363 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9364 * Faster Programs:: Everybody wants these, but at what cost?
9367 @node Advantages Over f2c
9368 @section Advantages Over f2c
9370 Without @code{f2c}, @code{g77} would have taken much longer to
9371 do and probably not been as good for quite a while.
9372 Sometimes people who notice how much @code{g77} depends on, and
9373 documents encouragement to use, @code{f2c} ask why @code{g77}
9374 was created if @code{f2c} already existed.
9376 This section gives some basic answers to these questions, though it
9377 is not intended to be comprehensive.
9380 * Language Extensions:: Features used by Fortran code.
9381 * Compiler Options:: Features helpful during development.
9382 * Compiler Speed:: Speed of the compilation process.
9383 * Program Speed:: Speed of the generated, optimized code.
9384 * Ease of Debugging:: Debugging ease-of-use at the source level.
9385 * Character and Hollerith Constants:: A byte saved is a byte earned.
9388 @node Language Extensions
9389 @subsection Language Extensions
9391 @code{g77} offers several extensions to the Fortran language that @code{f2c}
9394 However, @code{f2c} offers a few that @code{g77} doesn't, like
9395 fairly complete support for @code{INTEGER*2}.
9396 It is expected that @code{g77} will offer some or all of these missing
9397 features at some time in the future.
9398 (Version 0.5.18 of @code{g77} offers some rudimentary support for some
9401 @node Compiler Options
9402 @subsection Compiler Options
9404 @code{g77} offers a whole bunch of compiler options that @code{f2c} doesn't.
9406 However, @code{f2c} offers a few that @code{g77} doesn't, like an
9407 option to generate code to check array subscripts at run time.
9408 It is expected that @code{g77} will offer some or all of these
9409 missing options at some time in the future.
9411 @node Compiler Speed
9412 @subsection Compiler Speed
9414 Saving the steps of writing and then rereading C code is a big reason
9415 why @code{g77} should be able to compile code much faster than using
9416 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9418 However, due to @code{g77}'s youth, lots of self-checking is still being
9420 As a result, this improvement is as yet unrealized
9421 (though the potential seems to be there for quite a big speedup
9423 It is possible that, as of version 0.5.18, @code{g77}
9424 is noticeably faster compiling many Fortran source files than using
9425 @code{f2c} in conjunction with @code{gcc}.
9428 @subsection Program Speed
9430 @code{g77} has the potential to better optimize code than @code{f2c},
9431 even when @code{gcc} is used to compile the output of @code{f2c},
9432 because @code{f2c} must necessarily
9433 translate Fortran into a somewhat lower-level language (C) that cannot
9434 preserve all the information that is potentially useful for optimization,
9435 while @code{g77} can gather, preserve, and transmit that information directly
9438 For example, @code{g77} implements @code{ASSIGN} and assigned
9439 @code{GOTO} using direct assignment of pointers to labels and direct
9440 jumps to labels, whereas @code{f2c} maps the assigned labels to
9441 integer values and then uses a C @code{switch} statement to encode
9442 the assigned @code{GOTO} statements.
9444 However, as is typical, theory and reality don't quite match, at least
9445 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9446 can generate code that is faster than @code{g77}.
9448 Version 0.5.18 of @code{g77} offered default
9449 settings and options, via patches to the @code{gcc}
9450 back end, that allow for better program speed, though
9451 some of these improvements also affected the performance
9452 of programs translated by @code{f2c} and then compiled
9453 by @code{g77}'s version of @code{gcc}.
9455 Version 0.5.20 of @code{g77} offers further performance
9456 improvements, at least one of which (alias analysis) is
9457 not generally applicable to @code{f2c} (though @code{f2c}
9458 could presumably be changed to also take advantage of
9459 this new capability of the @code{gcc} back end, assuming
9460 this is made available in an upcoming release of @code{gcc}).
9462 @node Ease of Debugging
9463 @subsection Ease of Debugging
9465 Because @code{g77} compiles directly to assembler code like @code{gcc},
9466 instead of translating to an intermediate language (C) as does @code{f2c},
9467 support for debugging can be better for @code{g77} than @code{f2c}.
9469 However, although @code{g77} might be somewhat more ``native'' in terms of
9470 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9471 of things ``not quite right''.
9472 Many of the important ones should be resolved in the near future.
9474 For example, @code{g77} doesn't have to worry about reserved names
9475 like @code{f2c} does.
9476 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9477 translate this to something @emph{other} than
9478 @samp{for = while;}, because C reserves those words.
9480 However, @code{g77} does still uses things like an extra level of indirection
9481 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9482 yet support multiple entry points.
9484 Another example is that, given
9492 the @code{g77} user should be able to access the variables directly, by name,
9493 without having to traverse C-like structures and unions, while @code{f2c}
9494 is unlikely to ever offer this ability (due to limitations in the
9497 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9498 take advantage of this facility at all---it doesn't emit any debugging
9499 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9500 other than information
9501 on the array of @code{char} it creates (and, in the case
9502 of local @code{EQUIVALENCE}, names) for each such area.
9504 Yet another example is arrays.
9505 @code{g77} represents them to the debugger
9506 using the same ``dimensionality'' as in the source code, while @code{f2c}
9507 must necessarily convert them all to one-dimensional arrays to fit
9508 into the confines of the C language.
9509 However, the level of support
9510 offered by debuggers for interactive Fortran-style access to arrays
9511 as compiled by @code{g77} can vary widely.
9512 In some cases, it can actually
9513 be an advantage that @code{f2c} converts everything to widely supported
9516 In fairness, @code{g77} could do many of the things @code{f2c} does
9517 to get things working at least as well as @code{f2c}---for now,
9518 the developers prefer making @code{g77} work the
9519 way they think it is supposed to, and finding help improving the
9520 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9521 to get things working properly.
9523 @node Character and Hollerith Constants
9524 @subsection Character and Hollerith Constants
9525 @cindex character constants
9526 @cindex constants, character
9527 @cindex Hollerith constants
9528 @cindex constants, Hollerith
9529 @cindex trailing null byte
9530 @cindex null byte, trailing
9531 @cindex zero byte, trailing
9533 To avoid the extensive hassle that would be needed to avoid this,
9534 @code{f2c} uses C character constants to encode character and Hollerith
9536 That means a constant like @samp{'HELLO'} is translated to
9537 @samp{"hello"} in C, which further means that an extra null byte is
9538 present at the end of the constant.
9539 This null byte is superfluous.
9541 @code{g77} does not generate such null bytes.
9542 This represents significant
9543 savings of resources, such as on systems where @file{/dev/null} or
9544 @file{/dev/zero} represent bottlenecks in the systems' performance,
9545 because @code{g77} simply asks for fewer zeros from the operating
9546 system than @code{f2c}.
9547 (Avoiding spurious use of zero bytes, each byte typically have
9548 eight zero bits, also reduces the liabilities in case
9549 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9551 @node Block Data and Libraries
9552 @section Block Data and Libraries
9553 @cindex block data and libraries
9554 @cindex BLOCK DATA statement
9555 @cindex statements, BLOCK DATA
9556 @cindex libraries, containing BLOCK DATA
9557 @cindex @code{f2c} compatibility
9558 @cindex compatibility, @code{f2c}
9560 To ensure that block data program units are linked, especially a concern
9561 when they are put into libraries, give each one a name (as in
9562 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9563 statement in every program unit that uses any common block
9564 initialized by the corresponding @code{BLOCK DATA}.
9565 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9567 that is, it generates an actual procedure having the appropriate name.
9568 The procedure does nothing but return immediately if it happens to be
9570 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9571 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9572 in the program and ensures that by generating a
9573 reference to it so the linker will make sure it is present.
9574 (Specifically, @code{g77} outputs in the data section a static pointer to the
9575 external name @samp{FOO}.)
9577 The implementation @code{g77} currently uses to make this work is
9578 one of the few things not compatible with @code{f2c} as currently
9580 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9581 issue a warning that @samp{FOO} is not otherwise referenced,
9582 and, for @samp{BLOCK DATA FOO},
9583 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9584 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9585 this particular case.
9586 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9587 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9588 will result in an unresolved reference when linked.
9590 opposite, then @samp{FOO} might not be linked in under various
9591 circumstances (such as when @samp{FOO} is in a library, or you're
9592 using a ``clever'' linker---so clever, it produces a broken program
9593 with little or no warning by omitting initializations of global data
9594 because they are contained in unreferenced procedures).
9596 The changes you make to your code to make @code{g77} handle this situation,
9597 however, appear to be a widely portable way to handle it.
9598 That is, many systems permit it (as they should, since the
9599 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9600 is a block data program unit), and of the ones
9601 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9602 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9605 Here is the recommended approach to modifying a program containing
9606 a program unit such as the following:
9610 COMMON /VARS/ X, Y, Z
9611 DATA X, Y, Z / 3., 4., 5. /
9616 If the above program unit might be placed in a library module, then
9617 ensure that every program unit in every program that references that
9618 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9619 to force the area to be initialized.
9621 For example, change a program unit that starts with
9624 INTEGER FUNCTION CURX()
9625 COMMON /VARS/ X, Y, Z
9631 so that it uses the @code{EXTERNAL} statement, as in:
9634 INTEGER FUNCTION CURX()
9635 COMMON /VARS/ X, Y, Z
9642 That way, @samp{CURX} is compiled by @code{g77} (and many other
9643 compilers) so that the linker knows it must include @samp{FOO},
9644 the @code{BLOCK DATA} program unit that sets the initial values
9645 for the variables in @samp{VAR}, in the executable program.
9649 @cindex DO statement
9650 @cindex statements, DO
9651 @cindex trips, number of
9652 @cindex number of trips
9654 The meaning of a @code{DO} loop in Fortran is precisely specified
9655 in the Fortran standard@dots{}and is quite different from what
9656 many programmers might expect.
9658 In particular, Fortran @code{DO} loops are implemented as if
9659 the number of trips through the loop is calculated @emph{before}
9660 the loop is entered.
9662 The number of trips for a loop is calculated from the @var{start},
9663 @var{end}, and @var{increment} values specified in a statement such as:
9666 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9670 The trip count is evaluated using a fairly simple formula
9671 based on the three values following the @samp{=} in the
9672 statement, and it is that trip count that is effectively
9673 decremented during each iteration of the loop.
9674 If, at the beginning of an iteration of the loop, the
9675 trip count is zero or negative, the loop terminates.
9676 The per-loop-iteration modifications to @var{iter} are not
9677 related to determining whether to terminate the loop.
9679 There are two important things to remember about the trip
9684 It can be @emph{negative}, in which case it is
9685 treated as if it was zero---meaning the loop is
9686 not executed at all.
9689 The type used to @emph{calculate} the trip count
9690 is the same type as @var{iter}, but the final
9691 calculation, and thus the type of the trip
9692 count itself, always is @code{INTEGER(KIND=1)}.
9695 These two items mean that there are loops that cannot
9696 be written in straightforward fashion using the Fortran @code{DO}.
9698 For example, on a system with the canonical 32-bit two's-complement
9699 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9702 DO I = -2000000000, 2000000000
9706 Although the @var{start} and @var{end} values are well within
9707 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9708 The expected trip count is 40000000001, which is outside
9709 the range of @code{INTEGER(KIND=1)} on many systems.
9711 Instead, the above loop should be constructed this way:
9716 IF (I .GT. 2000000000) EXIT
9723 The simple @code{DO} construct and the @code{EXIT} statement
9724 (used to leave the innermost loop)
9725 are F90 features that @code{g77} supports.
9727 Some Fortran compilers have buggy implementations of @code{DO},
9728 in that they don't follow the standard.
9729 They implement @code{DO} as a straightforward translation
9730 to what, in C, would be a @code{for} statement.
9731 Instead of creating a temporary variable to hold the trip count
9732 as calculated at run time, these compilers
9733 use the iteration variable @var{iter} to control
9734 whether the loop continues at each iteration.
9736 The bug in such an implementation shows up when the
9737 trip count is within the range of the type of @var{iter},
9738 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9739 exceeds that range. For example:
9742 DO I = 2147483600, 2147483647
9746 A loop started by the above statement will work as implemented
9747 by @code{g77}, but the use, by some compilers, of a
9748 more C-like implementation akin to
9751 for (i = 2147483600; i <= 2147483647; ++i)
9755 produces a loop that does not terminate, because @samp{i}
9756 can never be greater than 2147483647, since incrementing it
9757 beyond that value overflows @samp{i}, setting it to -2147483648.
9758 This is a large, negative number that still is less than 2147483647.
9760 Another example of unexpected behavior of @code{DO} involves
9761 using a nonintegral iteration variable @var{iter}, that is,
9762 a @code{REAL} variable.
9763 Consider the following program:
9766 DATA BEGIN, END, STEP /.1, .31, .007/
9767 DO 10 R = BEGIN, END, STEP
9768 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9772 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9777 A C-like view of @code{DO} would hold that the two ``exclamatory''
9778 @code{PRINT} statements are never executed.
9779 However, this is the output of running the above program
9780 as compiled by @code{g77} on a GNU/Linux ix86 system:
9792 .310000002 .LE. .310000002!!
9795 Note that one of the two checks in the program turned up
9796 an apparent violation of the programmer's expectation---yet,
9797 the loop is correctly implemented by @code{g77}, in that
9798 it has 30 iterations.
9799 This trip count of 30 is correct when evaluated using
9800 the floating-point representations for the @var{begin},
9801 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
9803 On other systems, an apparently more accurate trip count
9804 of 31 might result, but, nevertheless, @code{g77} is
9805 faithfully following the Fortran standard, and the result
9806 is not what the author of the sample program above
9807 apparently expected.
9808 (Such other systems might, for different values in the @code{DATA}
9809 statement, violate the other programmer's expectation,
9812 Due to this combination of imprecise representation
9813 of floating-point values and the often-misunderstood
9814 interpretation of @code{DO} by standard-conforming
9815 compilers such as @code{g77}, use of @code{DO} loops
9816 with @code{REAL} iteration
9817 variables is not recommended.
9818 Such use can be caught by specifying @samp{-Wsurprising}.
9819 @xref{Warning Options}, for more information on this
9822 @node Working Programs
9823 @section Working Programs
9825 Getting Fortran programs to work in the first place can be
9826 quite a challenge---even when the programs already work on
9827 other systems, or when using other compilers.
9829 @code{g77} offers some facilities that might be useful for
9830 tracking down bugs in such programs.
9834 * Variables Assumed To Be Zero::
9835 * Variables Assumed To Be Saved::
9836 * Unwanted Variables::
9837 * Unused Arguments::
9838 * Surprising Interpretations of Code::
9839 * Aliasing Assumed To Work::
9840 * Output Assumed To Flush::
9841 * Large File Unit Numbers::
9845 @subsection Not My Type
9846 @cindex mistyped variables
9847 @cindex variables, mistyped
9848 @cindex mistyped functions
9849 @cindex functions, mistyped
9850 @cindex implicit typing
9852 A fruitful source of bugs in Fortran source code is use, or
9853 mis-use, of Fortran's implicit-typing feature, whereby the
9854 type of a variable, array, or function is determined by the
9855 first character of its name.
9857 Simple cases of this include statements like @samp{LOGX=9.227},
9858 without a statement such as @samp{REAL LOGX}.
9859 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
9860 type, with the result of the assignment being that it is given
9863 More involved cases include a function that is defined starting
9864 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
9865 Any caller of this function that does not also declare @samp{IPS}
9866 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
9867 is likely to assume it returns
9868 @code{INTEGER}, or some other type, leading to invalid results
9869 or even program crashes.
9871 The @samp{-Wimplicit} option might catch failures to
9872 properly specify the types of
9873 variables, arrays, and functions in the code.
9875 However, in code that makes heavy use of Fortran's
9876 implicit-typing facility, this option might produce so
9877 many warnings about cases that are working, it would be
9878 hard to find the one or two that represent bugs.
9879 This is why so many experienced Fortran programmers strongly
9880 recommend widespread use of the @code{IMPLICIT NONE} statement,
9881 despite it not being standard FORTRAN 77, to completely turn
9882 off implicit typing.
9883 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
9884 FORTRAN 77 compilers.)
9886 Note that @samp{-Wimplicit} catches only implicit typing of
9888 It does not catch implicit typing of expressions such
9890 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
9891 is equivalent to @samp{X**0}, due to the way Fortran expressions
9892 are given types and then evaluated.
9893 (In this particular case, the programmer probably wanted
9896 @node Variables Assumed To Be Zero
9897 @subsection Variables Assumed To Be Zero
9898 @cindex zero-initialized variables
9899 @cindex variables assumed to be zero
9900 @cindex uninitialized variables
9902 Many Fortran programs were developed on systems that provided
9903 automatic initialization of all, or some, variables and arrays
9905 As a result, many of these programs depend, sometimes
9906 inadvertently, on this behavior, though to do so violates
9907 the Fortran standards.
9909 You can ask @code{g77} for this behavior by specifying the
9910 @samp{-finit-local-zero} option when compiling Fortran code.
9911 (You might want to specify @samp{-fno-automatic} as well,
9912 to avoid code-size inflation for non-optimized compilations.)
9914 Note that a program that works better when compiled with the
9915 @samp{-finit-local-zero} option
9916 is almost certainly depending on a particular system's,
9917 or compiler's, tendency to initialize some variables to zero.
9918 It might be worthwhile finding such cases and fixing them,
9919 using techniques such as compiling with the @samp{-O -Wuninitialized}
9920 options using @code{g77}.
9922 @node Variables Assumed To Be Saved
9923 @subsection Variables Assumed To Be Saved
9924 @cindex variables retaining values across calls
9925 @cindex saved variables
9926 @cindex static variables
9928 Many Fortran programs were developed on systems that
9929 saved the values of all, or some, variables and arrays
9930 across procedure calls.
9931 As a result, many of these programs depend, sometimes
9932 inadvertently, on being able to assign a value to a
9933 variable, perform a @code{RETURN} to a calling procedure,
9934 and, upon subsequent invocation, reference the previously
9935 assigned variable to obtain the value.
9937 They expect this despite not using the @code{SAVE} statement
9938 to specify that the value in a variable is expected to survive
9939 procedure returns and calls.
9940 Depending on variables and arrays to retain values across
9941 procedure calls without using @code{SAVE} to require it violates
9942 the Fortran standards.
9944 You can ask @code{g77} to assume @code{SAVE} is specified for all
9945 relevant (local) variables and arrays by using the
9946 @samp{-fno-automatic} option.
9948 Note that a program that works better when compiled with the
9949 @samp{-fno-automatic} option
9950 is almost certainly depending on not having to use
9951 the @code{SAVE} statement as required by the Fortran standard.
9952 It might be worthwhile finding such cases and fixing them,
9953 using techniques such as compiling with the @samp{-O -Wuninitialized}
9954 options using @code{g77}.
9956 @node Unwanted Variables
9957 @subsection Unwanted Variables
9959 The @samp{-Wunused} option can find bugs involving
9960 implicit typing, sometimes
9961 more easily than using @samp{-Wimplicit} in code that makes
9962 heavy use of implicit typing.
9963 An unused variable or array might indicate that the
9964 spelling for its declaration is different from that of
9967 Other than cases involving typos, unused variables rarely
9968 indicate actual bugs in a program.
9969 However, investigating such cases thoroughly has, on occasion,
9970 led to the discovery of code that had not been completely
9971 written---where the programmer wrote declarations as needed
9972 for the whole algorithm, wrote some or even most of the code
9973 for that algorithm, then got distracted and forgot that the
9974 job was not complete.
9976 @node Unused Arguments
9977 @subsection Unused Arguments
9978 @cindex unused arguments
9979 @cindex arguments, unused
9981 As with unused variables, It is possible that unused arguments
9982 to a procedure might indicate a bug.
9983 Compile with @samp{-W -Wunused} option to catch cases of
9986 Note that @samp{-W} also enables warnings regarding overflow
9987 of floating-point constants under certain circumstances.
9989 @node Surprising Interpretations of Code
9990 @subsection Surprising Interpretations of Code
9992 The @samp{-Wsurprising} option can help find bugs involving
9993 expression evaluation or in
9994 the way @code{DO} loops with non-integral iteration variables
9996 Cases found by this option might indicate a difference of
9997 interpretation between the author of the code involved, and
9998 a standard-conforming compiler such as @code{g77}.
9999 Such a difference might produce actual bugs.
10001 In any case, changing the code to explicitly do what the
10002 programmer might have expected it to do, so @code{g77} and
10003 other compilers are more likely to follow the programmer's
10004 expectations, might be worthwhile, especially if such changes
10005 make the program work better.
10007 @node Aliasing Assumed To Work
10008 @subsection Aliasing Assumed To Work
10009 @cindex -falias-check option
10010 @cindex options, -falias-check
10011 @cindex -fargument-alias option
10012 @cindex options, -fargument-alias
10013 @cindex -fargument-noalias option
10014 @cindex options, -fargument-noalias
10015 @cindex -fno-argument-noalias-global option
10016 @cindex options, -fno-argument-noalias-global
10018 @cindex anti-aliasing
10019 @cindex overlapping arguments
10021 @cindex association, storage
10022 @cindex storage association
10023 @cindex scheduling of reads and writes
10024 @cindex reads and writes, scheduling
10026 The @samp{-falias-check}, @samp{-fargument-alias},
10027 @samp{-fargument-noalias},
10028 and @samp{-fno-argument-noalias-global} options,
10029 introduced in version 0.5.20 and
10030 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10031 were withdrawn as of @code{g77} version 0.5.23
10032 due to their not being supported by @code{gcc} version 2.8.
10034 These options, which control the assumptions regarding aliasing
10035 (overlapping) of writes and reads to main memory (core) made
10036 by the @code{gcc} back end,
10037 might well be added back (in some form) in a future version
10040 However, these options @emph{are} supported by @code{egcs}.
10042 The information below still is useful, but applies to
10043 only those versions of @code{g77} that support the
10044 alias analysis implied by support for these options.
10046 These options are effective only when compiling with @samp{-O}
10047 (specifying any level other than @samp{-O0})
10048 or with @samp{-falias-check}.
10050 The default for Fortran code is @samp{-fargument-noalias-global}.
10051 (The default for C code and code written in other C-based languages
10052 is @samp{-fargument-alias}.
10053 These defaults apply regardless of whether you use @code{g77} or
10054 @code{gcc} to compile your code.)
10056 Note that, on some systems, compiling with @samp{-fforce-addr} in
10057 effect can produce more optimal code when the default aliasing
10058 options are in effect (and when optimization is enabled).
10060 If your program is not working when compiled with optimization,
10061 it is possible it is violating the Fortran standards (77 and 90)
10062 by relying on the ability to ``safely'' modify variables and
10063 arrays that are aliased, via procedure calls, to other variables
10064 and arrays, without using @code{EQUIVALENCE} to explicitly
10065 set up this kind of aliasing.
10067 (The FORTRAN 77 standard's prohibition of this sort of
10068 overlap, generally referred to therein as ``storage
10069 assocation'', appears in Sections 15.9.3.6.
10070 This prohibition allows implementations, such as @code{g77},
10071 to, for example, implement the passing of procedures and
10072 even values in @code{COMMON} via copy operations into local,
10073 perhaps more efficiently accessed temporaries at entry to a
10074 procedure, and, where appropriate, via copy operations back
10075 out to their original locations in memory at exit from that
10076 procedure, without having to take into consideration the
10077 order in which the local copies are updated by the code,
10078 among other things.)
10080 To test this hypothesis, try compiling your program with
10081 the @samp{-fargument-alias} option, which causes the
10082 compiler to revert to assumptions essentially the same as
10083 made by versions of @code{g77} prior to 0.5.20.
10085 If the program works using this option, that strongly suggests
10086 that the bug is in your program.
10087 Finding and fixing the bug(s) should result in a program that
10088 is more standard-conforming and that can be compiled by @code{g77}
10089 in a way that results in a faster executable.
10091 (You might want to try compiling with @samp{-fargument-noalias},
10092 a kind of half-way point, to see if the problem is limited to
10093 aliasing between dummy arguments and @code{COMMON} variables---this
10094 option assumes that such aliasing is not done, while still allowing
10095 aliasing among dummy arguments.)
10097 An example of aliasing that is invalid according to the standards
10098 is shown in the following program, which might @emph{not} produce
10099 the expected results when executed:
10107 SUBROUTINE FOO(J, K)
10114 The above program attempts to use the temporary aliasing of the
10115 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10116 pathological behavior---the simultaneous changing of the values
10117 of @emph{both} @samp{J} and @samp{K} when either one of them
10120 The programmer likely expects the program to print these values:
10127 However, since the program is not standard-conforming, an
10128 implementation's behavior when running it is undefined, because
10129 subroutine @samp{FOO} modifies at least one of the arguments,
10130 and they are aliased with each other.
10131 (Even if one of the assignment statements was deleted, the
10132 program would still violate these rules.
10133 This kind of on-the-fly aliasing is permitted by the standard
10134 only when none of the aliased items are defined, or written,
10135 while the aliasing is in effect.)
10137 As a practical example, an optimizing compiler might schedule
10138 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10139 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10140 resulting in the following output:
10147 Essentially, compilers are promised (by the standard and, therefore,
10148 by programmers who write code they claim to be standard-conforming)
10149 that if they cannot detect aliasing via static analysis of a single
10150 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10151 such aliasing exists.
10152 In such cases, compilers are free to assume that an assignment to
10153 one variable will not change the value of another variable, allowing
10154 it to avoid generating code to re-read the value of the other
10155 variable, to re-schedule reads and writes, and so on, to produce
10156 a faster executable.
10158 The same promise holds true for arrays (as seen by the called
10159 procedure)---an element of one dummy array cannot be aliased
10160 with, or overlap, any element of another dummy array or be
10161 in a @code{COMMON} area known to the procedure.
10163 (These restrictions apply only when the procedure defines, or
10164 writes to, one of the aliased variables or arrays.)
10166 Unfortunately, there is no way to find @emph{all} possible cases of
10167 violations of the prohibitions against aliasing in Fortran code.
10168 Static analysis is certainly imperfect, as is run-time analysis,
10169 since neither can catch all violations.
10170 (Static analysis can catch all likely violations, and some that
10171 might never actually happen, while run-time analysis can catch
10172 only those violations that actually happen during a particular run.
10173 Neither approach can cope with programs mixing Fortran code with
10174 routines written in other languages, however.)
10176 Currently, @code{g77} provides neither static nor run-time facilities
10177 to detect any cases of this problem, although other products might.
10178 Run-time facilities are more likely to be offered by future
10179 versions of @code{g77}, though patches improving @code{g77} so that
10180 it provides either form of detection are welcome.
10182 @node Output Assumed To Flush
10183 @subsection Output Assumed To Flush
10184 @cindex ALWAYS_FLUSH
10185 @cindex synchronous write errors
10187 @cindex flushing output
10189 @cindex I/O, flushing
10190 @cindex output, flushing
10191 @cindex writes, flushing
10193 @cindex network file system
10195 For several versions prior to 0.5.20, @code{g77} configured its
10196 version of the @code{libf2c} run-time library so that one of
10197 its configuration macros, @samp{ALWAYS_FLUSH}, was defined.
10199 This was done as a result of a belief that many programs expected
10200 output to be flushed to the operating system (under UNIX, via
10201 the @code{fflush()} library call) with the result that errors,
10202 such as disk full, would be immediately flagged via the
10203 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10205 Because of the adverse effects this approach had on the performance
10206 of many programs, @code{g77} no longer configures @code{libf2c}
10207 (now named @code{libg2c} in its @code{g77} incarnation)
10208 to always flush output.
10210 If your program depends on this behavior, either insert the
10211 appropriate @samp{CALL FLUSH} statements, or modify the sources
10212 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10213 relink your programs with the modified library.
10215 (Ideally, @code{libg2c} would offer the choice at run-time, so
10216 that a compile-time option to @code{g77} or @code{f2c} could
10217 result in generating the appropriate calls to flushing or
10218 non-flushing library routines.)
10220 @xref{Always Flush Output}, for information on how to modify
10221 the @code{g77} source tree so that a version of @code{libg2c}
10222 can be built and installed with the @samp{ALWAYS_FLUSH} macro defined.
10224 @node Large File Unit Numbers
10225 @subsection Large File Unit Numbers
10227 @cindex unit numbers
10228 @cindex maximum unit number
10229 @cindex illegal unit number
10230 @cindex increasing maximum unit number
10232 If your program crashes at run time with a message including
10233 the text @samp{illegal unit number}, that probably is
10234 a message from the run-time library, @code{libg2c}.
10236 The message means that your program has attempted to use a
10237 file unit number that is out of the range accepted by
10239 Normally, this range is 0 through 99, and the high end
10240 of the range is controlled by a @code{libg2c} source-file
10241 macro named @samp{MXUNIT}.
10243 If you can easily change your program to use unit numbers
10244 in the range 0 through 99, you should do so.
10246 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10247 to change @samp{MXUNIT} in @code{libg2c} so you can build and
10248 install a new version of @code{libg2c} that supports the larger
10249 unit numbers you need.
10251 @emph{Note:} While @code{libg2c} places a limit on the range
10252 of Fortran file-unit numbers, the underlying library and operating
10253 system might impose different kinds of limits.
10254 For example, some systems limit the number of files simultaneously
10255 open by a running program.
10256 Information on how to increase these limits should be found
10257 in your system's documentation.
10259 @node Overly Convenient Options
10260 @section Overly Convenient Command-line Options
10261 @cindex overly convenient options
10262 @cindex options, overly convenient
10264 These options should be used only as a quick-and-dirty way to determine
10265 how well your program will run under different compilation models
10266 without having to change the source.
10267 Some are more problematic
10268 than others, depending on how portable and maintainable you want the
10269 program to be (and, of course, whether you are allowed to change it
10270 at all is crucial).
10272 You should not continue to use these command-line options to compile
10273 a given program, but rather should make changes to the source code:
10276 @cindex -finit-local-zero option
10277 @cindex options, -finit-local-zero
10278 @item -finit-local-zero
10279 (This option specifies that any uninitialized local variables
10280 and arrays have default initialization to binary zeros.)
10282 Many other compilers do this automatically, which means lots of
10283 Fortran code developed with those compilers depends on it.
10285 It is safer (and probably
10286 would produce a faster program) to find the variables and arrays that
10287 need such initialization and provide it explicitly via @code{DATA}, so that
10288 @samp{-finit-local-zero} is not needed.
10290 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10291 find likely candidates, but
10292 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10293 or this technique won't work.
10295 @cindex -fno-automatic option
10296 @cindex options, -fno-automatic
10297 @item -fno-automatic
10298 (This option specifies that all local variables and arrays
10299 are to be treated as if they were named in @code{SAVE} statements.)
10301 Many other compilers do this automatically, which means lots of
10302 Fortran code developed with those compilers depends on it.
10304 The effect of this is that all non-automatic variables and arrays
10305 are made static, that is, not placed on the stack or in heap storage.
10306 This might cause a buggy program to appear to work better.
10307 If so, rather than relying on this command-line option (and hoping all
10308 compilers provide the equivalent one), add @code{SAVE}
10309 statements to some or all program unit sources, as appropriate.
10310 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10311 to find likely candidates, but
10312 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10313 or this technique won't work.
10315 The default is @samp{-fautomatic}, which tells @code{g77} to try
10316 and put variables and arrays on the stack (or in fast registers)
10317 where possible and reasonable.
10318 This tends to make programs faster.
10320 @cindex automatic arrays
10321 @cindex arrays, automatic
10322 @emph{Note:} Automatic variables and arrays are not affected
10324 These are variables and arrays that are @emph{necessarily} automatic,
10325 either due to explicit statements, or due to the way they are
10327 Examples include local variables and arrays not given the
10328 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10329 and local arrays declared with non-constant bounds (automatic
10331 Currently, @code{g77} supports only automatic arrays, not
10332 @code{RECURSIVE} procedures or other means of explicitly
10333 specifying that variables or arrays are automatic.
10335 @cindex -fugly option
10336 @cindex options, -fugly
10338 Fix the source code so that @samp{-fno-ugly} will work.
10339 Note that, for many programs, it is difficult to practically
10340 avoid using the features enabled via @samp{-fugly-init}, and these
10341 features pose the lowest risk of writing nonportable code, among the
10342 various ``ugly'' features.
10344 @cindex -f@var{group}-intrinsics-hide option
10345 @cindex options, -f@var{group}-intrinsics-hide
10346 @item -f@var{group}-intrinsics-hide
10347 Change the source code to use @code{EXTERNAL} for any external procedure
10348 that might be the name of an intrinsic.
10349 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10352 @node Faster Programs
10353 @section Faster Programs
10354 @cindex speeding up programs
10355 @cindex programs, speeding up
10357 Aside from the usual @code{gcc} options, such as @samp{-O},
10358 @samp{-ffast-math}, and so on, consider trying some of the
10359 following approaches to speed up your program (once you get
10364 * Prefer Automatic Uninitialized Variables::
10365 * Avoid f2c Compatibility::
10366 * Use Submodel Options::
10370 @subsection Aligned Data
10371 @cindex data, aligned
10372 @cindex stack, aligned
10373 @cindex aligned data
10374 @cindex aligned stack
10375 @cindex Pentium optimizations
10376 @cindex optimizations, Pentium
10378 On some systems, such as those with Pentium Pro CPUs, programs
10379 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10380 might run much slower
10381 than possible due to the compiler not aligning these 64-bit
10382 values to 64-bit boundaries in memory.
10383 (The effect also is present, though
10384 to a lesser extent, on the 586 (Pentium) architecture.)
10386 The Intel x86 architecture generally ensures that these programs will
10387 work on all its implementations,
10388 but particular implementations (such as Pentium Pro)
10389 perform better with more strict alignment.
10390 (Such behavior isn't unique to the Intel x86 architecture.)
10391 Other architectures might @emph{demand} 64-bit alignment
10394 There are a variety of approaches to use to address this problem:
10398 @cindex COMMON, layout
10399 @cindex layout of common blocks
10400 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10401 that the variables and arrays with the widest alignment
10402 guidelines come first.
10404 For example, on most systems, this would mean placing
10405 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10406 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10407 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10408 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10409 and @code{INTEGER(KIND=3)} entities.
10411 The reason to use such placement is it makes it more likely
10412 that your data will be aligned properly, without requiring
10413 you to do detailed analysis of each aggregate (@code{COMMON}
10414 and @code{EQUIVALENCE}) area.
10416 Specifically, on systems where the above guidelines are
10417 appropriate, placing @code{CHARACTER} entities before
10418 @code{REAL(KIND=2)} entities can work just as well,
10419 but only if the number of bytes occupied by the @code{CHARACTER}
10420 entities is divisible by the recommended alignment for
10421 @code{REAL(KIND=2)}.
10423 By ordering the placement of entities in aggregate
10424 areas according to the simple guidelines above, you
10425 avoid having to carefully count the number of bytes
10426 occupied by each entity to determine whether the
10427 actual alignment of each subsequent entity meets the
10428 alignment guidelines for the type of that entity.
10430 If you don't ensure correct alignment of @code{COMMON} elements, the
10431 compiler may be forced by some systems to violate the Fortran semantics by
10432 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10433 If the unfortunate practice is employed of overlaying different types of
10434 data in the @code{COMMON} block, the different variants
10435 of this block may become misaligned with respect to each other.
10436 Even if your platform doesn't require strict alignment,
10437 @code{COMMON} should be laid out as above for portability.
10438 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10439 possible requirement, which is compiler-independent on a given platform.)
10442 @cindex -malign-double option
10443 @cindex options, -malign-double
10444 Use the (x86-specific) @samp{-malign-double} option when compiling
10445 programs for the Pentium and Pentium Pro architectures (called 586
10446 and 686 in the @code{gcc} configuration subsystem).
10447 The warning about this in the @code{gcc} manual isn't
10448 generally relevant to Fortran,
10449 but using it will force @code{COMMON} to be padded if necessary to align
10450 @code{DOUBLE PRECISION} data.
10452 When @code{DOUBLE PRECISION} data is forcibly aligned
10453 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10454 @code{g77} issues a warning about the need to
10457 In this case, each and every program unit that uses
10458 the same @code{COMMON} area
10459 must specify the same layout of variables and their types
10461 and be compiled with @samp{-malign-double} as well.
10462 @code{g77} will issue warnings in each case,
10463 but as long as every program unit using that area
10464 is compiled with the same warnings,
10465 the resulting object files should work when linked together
10466 unless the program makes additional assumptions about
10467 @code{COMMON} area layouts that are outside the scope
10468 of the FORTRAN 77 standard,
10469 or uses @code{EQUIVALENCE} or different layouts
10470 in ways that assume no padding is ever inserted by the compiler.
10472 @emph{Note:} @samp{-malign-double} applies only to
10473 statically-allocated data.
10474 Double-precision data on the stack can still
10475 cause problems due to misalignment.
10476 @xref{Aligned Data}.
10479 Ensure that @file{crt0.o} or @file{crt1.o}
10480 on your system guarantees a 64-bit
10481 aligned stack for @code{main()}.
10482 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10483 but we don't know of any other x86 setups where it will be right.
10484 Read your system's documentation to determine if
10485 it is appropriate to upgrade to a more recent version
10486 to obtain the optimal alignment.
10489 Progress is being made on making this work
10490 ``out of the box'' on future versions of @code{g77},
10491 @code{gcc}, and some of the relevant operating systems
10492 (such as GNU/Linux).
10494 @node Prefer Automatic Uninitialized Variables
10495 @subsection Prefer Automatic Uninitialized Variables
10497 If you're using @samp{-fno-automatic} already, you probably
10498 should change your code to allow compilation with @samp{-fautomatic}
10499 (the default), to allow the program to run faster.
10501 Similarly, you should be able to use @samp{-fno-init-local-zero}
10502 (the default) instead of @samp{-finit-local-zero}.
10503 This is because it is rare that every variable affected by these
10504 options in a given program actually needs to
10507 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10508 every local non-automatic variable and array, affects even things like
10509 @code{DO} iteration
10510 variables, which rarely need to be @code{SAVE}d, and this often reduces
10511 run-time performances.
10512 Similarly, @samp{-fno-init-local-zero} forces such
10513 variables to be initialized to zero---when @code{SAVE}d (such as when
10514 @samp{-fno-automatic}), this by itself generally affects only
10515 startup time for a program, but when not @code{SAVE}d,
10516 it can slow down the procedure every time it is called.
10518 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10519 for information on the @samp{-fno-automatic} and
10520 @samp{-finit-local-zero} options and how to convert
10521 their use into selective changes in your own code.
10523 @node Avoid f2c Compatibility
10524 @subsection Avoid f2c Compatibility
10525 @cindex -fno-f2c option
10526 @cindex options, -fno-f2c
10527 @cindex @code{f2c} compatibility
10528 @cindex compatibility, @code{f2c}
10530 If you aren't linking with any code compiled using
10531 @code{f2c}, try using the @samp{-fno-f2c} option when
10532 compiling @emph{all} the code in your program.
10533 (Note that @code{libf2c} is @emph{not} an example of code
10534 that is compiled using @code{f2c}---it is compiled by a C
10535 compiler, typically @code{gcc}.)
10537 @node Use Submodel Options
10538 @subsection Use Submodel Options
10539 @cindex Pentium optimizations
10540 @cindex optimizations, Pentium
10541 @cindex 586/686 CPUs
10544 Using an appropriate @samp{-m} option to generate specific code for your
10545 CPU may be worthwhile, though it may mean the executable won't run on
10546 other versions of the CPU that don't support the same instruction set.
10547 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10550 For recent CPUs that don't have explicit support in
10551 the released version of @code{gcc}, it may still be possible to get
10553 For instance, the flags recommended for 586/686
10554 (Pentium(Pro)) chips for building the Linux kernel are:
10557 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
10558 -fomit-frame-pointer
10561 @noindent @samp{-fomit-frame-pointer} will, however, inhibit debugging
10565 @chapter Known Causes of Trouble with GNU Fortran
10566 @cindex bugs, known
10567 @cindex installation trouble
10568 @cindex known causes of trouble
10570 This section describes known problems that affect users of GNU Fortran.
10571 Most of these are not GNU Fortran bugs per se---if they were, we would
10573 But the result for a user might be like the result of a bug.
10575 Some of these problems are due to bugs in other software, some are
10576 missing features that are too much work to add, and some are places
10577 where people's opinions differ as to what is best.
10579 Information on bugs that show up when configuring, porting, building,
10580 or installing @code{g77} is not provided here.
10581 @xref{Problems Installing}.
10583 To find out about major bugs discovered in the current release and
10584 possible workarounds for them, retrieve
10585 @uref{ftp://alpha.gnu.org/g77.plan}.
10587 (Note that some of this portion of the manual is lifted
10588 directly from the @code{gcc} manual, with minor modifications
10589 to tailor it to users of @code{g77}.
10590 Anytime a bug seems to have more to do with the @code{gcc}
10591 portion of @code{g77},
10592 @xref{Trouble,,Known Causes of Trouble with GNU CC,
10593 gcc,Using and Porting GNU CC}.)
10596 * But-bugs:: Bugs really in other programs or elsewhere.
10597 * Actual Bugs:: Bugs and misfeatures we will fix later.
10598 * Missing Features:: Features we already know we want to add later.
10599 * Disappointments:: Regrettable things we can't change.
10600 * Non-bugs:: Things we think are right, but some others disagree.
10601 * Warnings and Errors:: Which problems in your code get warnings,
10602 and which get errors.
10606 @section Bugs Not In GNU Fortran
10609 These are bugs to which the maintainers often have to reply,
10610 ``but that isn't a bug in @code{g77}@dots{}''.
10611 Some of these already are fixed in new versions of other
10612 software; some still need to be fixed; some are problems
10613 with how @code{g77} is installed or is being used;
10614 some are the result of bad hardware that causes software
10615 to misbehave in sometimes bizarre ways;
10616 some just cannot be addressed at this time until more
10617 is known about the problem.
10619 Please don't re-report these bugs to the @code{g77} maintainers---if
10620 you must remind someone how important it is to you that the problem
10621 be fixed, talk to the people responsible for the other products
10622 identified below, but preferably only after you've tried the
10623 latest versions of those products.
10624 The @code{g77} maintainers have their hands full working on
10625 just fixing and improving @code{g77}, without serving as a
10626 clearinghouse for all bugs that happen to affect @code{g77}
10629 @xref{Collected Fortran Wisdom}, for information on behavior
10630 of Fortran programs, and the programs that compile them, that
10631 might be @emph{thought} to indicate bugs.
10634 * Signal 11 and Friends:: Strange behavior by any software.
10635 * Cannot Link Fortran Programs:: Unresolved references.
10636 * Large Common Blocks:: Problems on older GNU/Linux systems.
10637 * Debugger Problems:: When the debugger crashes.
10638 * NeXTStep Problems:: Misbehaving executables.
10639 * Stack Overflow:: More misbehaving executables.
10640 * Nothing Happens:: Less behaving executables.
10641 * Strange Behavior at Run Time:: Executables misbehaving due to
10642 bugs in your program.
10643 * Floating-point Errors:: The results look wrong, but@dots{}.
10646 @node Signal 11 and Friends
10647 @subsection Signal 11 and Friends
10649 @cindex hardware errors
10651 A whole variety of strange behaviors can occur when the
10652 software, or the way you are using the software,
10653 stresses the hardware in a way that triggers hardware bugs.
10654 This might seem hard to believe, but it happens frequently
10655 enough that there exist documents explaining in detail
10656 what the various causes of the problems are, what
10657 typical symptoms look like, and so on.
10659 Generally these problems are referred to in this document
10660 as ``signal 11'' crashes, because the Linux kernel, running
10661 on the most popular hardware (the Intel x86 line), often
10662 stresses the hardware more than other popular operating
10664 When hardware problems do occur under GNU/Linux on x86
10665 systems, these often manifest themselves as ``signal 11''
10666 problems, as illustrated by the following diagnostic:
10669 sh# @kbd{g77 myprog.f}
10670 gcc: Internal compiler error: program f771 got fatal signal 11
10674 It is @emph{very} important to remember that the above
10675 message is @emph{not} the only one that indicates a
10676 hardware problem, nor does it always indicate a hardware
10679 In particular, on systems other than those running the Linux
10680 kernel, the message might appear somewhat or very different,
10681 as it will if the error manifests itself while running a
10682 program other than the @code{g77} compiler.
10684 it will appear somewhat different when running your program,
10685 when running Emacs, and so on.
10687 How to cope with such problems is well beyond the scope
10690 However, users of Linux-based systems (such as GNU/Linux)
10691 should review @uref{http://www.bitwizard.nl/sig11}, a source
10692 of detailed information on diagnosing hardware problems,
10693 by recognizing their common symptoms.
10695 Users of other operating systems and hardware might
10696 find this reference useful as well.
10697 If you know of similar material for another hardware/software
10698 combination, please let us know so we can consider including
10699 a reference to it in future versions of this manual.
10701 @node Cannot Link Fortran Programs
10702 @subsection Cannot Link Fortran Programs
10703 @cindex unresolved reference (various)
10704 @cindex linking error for user code
10706 @cindex ld error for user code
10707 @cindex ld can't find strange names
10708 On some systems, perhaps just those with out-of-date (shared?)
10709 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10710 programs (which should be done using @code{g77}).
10712 If this happens to you, try appending @samp{-lc} to the command you
10713 use to link the program, e.g. @samp{g77 foo.f -lc}.
10714 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10715 but it cannot also specify @samp{-lc} because not all systems have a
10716 file named @file{libc.a}.
10718 It is unclear at this point whether there are legitimately installed
10719 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10722 @cindex undefined reference (_main)
10723 @cindex linking error for user code
10724 @cindex ld error for user code
10726 @cindex ld can't find _main
10727 If your program doesn't link due to unresolved references to names
10728 like @samp{_main}, make sure you're using the @code{g77} command to do the
10729 link, since this command ensures that the necessary libraries are
10730 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10731 command to do the actual link.
10732 (Use the @samp{-v} option to discover
10733 more about what actually happens when you use the @code{g77} and @code{gcc}
10736 Also, try specifying @samp{-lc} as the last item on the @code{g77}
10737 command line, in case that helps.
10739 @node Large Common Blocks
10740 @subsection Large Common Blocks
10741 @cindex common blocks, large
10742 @cindex large common blocks
10743 @cindex linker errors
10745 @cindex errors, linker
10746 On some older GNU/Linux systems, programs with common blocks larger
10747 than 16MB cannot be linked without some kind of error
10748 message being produced.
10750 This is a bug in older versions of @code{ld}, fixed in
10751 more recent versions of @code{binutils}, such as version 2.6.
10753 @node Debugger Problems
10754 @subsection Debugger Problems
10755 @cindex @code{gdb} support
10756 @cindex support, @code{gdb}
10757 There are some known problems when using @code{gdb} on code
10758 compiled by @code{g77}.
10759 Inadequate investigation as of the release of 0.5.16 results in not
10760 knowing which products are the culprit, but @file{gdb-4.14} definitely
10761 crashes when, for example, an attempt is made to print the contents
10762 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
10763 machines, plus some others.
10764 Attempts to access assumed-size arrays are
10765 also known to crash recent versions of @code{gdb}.
10766 (@code{gdb}'s Fortran support was done for a different compiler
10767 and isn't properly compatible with @code{g77}.)
10769 @node NeXTStep Problems
10770 @subsection NeXTStep Problems
10771 @cindex NeXTStep problems
10773 @cindex segmentation violation
10774 Developers of Fortran code on NeXTStep (all architectures) have to
10775 watch out for the following problem when writing programs with
10776 large, statically allocated (i.e. non-stack based) data structures
10777 (common blocks, saved arrays).
10779 Due to the way the native loader (@file{/bin/ld}) lays out
10780 data structures in virtual memory, it is very easy to create an
10781 executable wherein the @samp{__DATA} segment overlaps (has addresses in
10782 common) with the @samp{UNIX STACK} segment.
10784 This leads to all sorts of trouble, from the executable simply not
10785 executing, to bus errors.
10786 The NeXTStep command line tool @code{ebadexec} points to
10787 the problem as follows:
10790 % @kbd{/bin/ebadexec a.out}
10791 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
10792 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
10793 STACK segment (truncated address = 0x400000 rounded size =
10794 0x3c00000) of executable file: a.out
10797 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
10800 This can be cured by assigning the @samp{__DATA} segment
10801 (virtual) addresses beyond the stack segment.
10803 estimate for this is from address 6000000 (hexadecimal) onwards---this
10804 has always worked for me [Toon Moene]:
10807 % @kbd{g77 -segaddr __DATA 6000000 test.f}
10808 % @kbd{ebadexec a.out}
10809 ebadexec: file: a.out appears to be executable
10813 Browsing through @file{@value{path-g77}/Makefile.in},
10814 you will find that the @code{f771} program itself also has to be
10815 linked with these flags---it has large statically allocated
10817 (Version 0.5.18 reduces this somewhat, but probably
10820 (The above item was contributed by Toon Moene
10821 (@email{toon@@moene.indiv.nluug.nl}).)
10823 @node Stack Overflow
10824 @subsection Stack Overflow
10825 @cindex stack overflow
10826 @cindex segmentation violation
10827 @code{g77} code might fail at runtime (probably with a ``segmentation
10828 violation'') due to overflowing the stack.
10829 This happens most often on systems with an environment
10830 that provides substantially more heap space (for use
10831 when arbitrarily allocating and freeing memory) than stack
10834 Often this can be cured by
10835 increasing or removing your shell's limit on stack usage, typically
10836 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
10837 @kbd{ulimit -s} (in @code{sh} and derivatives).
10839 Increasing the allowed stack size might, however, require
10840 changing some operating system or system configuration parameters.
10842 You might be able to work around the problem by compiling with the
10843 @samp{-fno-automatic} option to reduce stack usage, probably at the
10846 @xref{Maximum Stackable Size}, for information on patching
10847 @code{g77} to use different criteria for placing local
10848 non-automatic variables and arrays on the stack.
10850 @cindex automatic arrays
10851 @cindex arrays, automatic
10852 However, if your program uses large automatic arrays
10853 (for example, has declarations like @samp{REAL A(N)} where
10854 @samp{A} is a local array and @samp{N} is a dummy or
10855 @code{COMMON} variable that can have a large value),
10856 neither use of @samp{-fno-automatic},
10857 nor changing the cut-off point for @code{g77} for using the stack,
10858 will solve the problem by changing the placement of these
10859 large arrays, as they are @emph{necessarily} automatic.
10861 @code{g77} currently provides no means to specify that
10862 automatic arrays are to be allocated on the heap instead
10864 So, other than increasing the stack size, your best bet is to
10865 change your source code to avoid large automatic arrays.
10866 Methods for doing this currently are outside the scope of
10869 (@emph{Note:} If your system puts stack and heap space in the
10870 same memory area, such that they are effectively combined, then
10871 a stack overflow probably indicates a program that is either
10872 simply too large for the system, or buggy.)
10874 @node Nothing Happens
10875 @subsection Nothing Happens
10876 @cindex nothing happens
10877 @cindex naming programs @samp{test}
10878 @cindex @samp{test} programs
10879 @cindex programs named @samp{test}
10880 It is occasionally reported that a ``simple'' program,
10881 such as a ``Hello, World!'' program, does nothing when
10882 it is run, even though the compiler reported no errors,
10883 despite the program containing nothing other than a
10884 simple @code{PRINT} statement.
10886 This most often happens because the program has been
10887 compiled and linked on a UNIX system and named @samp{test},
10888 though other names can lead to similarly unexpected
10889 run-time behavior on various systems.
10891 Essentially this problem boils down to giving
10892 your program a name that is already known to
10893 the shell you are using to identify some other program,
10894 which the shell continues to execute instead of your
10895 program when you invoke it via, for example:
10902 Under UNIX and many other system, a simple command name
10903 invokes a searching mechanism that might well not choose
10904 the program located in the current working directory if
10905 there is another alternative (such as the @code{test}
10906 command commonly installed on UNIX systems).
10908 The reliable way to invoke a program you just linked in
10909 the current directory under UNIX is to specify it using
10910 an explicit pathname, as in:
10918 Users who encounter this problem should take the time to
10919 read up on how their shell searches for commands, how to
10920 set their search path, and so on.
10921 The relevant UNIX commands to learn about include
10922 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
10923 @code{set} and @code{env}), @code{which}, and @code{find}.
10925 @node Strange Behavior at Run Time
10926 @subsection Strange Behavior at Run Time
10927 @cindex segmentation violation
10929 @cindex overwritten data
10930 @cindex data, overwritten
10931 @code{g77} code might fail at runtime with ``segmentation violation'',
10932 ``bus error'', or even something as subtle as a procedure call
10933 overwriting a variable or array element that it is not supposed
10936 These can be symptoms of a wide variety of actual bugs that
10937 occurred earlier during the program's run, but manifested
10938 themselves as @emph{visible} problems some time later.
10940 Overflowing the bounds of an array---usually by writing beyond
10941 the end of it---is one of two kinds of bug that often occurs
10944 The other kind of bug is a mismatch between the actual arguments
10945 passed to a procedure and the dummy arguments as declared by that
10948 Both of these kinds of bugs, and some others as well, can be
10949 difficult to track down, because the bug can change its behavior,
10950 or even appear to not occur, when using a debugger.
10952 That is, these bugs can be quite sensitive to data, including
10953 data representing the placement of other data in memory (that is,
10954 pointers, such as the placement of stack frames in memory).
10956 Plans call for improving @code{g77} so that it can offer the
10957 ability to catch and report some of these problems at compile, link, or
10958 run time, such as by generating code to detect references to
10959 beyond the bounds of an array, or checking for agreement between
10960 calling and called procedures.
10962 In the meantime, finding and fixing the programming
10963 bugs that lead to these behaviors is, ultimately, the user's
10964 responsibility, as difficult as that task can sometimes be.
10966 @cindex ``infinite spaces'' printed
10967 @cindex spaces, endless printing of
10968 @cindex libc, non-ANSI or non-default
10970 @cindex linking against non-standard library
10972 One runtime problem that has been observed might have a simple solution.
10973 If a formatted @code{WRITE} produces an endless stream of spaces, check
10974 that your program is linked against the correct version of the C library.
10975 The configuration process takes care to account for your
10976 system's normal @file{libc} not being ANSI-standard, which will
10977 otherwise cause this behaviour.
10978 If your system's default library is
10979 ANSI-standard and you subsequently link against a non-ANSI one, there
10980 might be problems such as this one.
10982 Specifically, on Solaris2 systems,
10983 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
10985 @node Floating-point Errors
10986 @subsection Floating-point Errors
10987 @cindex floating-point errors
10988 @cindex rounding errors
10989 @cindex inconsistent floating-point results
10990 @cindex results, inconsistent
10991 Some programs appear to produce inconsistent floating-point
10992 results compiled by @code{g77} versus by other compilers.
10994 Often the reason for this behavior is the fact that floating-point
10995 values are represented on almost all Fortran systems by
10996 @emph{approximations}, and these approximations are inexact
10997 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
10998 0.7, 0.8, 0.9, 1.1, and so on.
10999 Most Fortran systems, including all current ports of @code{g77},
11000 use binary arithmetic to represent these approximations.
11002 Therefore, the exact value of any floating-point approximation
11003 as manipulated by @code{g77}-compiled code is representable by
11004 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11005 so on (just keep dividing by two) through the precision of the
11006 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11007 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11008 power of two (in Fortran, by @samp{2**N}) that typically is between
11009 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11010 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11013 So, a value like 0.2 is exactly represented in decimal---since
11014 it is a fraction, @samp{2/10}, with a denominator that is compatible
11015 with the base of the number system (base 10).
11016 However, @samp{2/10} cannot be represented by any finite number
11017 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11018 be exactly represented in binary notation.
11020 (On the other hand, decimal notation can represent any binary
11021 number in a finite number of digits.
11022 Decimal notation cannot do so with ternary, or base-3,
11023 notation, which would represent floating-point numbers as
11024 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11025 After all, no finite number of decimal digits can exactly
11026 represent @samp{1/3}.
11027 Fortunately, few systems use ternary notation.)
11029 Moreover, differences in the way run-time I/O libraries convert
11030 between these approximations and the decimal representation often
11031 used by programmers and the programs they write can result in
11032 apparent differences between results that do not actually exist,
11033 or exist to such a small degree that they usually are not worth
11036 For example, consider the following program:
11043 When compiled by @code{g77}, the above program might output
11044 @samp{0.20000003}, while another compiler might produce a
11045 executable that outputs @samp{0.2}.
11047 This particular difference is due to the fact that, currently,
11048 conversion of floating-point values by the @code{libg2c} library,
11049 used by @code{g77}, handles only double-precision values.
11051 Since @samp{0.2} in the program is a single-precision value, it
11052 is converted to double precision (still in binary notation)
11053 before being converted back to decimal.
11054 The conversion to binary appends _binary_ zero digits to the
11055 original value---which, again, is an inexact approximation of
11056 0.2---resulting in an approximation that is much less exact
11057 than is connoted by the use of double precision.
11059 (The appending of binary zero digits has essentially the same
11060 effect as taking a particular decimal approximation of
11061 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11062 zeros to it, producing @samp{0.33333330000000000}.
11063 Treating the resulting decimal approximation as if it really
11064 had 18 or so digits of valid precision would make it seem
11065 a very poor approximation of @samp{1/3}.)
11067 As a result of converting the single-precision approximation
11068 to double precision by appending binary zeros, the conversion
11069 of the resulting double-precision
11070 value to decimal produces what looks like an incorrect
11071 result, when in fact the result is @emph{inexact}, and
11072 is probably no less inaccurate or imprecise an approximation
11073 of 0.2 than is produced by other compilers that happen to output
11074 the converted value as ``exactly'' @samp{0.2}.
11075 (Some compilers behave in a way that can make them appear
11076 to retain more accuracy across a conversion of a single-precision
11077 constant to double precision.
11078 @xref{Context-Sensitive Constants}, to see why
11079 this practice is illusory and even dangerous.)
11081 Note that a more exact approximation of the constant is
11082 computed when the program is changed to specify a
11083 double-precision constant:
11090 Future versions of @code{g77} and/or @code{libg2c} might convert
11091 single-precision values directly to decimal,
11092 instead of converting them to double precision first.
11093 This would tend to result in output that is more consistent
11094 with that produced by some other Fortran implementations.
11098 @node Missing Features
11099 @section Missing Features
11101 This section lists features we know are missing from @code{g77},
11102 and which we want to add someday.
11103 (There is no priority implied in the ordering below.)
11106 GNU Fortran language:
11107 * Better Source Model::
11108 * Fortran 90 Support::
11109 * Intrinsics in PARAMETER Statements::
11110 * SELECT CASE on CHARACTER Type::
11111 * RECURSIVE Keyword::
11112 * Popular Non-standard Types::
11113 * Full Support for Compiler Types::
11114 * Array Bounds Expressions::
11115 * POINTER Statements::
11116 * Sensible Non-standard Constructs::
11117 * FLUSH Statement::
11118 * Expressions in FORMAT Statements::
11119 * Explicit Assembler Code::
11120 * Q Edit Descriptor::
11122 GNU Fortran dialects:
11123 * Old-style PARAMETER Statements::
11124 * TYPE and ACCEPT I/O Statements::
11125 * STRUCTURE UNION RECORD MAP::
11126 * OPEN CLOSE and INQUIRE Keywords::
11127 * ENCODE and DECODE::
11128 * Suppressing Space Padding::
11129 * Fortran Preprocessor::
11130 * Bit Operations on Floating-point Data::
11134 * Floating-point Exception Handling::
11135 * Nonportable Conversions::
11136 * Large Automatic Arrays::
11137 * Support for Threads::
11138 * Increasing Precision/Range::
11140 Better diagnostics:
11141 * Gracefully Handle Sensible Bad Code::
11142 * Non-standard Conversions::
11143 * Non-standard Intrinsics::
11144 * Modifying DO Variable::
11145 * Better Pedantic Compilation::
11146 * Warn About Implicit Conversions::
11147 * Invalid Use of Hollerith Constant::
11148 * Dummy Array Without Dimensioning Dummy::
11149 * Invalid FORMAT Specifiers::
11150 * Ambiguous Dialects::
11152 * Informational Messages::
11154 Run-time facilities:
11155 * Uninitialized Variables at Run Time::
11156 * Bounds Checking at Run Time::
11159 * Labels Visible to Debugger::
11162 @node Better Source Model
11163 @subsection Better Source Model
11165 @code{g77} needs to provide, as the default source-line model,
11166 a ``pure visual'' mode, where
11167 the interpretation of a source program in this mode can be accurately
11168 determined by a user looking at a traditionally displayed rendition
11169 of the program (assuming the user knows whether the program is fixed
11172 The design should assume the user cannot tell tabs from spaces
11173 and cannot see trailing spaces on lines, but has canonical tab stops
11174 and, for fixed-form source, has the ability to always know exactly
11175 where column 72 is (since the Fortran standard itself requires
11176 this for fixed-form source).
11178 This would change the default treatment of fixed-form source
11179 to not treat lines with tabs as if they were infinitely long---instead,
11180 they would end at column 72 just as if the tabs were replaced
11181 by spaces in the canonical way.
11183 As part of this, provide common alternate models (Digital, @code{f2c},
11184 and so on) via command-line options.
11185 This includes allowing arbitrarily long
11186 lines for free-form source as well as fixed-form source and providing
11187 various limits and diagnostics as appropriate.
11189 @cindex sequence numbers
11190 @cindex columns 73 through 80
11191 Also, @code{g77} should offer, perhaps even default to, warnings
11192 when characters beyond the last valid column are anything other
11194 This would mean code with ``sequence numbers'' in columns 73 through 80
11195 would be rejected, and there's a lot of that kind of code around,
11196 but one of the most frequent bugs encountered by new users is
11197 accidentally writing fixed-form source code into and beyond
11199 So, maybe the users of old code would be able to more easily handle
11200 having to specify, say, a @code{-Wno-col73to80} option.
11202 @node Fortran 90 Support
11203 @subsection Fortran 90 Support
11204 @cindex Fortran 90 support
11205 @cindex support, Fortran 90
11207 @code{g77} does not support many of the features that
11208 distinguish Fortran 90 (and, now, Fortran 95) from
11211 Some Fortran 90 features are supported, because they
11212 make sense to offer even to die-hard users of F77.
11213 For example, many of them codify various ways F77 has
11214 been extended to meet users' needs during its tenure,
11215 so @code{g77} might as well offer them as the primary
11216 way to meet those same needs, even if it offers compatibility
11217 with one or more of the ways those needs were met
11218 by other F77 compilers in the industry.
11220 Still, many important F90 features are not supported,
11221 because no attempt has been made to research each and
11222 every feature and assess its viability in @code{g77}.
11223 In the meantime, users who need those features must
11224 use Fortran 90 compilers anyway, and the best approach
11225 to adding some F90 features to GNU Fortran might well be
11226 to fund a comprehensive project to create GNU Fortran 95.
11228 @node Intrinsics in PARAMETER Statements
11229 @subsection Intrinsics in @code{PARAMETER} Statements
11230 @cindex PARAMETER statement
11231 @cindex statements, PARAMETER
11233 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11234 This feature is considered to be absolutely vital, even though it
11235 is not standard-conforming, and is scheduled for version 0.6.
11237 Related to this, @code{g77} doesn't allow non-integral
11238 exponentiation in @code{PARAMETER} statements, such as
11239 @samp{PARAMETER (R=2**.25)}.
11240 It is unlikely @code{g77} will ever support this feature,
11241 as doing it properly requires complete emulation of
11242 a target computer's floating-point facilities when
11243 building @code{g77} as a cross-compiler.
11244 But, if the @code{gcc} back end is enhanced to provide
11245 such a facility, @code{g77} will likely use that facility
11246 in implementing this feature soon afterwards.
11248 @node SELECT CASE on CHARACTER Type
11249 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11251 Character-type selector/cases for @code{SELECT CASE} currently
11254 @node RECURSIVE Keyword
11255 @subsection @code{RECURSIVE} Keyword
11256 @cindex RECURSIVE keyword
11257 @cindex keywords, RECURSIVE
11258 @cindex recursion, lack of
11259 @cindex lack of recursion
11261 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11263 Nor does it provide any means for compiling procedures
11264 designed to do recursion.
11266 All recursive code can be rewritten to not use recursion,
11267 but the result is not pretty.
11269 @node Increasing Precision/Range
11270 @subsection Increasing Precision/Range
11274 @cindex increasing precision
11275 @cindex precision, increasing
11276 @cindex increasing range
11277 @cindex range, increasing
11281 Some compilers, such as @code{f2c}, have an option (@samp{-r8} or
11282 similar) that provides automatic treatment of @code{REAL}
11283 entities such that they have twice the storage size, and
11284 a corresponding increase in the range and precision, of what
11285 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11286 (This affects @code{COMPLEX} the same way.)
11288 They also typically offer another option (@samp{-i8}) to increase
11289 @code{INTEGER} entities so they are twice as large
11290 (with roughly twice as much range).
11292 (There are potential pitfalls in using these options.)
11294 @code{g77} does not yet offer any option that performs these
11295 kinds of transformations.
11296 Part of the problem is the lack of detailed specifications regarding
11297 exactly how these options affect the interpretation of constants,
11298 intrinsics, and so on.
11300 Until @code{g77} addresses this need, programmers could improve
11301 the portability of their code by modifying it to not require
11302 compile-time options to produce correct results.
11303 Some free tools are available which may help, specifically
11304 in Toolpack (which one would expect to be sound) and the @file{fortran}
11305 section of the Netlib repository.
11307 Use of preprocessors can provide a fairly portable means
11308 to work around the lack of widely portable methods in the Fortran
11309 language itself (though increasing acceptance of Fortran 90 would
11310 alleviate this problem).
11312 @node Popular Non-standard Types
11313 @subsection Popular Non-standard Types
11314 @cindex INTEGER*2 support
11315 @cindex LOGICAL*1 support
11317 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11319 Version 0.6 will provide full support for this very
11320 popular set of features.
11321 In the meantime, version 0.5.18 provides rudimentary support
11324 @node Full Support for Compiler Types
11325 @subsection Full Support for Compiler Types
11327 @cindex REAL*16 support
11328 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11329 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11330 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11331 This means providing intrinsic support, and maybe constant
11332 support (using F90 syntax) as well, and, for most
11333 machines will result in automatic support of @code{INTEGER*1},
11334 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11336 This is scheduled for version 0.6.
11338 @node Array Bounds Expressions
11339 @subsection Array Bounds Expressions
11340 @cindex array elements, in adjustable array bounds
11341 @cindex function references, in adjustable array bounds
11342 @cindex array bounds, adjustable
11343 @cindex DIMENSION statement
11344 @cindex statements, DIMENSION
11346 @code{g77} doesn't support more general expressions to dimension
11347 arrays, such as array element references, function
11350 For example, @code{g77} currently does not accept the following:
11354 INTEGER N(10), M(N(2), N(1))
11357 @node POINTER Statements
11358 @subsection POINTER Statements
11359 @cindex POINTER statement
11360 @cindex statements, POINTER
11361 @cindex Cray pointers
11363 @code{g77} doesn't support pointers or allocatable objects
11364 (other than automatic arrays).
11365 This set of features is
11366 probably considered just behind intrinsics
11367 in @code{PARAMETER} statements on the list of large,
11368 important things to add to @code{g77}.
11370 In the meantime, consider using the @code{INTEGER(KIND=7)}
11371 declaration to specify that a variable must be
11372 able to hold a pointer.
11373 This construct is not portable to other non-GNU compilers,
11374 but it is portable to all machines GNU Fortran supports
11375 when @code{g77} is used.
11377 @xref{Functions and Subroutines}, for information on
11378 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11379 constructs, which are useful for passing pointers to
11380 procedures written in languages other than Fortran.
11382 @node Sensible Non-standard Constructs
11383 @subsection Sensible Non-standard Constructs
11385 @code{g77} rejects things other compilers accept,
11386 like @samp{INTRINSIC SQRT,SQRT}.
11387 As time permits in the future, some of these things that are easy for
11388 humans to read and write and unlikely to be intended to mean something
11389 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11390 trigger warnings about such non-standard constructs).
11392 Until @code{g77} no longer gratuitously rejects sensible code,
11393 you might as well fix your code
11394 to be more standard-conforming and portable.
11396 The kind of case that is important to except from the
11397 recommendation to change your code is one where following
11398 good coding rules would force you to write non-standard
11399 code that nevertheless has a clear meaning.
11401 For example, when writing an @code{INCLUDE} file that
11402 defines a common block, it might be appropriate to
11403 include a @code{SAVE} statement for the common block
11404 (such as @samp{SAVE /CBLOCK/}), so that variables
11405 defined in the common block retain their values even
11406 when all procedures declaring the common block become
11407 inactive (return to their callers).
11409 However, putting @code{SAVE} statements in an @code{INCLUDE}
11410 file would prevent otherwise standard-conforming code
11411 from also specifying the @code{SAVE} statement, by itself,
11412 to indicate that all local variables and arrays are to
11413 have the @code{SAVE} attribute.
11415 For this reason, @code{g77} already has been changed to
11416 allow this combination, because although the general
11417 problem of gratuitously rejecting unambiguous and
11418 ``safe'' constructs still exists in @code{g77}, this
11419 particular construct was deemed useful enough that
11420 it was worth fixing @code{g77} for just this case.
11422 So, while there is no need to change your code
11423 to avoid using this particular construct, there
11424 might be other, equally appropriate but non-standard
11425 constructs, that you shouldn't have to stop using
11426 just because @code{g77} (or any other compiler)
11427 gratuitously rejects it.
11429 Until the general problem is solved, if you have
11430 any such construct you believe is worthwhile
11431 using (e.g. not just an arbitrary, redundant
11432 specification of an attribute), please submit a
11433 bug report with an explanation, so we can consider
11434 fixing @code{g77} just for cases like yours.
11436 @node FLUSH Statement
11437 @subsection @code{FLUSH} Statement
11439 @code{g77} could perhaps use a @code{FLUSH} statement that
11440 does what @samp{CALL FLUSH} does,
11441 but that supports @samp{*} as the unit designator (same unit as for
11442 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11445 @node Expressions in FORMAT Statements
11446 @subsection Expressions in @code{FORMAT} Statements
11447 @cindex FORMAT statement
11448 @cindex statements, FORMAT
11450 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11451 Supporting this requires a significant redesign or replacement
11454 However, @code{g77} does support
11455 this construct when the expression is constant
11456 (as of version 0.5.22).
11460 PARAMETER (IWIDTH = 12)
11461 10 FORMAT (I<IWIDTH>)
11464 Otherwise, at least for output (@code{PRINT} and
11465 @code{WRITE}), Fortran code making use of this feature can
11466 be rewritten to avoid it by constructing the @code{FORMAT}
11467 string in a @code{CHARACTER} variable or array, then
11468 using that variable or array in place of the @code{FORMAT}
11469 statement label to do the original @code{PRINT} or @code{WRITE}.
11471 Many uses of this feature on input can be rewritten this way
11472 as well, but not all can.
11473 For example, this can be rewritten:
11480 However, this cannot, in general, be rewritten, especially
11481 when @code{ERR=} and @code{END=} constructs are employed:
11488 @node Explicit Assembler Code
11489 @subsection Explicit Assembler Code
11491 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11492 code to specify explicit assembler code.
11494 @node Q Edit Descriptor
11495 @subsection Q Edit Descriptor
11496 @cindex FORMAT statement
11497 @cindex Q edit descriptor
11499 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11500 (This is meant to get the number of characters remaining in an input record.)
11501 Supporting this requires a significant redesign or replacement
11504 A workaround might be using internal I/O or the stream-based intrinsics.
11505 @xref{FGetC Intrinsic (subroutine)}.
11507 @node Old-style PARAMETER Statements
11508 @subsection Old-style PARAMETER Statements
11509 @cindex PARAMETER statement
11510 @cindex statements, PARAMETER
11512 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11513 Supporting this obsolete form of
11514 the @code{PARAMETER} statement would not be particularly hard, as most of the
11515 parsing code is already in place and working.
11517 Until time/money is
11518 spent implementing it, you might as well fix your code to use the
11519 standard form, @samp{PARAMETER (I=1)} (possibly needing
11520 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11521 otherwise, in the obsolete form of @code{PARAMETER}, the
11522 type of the variable is set from the type of the constant being
11525 @node TYPE and ACCEPT I/O Statements
11526 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11527 @cindex TYPE statement
11528 @cindex statements, TYPE
11529 @cindex ACCEPT statement
11530 @cindex statements, ACCEPT
11532 @code{g77} doesn't support the I/O statements @code{TYPE} and
11534 These are common extensions that should be easy to support,
11535 but also are fairly easy to work around in user code.
11537 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11538 by @samp{PRINT fmt,list}.
11539 And, any @samp{ACCEPT fmt,list} statement can be
11540 replaced by @samp{READ fmt,list}.
11542 @node STRUCTURE UNION RECORD MAP
11543 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11544 @cindex STRUCTURE statement
11545 @cindex statements, STRUCTURE
11546 @cindex UNION statement
11547 @cindex statements, UNION
11548 @cindex RECORD statement
11549 @cindex statements, RECORD
11550 @cindex MAP statement
11551 @cindex statements, MAP
11553 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11555 This set of extensions is quite a bit
11556 lower on the list of large, important things to add to @code{g77}, partly
11557 because it requires a great deal of work either upgrading or
11558 replacing @code{libg2c}.
11560 @node OPEN CLOSE and INQUIRE Keywords
11561 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11562 @cindex disposition of files
11563 @cindex OPEN statement
11564 @cindex statements, OPEN
11565 @cindex CLOSE statement
11566 @cindex statements, CLOSE
11567 @cindex INQUIRE statement
11568 @cindex statements, INQUIRE
11570 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11571 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11572 These extensions are easy to add to @code{g77} itself, but
11573 require much more work on @code{libg2c}.
11575 @node ENCODE and DECODE
11576 @subsection @code{ENCODE} and @code{DECODE}
11577 @cindex ENCODE statement
11578 @cindex statements, ENCODE
11579 @cindex DECODE statement
11580 @cindex statements, DECODE
11582 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11584 These statements are best replaced by READ and WRITE statements
11585 involving internal files (CHARACTER variables and arrays).
11587 For example, replace a code fragment like
11592 DECODE (80, 9000, LINE) A, B, C
11594 9000 FORMAT (1X, 3(F10.5))
11603 READ (UNIT=LINE, FMT=9000) A, B, C
11605 9000 FORMAT (1X, 3(F10.5))
11608 Similarly, replace a code fragment like
11613 ENCODE (80, 9000, LINE) A, B, C
11615 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11624 WRITE (UNIT=LINE, FMT=9000) A, B, C
11626 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11629 It is entirely possible that @code{ENCODE} and @code{DECODE} will
11630 be supported by a future version of @code{g77}.
11632 @node Suppressing Space Padding
11633 @subsection Suppressing Space Padding of Source Lines
11635 @code{g77} should offer VXT-Fortran-style suppression of virtual
11636 spaces at the end of a source line
11637 if an appropriate command-line option is specified.
11639 This affects cases where
11640 a character constant is continued onto the next line in a fixed-form
11641 source file, as in the following example:
11644 10 PRINT *,'HOW MANY
11649 @code{g77}, and many other compilers, virtually extend
11650 the continued line through column 72 with spaces that become part
11651 of the character constant, but Digital Fortran normally didn't,
11652 leaving only one space between @samp{MANY} and @samp{SPACES?}
11653 in the output of the above statement.
11655 Fairly recently, at least one version of Digital Fortran
11656 was enhanced to provide the other behavior when a
11657 command-line option is specified, apparently due to demand
11658 from readers of the USENET group @file{comp.lang.fortran}
11659 to offer conformance to this widespread practice in the
11661 @code{g77} should return the favor by offering conformance
11662 to Digital's approach to handling the above example.
11664 @node Fortran Preprocessor
11665 @subsection Fortran Preprocessor
11667 @code{g77} should offer a preprocessor designed specifically
11668 for Fortran to replace @samp{cpp -traditional}.
11669 There are several out there worth evaluating, at least.
11671 Such a preprocessor would recognize Hollerith constants,
11672 properly parse comments and character constants, and so on.
11673 It might also recognize, process, and thus preprocess
11674 files included via the @code{INCLUDE} directive.
11676 @node Bit Operations on Floating-point Data
11677 @subsection Bit Operations on Floating-point Data
11678 @cindex AND intrinsic
11679 @cindex intrinsics, AND
11680 @cindex OR intrinsic
11681 @cindex intrinsics, OR
11682 @cindex SHIFT intrinsic
11683 @cindex intrinsics, SHIFT
11685 @code{g77} does not allow @code{REAL} and other non-integral types for
11686 arguments to intrinsics like @code{AND}, @code{OR}, and @code{SHIFT}.
11688 For example, this program is rejected by @code{g77}, because
11689 the intrinsic @code{IAND} does not accept @code{REAL} arguments:
11692 DATA A/7.54/, B/9.112/
11693 PRINT *, IAND(A, B)
11697 @node POSIX Standard
11698 @subsection @code{POSIX} Standard
11700 @code{g77} should support the POSIX standard for Fortran.
11702 @node Floating-point Exception Handling
11703 @subsection Floating-point Exception Handling
11704 @cindex floating point exceptions
11705 @cindex exceptions, floating point
11706 @cindex FPE handling
11709 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
11710 control over whether or not floating-point exceptions are trapped or
11712 (Ignoring them typically results in NaN values being
11713 propagated in systems that conform to IEEE 754.)
11714 The behaviour is inherited from the system-dependent startup code.
11716 Most systems provide some C-callable mechanism to change this; this can
11717 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
11718 For example, just compiling and linking the following C code with your
11719 program will turn on exception trapping for the ``common'' exceptions
11720 on an x86-based GNU system:
11723 #include <fpu_control.h>
11724 void __attribute__ ((constructor))
11726 (void) __setfpucw (_FPU_DEFAULT &
11727 ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
11731 @node Nonportable Conversions
11732 @subsection Nonportable Conversions
11733 @cindex nonportable conversions
11734 @cindex conversions, nonportable
11736 @code{g77} doesn't accept some particularly nonportable,
11737 silent data-type conversions such as @code{LOGICAL}
11738 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
11739 is type @code{REAL}), that other compilers might
11742 Some of these conversions are accepted by @code{g77}
11743 when the @samp{-fugly} option is specified.
11744 Perhaps it should accept more or all of them.
11746 @node Large Automatic Arrays
11747 @subsection Large Automatic Arrays
11748 @cindex automatic arrays
11749 @cindex arrays, automatic
11751 Currently, automatic arrays always are allocated on the stack.
11752 For situations where the stack cannot be made large enough,
11753 @code{g77} should offer a compiler option that specifies
11754 allocation of automatic arrays in heap storage.
11756 @node Support for Threads
11757 @subsection Support for Threads
11759 @cindex parallel processing
11761 Neither the code produced by @code{g77} nor the @code{libg2c} library
11762 are thread-safe, nor does @code{g77} have support for parallel processing
11763 (other than the instruction-level parallelism available on some
11765 A package such as PVM might help here.
11767 @node Gracefully Handle Sensible Bad Code
11768 @subsection Gracefully Handle Sensible Bad Code
11770 @code{g77} generally should continue processing for
11771 warnings and recoverable (user) errors whenever possible---that
11772 is, it shouldn't gratuitously make bad or useless code.
11783 When compiling the above with @samp{-ff2c-intrinsics-disable},
11784 @code{g77} should indeed complain about passing @code{ZABS},
11785 but it still should compile, instead of rejecting
11786 the entire @code{CALL} statement.
11787 (Some of this is related to improving
11788 the compiler internals to improve how statements are analyzed.)
11790 @node Non-standard Conversions
11791 @subsection Non-standard Conversions
11793 @samp{-Wconversion} and related should flag places where non-standard
11794 conversions are found.
11795 Perhaps much of this would be part of @samp{-Wugly*}.
11797 @node Non-standard Intrinsics
11798 @subsection Non-standard Intrinsics
11800 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
11801 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
11802 This would help find code that might fail silently when ported to another
11805 @node Modifying DO Variable
11806 @subsection Modifying @code{DO} Variable
11808 @code{g77} should warn about modifying @code{DO} variables
11809 via @code{EQUIVALENCE}.
11810 (The internal information gathered to produce this warning
11811 might also be useful in setting the
11812 internal ``doiter'' flag for a variable or even array
11813 reference within a loop, since that might produce faster code someday.)
11815 For example, this code is invalid, so @code{g77} should warn about
11816 the invalid assignment to @samp{NOTHER}:
11819 EQUIVALENCE (I, NOTHER)
11821 IF (I.EQ. 10) NOTHER = 20
11825 @node Better Pedantic Compilation
11826 @subsection Better Pedantic Compilation
11828 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
11829 and use it only to generate
11830 warnings instead of rejecting constructs outright.
11832 if a variable that dimensions an array is not a dummy or placed
11833 explicitly in @code{COMMON} (F77 does not allow it to be
11834 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
11835 follow statement-function-definition statements; about all sorts of
11836 syntactic extensions.
11838 @node Warn About Implicit Conversions
11839 @subsection Warn About Implicit Conversions
11841 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
11842 to expect automatic, silent, and
11843 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
11844 constants to @code{REAL(KIND=2)} based on context.
11846 For example, it would warn about cases like this:
11849 DOUBLE PRECISION FOO
11850 PARAMETER (TZPHI = 9.435784839284958)
11854 @node Invalid Use of Hollerith Constant
11855 @subsection Invalid Use of Hollerith Constant
11857 @code{g77} should disallow statements like @samp{RETURN 2HAB},
11858 which are invalid in both source forms
11859 (unlike @samp{RETURN (2HAB)},
11860 which probably still makes no sense but at least can
11861 be reliably parsed).
11862 Fixed-form processing rejects it, but not free-form, except
11863 in a way that is a bit difficult to understand.
11865 @node Dummy Array Without Dimensioning Dummy
11866 @subsection Dummy Array Without Dimensioning Dummy
11868 @code{g77} should complain when a list of dummy arguments containing an
11869 adjustable dummy array does
11870 not also contain every variable listed in the dimension list of the
11873 Currently, @code{g77} does complain about a variable that
11874 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
11875 area, but this needs to be extended to catch cases where it doesn't appear in
11876 every dummy list that also lists any arrays it dimensions.
11878 For example, @code{g77} should warn about the entry point @samp{ALT}
11879 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
11883 SUBROUTINE PRIMARY(ARRAY, ISIZE)
11888 @node Invalid FORMAT Specifiers
11889 @subsection Invalid FORMAT Specifiers
11891 @code{g77} should check @code{FORMAT} specifiers for validity
11892 as it does @code{FORMAT} statements.
11894 For example, a diagnostic would be produced for:
11897 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
11900 @node Ambiguous Dialects
11901 @subsection Ambiguous Dialects
11903 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
11904 @samp{-Wvxt}, @samp{-Wf90}, and so on.
11905 These would warn about places in the user's source where ambiguities
11906 are found, helpful in resolving ambiguities in the program's
11907 dialect or dialects.
11909 @node Unused Labels
11910 @subsection Unused Labels
11912 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
11914 @node Informational Messages
11915 @subsection Informational Messages
11917 @code{g77} needs an option to suppress information messages (notes).
11918 @samp{-w} does this but also suppresses warnings.
11919 The default should be to suppress info messages.
11921 Perhaps info messages should simply be eliminated.
11923 @node Uninitialized Variables at Run Time
11924 @subsection Uninitialized Variables at Run Time
11926 @code{g77} needs an option to initialize everything (not otherwise
11927 explicitly initialized) to ``weird''
11928 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
11929 largest-magnitude integers, would help track down references to
11930 some kinds of uninitialized variables at run time.
11932 Note that use of the options @samp{-O -Wuninitialized} can catch
11933 many such bugs at compile time.
11935 @node Bounds Checking at Run Time
11936 @subsection Bounds Checking at Run Time
11938 @code{g77} should offer run-time bounds-checking of array/subscript references
11939 in a fashion similar to @code{f2c}.
11941 Note that @code{g77} already warns about references to out-of-bounds
11942 elements of arrays when it detects these at compile time.
11944 @node Labels Visible to Debugger
11945 @subsection Labels Visible to Debugger
11947 @code{g77} should output debugging information for statements labels,
11948 for use by debuggers that know how to support them.
11949 Same with weirder things like construct names.
11950 It is not yet known if any debug formats or debuggers support these.
11952 @node Disappointments
11953 @section Disappointments and Misunderstandings
11955 These problems are perhaps regrettable, but we don't know any practical
11956 way around them for now.
11959 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
11960 external name @samp{foo_}.
11961 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
11962 and @samp{SUBROUTINE FOO}.
11963 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
11966 @node Mangling of Names
11967 @subsection Mangling of Names in Source Code
11968 @cindex naming issues
11969 @cindex external names
11970 @cindex common blocks
11972 @cindex underscores
11974 The current external-interface design, which includes naming of
11975 external procedures, COMMON blocks, and the library interface,
11976 has various usability problems, including things like adding
11977 underscores where not really necessary (and preventing easier
11978 inter-language operability) and yet not providing complete
11979 namespace freedom for user C code linked with Fortran apps (due
11980 to the naming of functions in the library, among other things).
11982 Project GNU should at least get all this ``right'' for systems
11983 it fully controls, such as the Hurd, and provide defaults and
11984 options for compatibility with existing systems and interoperability
11985 with popular existing compilers.
11987 @node Multiple Definitions of External Names
11988 @subsection Multiple Definitions of External Names
11990 @cindex BLOCK DATA statement
11991 @cindex statements, BLOCK DATA
11992 @cindex COMMON statement
11993 @cindex statements, COMMON
11994 @cindex naming conflicts
11996 @code{g77} doesn't allow a common block and an external procedure or
11997 @code{BLOCK DATA} to have the same name.
11998 Some systems allow this, but @code{g77} does not,
11999 to be compatible with @code{f2c}.
12001 @code{g77} could special-case the way it handles
12002 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12003 particular area (necessarily, since @code{g77} offers an
12004 important feature here), but
12005 it is likely that such special-casing would be very annoying to people
12006 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12007 @samp{FOO} in the same program unit, to refer to external procedures, since
12008 the result would be that @code{g77} would treat these references as requests to
12009 force-load BLOCK DATA program units.
12011 In that case, if @code{g77} modified
12012 names of @code{BLOCK DATA} so they could have the same names as
12013 @code{COMMON}, users
12014 would find that their programs wouldn't link because the @samp{FOO} procedure
12015 didn't have its name translated the same way.
12017 (Strictly speaking,
12018 @code{g77} could emit a null-but-externally-satisfying definition of
12019 @samp{FOO} with its name transformed as if it had been a
12020 @code{BLOCK DATA}, but that probably invites more trouble than it's
12023 @node Limitation on Implicit Declarations
12024 @subsection Limitation on Implicit Declarations
12025 @cindex IMPLICIT CHARACTER*(*) statement
12026 @cindex statements, IMPLICIT CHARACTER*(*)
12028 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12029 This is not standard-conforming.
12032 @section Certain Changes We Don't Want to Make
12034 This section lists changes that people frequently request, but which
12035 we do not make because we think GNU Fortran is better without them.
12038 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12039 is one, not two, characters long.
12040 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12042 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12043 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12044 single-precision constant,
12045 and might be interpreted as
12046 @samp{9.435785} or similar.
12047 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12048 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12049 not behave as expected.
12052 @node Backslash in Constants
12053 @subsection Backslash in Constants
12055 @cindex f77 support
12056 @cindex support, f77
12058 In the opinion of many experienced Fortran users,
12059 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12060 as currently set by @code{g77}.
12062 First of all, you can always specify
12063 @samp{-fno-backslash} to turn off this processing.
12065 Despite not being within the spirit (though apparently within the
12066 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12067 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12068 default to, and apparently lots of code depends on this feature.
12070 This is a particularly troubling issue.
12071 The use of a C construct in the midst of Fortran code
12072 is bad enough, worse when it makes existing Fortran
12073 programs stop working (as happens when programs written
12074 for non-UNIX systems are ported to UNIX systems with
12075 compilers that provide the @samp{-fbackslash} feature
12076 as the default---sometimes with no option to turn it off).
12078 The author of GNU Fortran wished, for reasons of linguistic
12079 purity, to make @samp{-fno-backslash} the default for GNU
12080 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12081 to specify @samp{-fbackslash} to get the UNIX behavior.
12083 However, the realization that @code{g77} is intended as
12084 a replacement for @emph{UNIX} @code{f77}, caused the author
12085 to choose to make @code{g77} as compatible with
12086 @code{f77} as feasible, which meant making @samp{-fbackslash}
12089 The primary focus on compatibility is at the source-code
12090 level, and the question became ``What will users expect
12091 a replacement for @code{f77} to do, by default?''
12092 Although at least one UNIX @code{f77} does not provide
12093 @samp{-fbackslash} as a default, it appears that
12094 the majority of them do, which suggests that
12095 the majority of code that is compiled by UNIX @code{f77}
12096 compilers expects @samp{-fbackslash} to be the default.
12098 It is probably the case that more code exists
12099 that would @emph{not} work with @samp{-fbackslash}
12100 in force than code that requires it be in force.
12102 However, most of @emph{that} code is not being compiled
12104 and when it is, new build procedures (shell scripts,
12105 makefiles, and so on) must be set up anyway so that
12106 they work under UNIX.
12107 That makes a much more natural and safe opportunity for
12108 non-UNIX users to adapt their build procedures for
12109 @code{g77}'s default of @samp{-fbackslash} than would
12110 exist for the majority of UNIX @code{f77} users who
12111 would have to modify existing, working build procedures
12112 to explicitly specify @samp{-fbackslash} if that was
12115 One suggestion has been to configure the default for
12116 @samp{-fbackslash} (and perhaps other options as well)
12117 based on the configuration of @code{g77}.
12119 This is technically quite straightforward, but will be avoided
12120 even in cases where not configuring defaults to be
12121 dependent on a particular configuration greatly inconveniences
12122 some users of legacy code.
12124 Many users appreciate the GNU compilers because they provide an
12125 environment that is uniform across machines.
12126 These users would be
12127 inconvenienced if the compiler treated things like the
12128 format of the source code differently on certain machines.
12130 Occasionally users write programs intended only for a particular machine
12132 On these occasions, the users would benefit if the GNU Fortran compiler
12133 were to support by default the same dialect as the other compilers on
12135 But such applications are rare.
12136 And users writing a
12137 program to run on more than one type of machine cannot possibly benefit
12138 from this kind of compatibility.
12139 (This is consistent with the design goals for @code{gcc}.
12140 To change them for @code{g77}, you must first change them
12142 Do not ask the maintainers of @code{g77} to do this for you,
12143 or to disassociate @code{g77} from the widely understood, if
12144 not widely agreed-upon, goals for GNU compilers in general.)
12146 This is why GNU Fortran does and will treat backslashes in the same
12147 fashion on all types of machines (by default).
12148 @xref{Direction of Language Development}, for more information on
12149 this overall philosophy guiding the development of the GNU Fortran
12152 Of course, users strongly concerned about portability should indicate
12153 explicitly in their build procedures which options are expected
12154 by their source code, or write source code that has as few such
12155 expectations as possible.
12157 For example, avoid writing code that depends on backslash (@samp{\})
12158 being interpreted either way in particular, such as by
12159 starting a program unit with:
12163 PARAMETER (BACKSL = '\\')
12167 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12169 In this way, users can write programs which have the same meaning
12170 in many Fortran dialects.
12172 (However, this technique does not work for Hollerith constants---which
12173 is just as well, since the only generally portable uses for Hollerith
12174 constants are in places where character constants can and should
12175 be used instead, for readability.)
12177 @node Initializing Before Specifying
12178 @subsection Initializing Before Specifying
12179 @cindex initialization, statement placement
12180 @cindex placing initialization statements
12182 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12183 source code before @samp{COMMON VAR},
12184 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12185 In general, @code{g77} requires initialization of a variable
12186 or array to be specified @emph{after} all other specifications
12187 of attributes (type, size, placement, and so on) of that variable
12188 or array are specified (though @emph{confirmation} of data type is
12191 It is @emph{possible} @code{g77} will someday allow all of this,
12192 even though it is not allowed by the FORTRAN 77 standard.
12194 Then again, maybe it is better to have
12195 @code{g77} always require placement of @code{DATA}
12196 so that it can possibly immediately write constants
12197 to the output file, thus saving time and space.
12199 That is, @samp{DATA A/1000000*1/} should perhaps always
12200 be immediately writable to canonical assembler, unless it's already known
12201 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12202 and to do this it cannot be followed by @samp{COMMON A}.
12204 @node Context-Sensitive Intrinsicness
12205 @subsection Context-Sensitive Intrinsicness
12206 @cindex intrinsics, context-sensitive
12207 @cindex context-sensitive intrinsics
12209 @code{g77} treats procedure references to @emph{possible} intrinsic
12210 names as always enabling their intrinsic nature, regardless of
12211 whether the @emph{form} of the reference is valid for that
12214 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12215 an invalid reference to the @code{SQRT} intrinsic function,
12216 because the reference is a subroutine invocation.
12218 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12219 as a reference to a @emph{procedure} named @samp{SQRT}, not
12220 to a @emph{variable} with that name (as it would for a statement
12221 such as @samp{V = SQRT}).
12223 Next, @code{g77} establishes that, in the program unit being compiled,
12224 @code{SQRT} is an intrinsic---not a subroutine that
12225 happens to have the same name as an intrinsic (as would be
12226 the case if, for example, @samp{EXTERNAL SQRT} was present).
12228 Finally, @code{g77} recognizes that the @emph{form} of the
12229 reference is invalid for that particular intrinsic.
12230 That is, it recognizes that it is invalid for an intrinsic
12231 @emph{function}, such as @code{SQRT}, to be invoked as
12232 a @emph{subroutine}.
12234 At that point, @code{g77} issues a diagnostic.
12236 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12237 references an external subroutine of their own, not an
12238 intrinsic function.
12240 However, @code{g77} knows about intrinsic
12241 subroutines, not just functions, and is able to support both having
12242 the same names, for example.
12244 As a result of this, @code{g77} rejects calls
12245 to intrinsics that are not subroutines, and function invocations
12246 of intrinsics that are not functions, just as it (and most compilers)
12247 rejects invocations of intrinsics with the wrong number (or types)
12250 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12251 a user-written subroutine named @samp{SQRT}.
12253 @node Context-Sensitive Constants
12254 @subsection Context-Sensitive Constants
12255 @cindex constants, context-sensitive
12256 @cindex context-sensitive constants
12258 @code{g77} does not use context to determine the types of
12259 constants or named constants (@code{PARAMETER}), except
12260 for (non-standard) typeless constants such as @samp{'123'O}.
12262 For example, consider the following statement:
12265 PRINT *, 9.435784839284958 * 2D0
12269 @code{g77} will interpret the (truncated) constant
12270 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12271 constant, because the suffix @code{D0} is not specified.
12273 As a result, the output of the above statement when
12274 compiled by @code{g77} will appear to have ``less precision''
12275 than when compiled by other compilers.
12277 In these and other cases, some compilers detect the
12278 fact that a single-precision constant is used in
12279 a double-precision context and therefore interpret the
12280 single-precision constant as if it was @emph{explicitly}
12281 specified as a double-precision constant.
12282 (This has the effect of appending @emph{decimal}, not
12283 @emph{binary}, zeros to the fractional part of the
12284 number---producing different computational results.)
12286 The reason this misfeature is dangerous is that a slight,
12287 apparently innocuous change to the source code can change
12288 the computational results.
12293 DOUBLE PRECISION FIVE
12294 PARAMETER (ALMOST = 5.000000000001)
12296 CLOSE = 5.000000000001
12297 PRINT *, 5.000000000001 - FIVE
12298 PRINT *, ALMOST - FIVE
12299 PRINT *, CLOSE - FIVE
12304 Running the above program should
12305 result in the same value being
12306 printed three times.
12307 With @code{g77} as the compiler,
12310 However, compiled by many other compilers,
12311 running the above program would print
12312 two or three distinct values, because
12313 in two or three of the statements, the
12314 constant @samp{5.000000000001}, which
12315 on most systems is exactly equal to @samp{5.}
12316 when interpreted as a single-precision constant,
12317 is instead interpreted as a double-precision
12318 constant, preserving the represented
12320 However, this ``clever'' promotion of
12321 type does not extend to variables or,
12322 in some compilers, to named constants.
12324 Since programmers often are encouraged to replace manifest
12325 constants or permanently-assigned variables with named
12326 constants (@code{PARAMETER} in Fortran), and might need
12327 to replace some constants with variables having the same
12328 values for pertinent portions of code,
12329 it is important that compilers treat code so modified in the
12330 same way so that the results of such programs are the same.
12331 @code{g77} helps in this regard by treating constants just
12332 the same as variables in terms of determining their types
12333 in a context-independent way.
12335 Still, there is a lot of existing Fortran code that has
12336 been written to depend on the way other compilers freely
12337 interpret constants' types based on context, so anything
12338 @code{g77} can do to help flag cases of this in such code
12339 could be very helpful.
12341 @node Equivalence Versus Equality
12342 @subsection Equivalence Versus Equality
12343 @cindex .EQV., with integer operands
12344 @cindex comparing logical expressions
12345 @cindex logical expressions, comparing
12347 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12348 is not supported, except via @samp{-fugly}, which is not
12349 recommended except for legacy code (where the behavior expected
12350 by the @emph{code} is assumed).
12352 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12353 and @code{.NEQV.} instead, as these are permitted by the various
12356 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12357 to work if either of its operands is @code{LOGICAL}.
12359 The problem with supporting this ``feature'' is that there is
12360 unlikely to be consensus on how it works, as illustrated by the
12361 following sample program:
12365 DATA L,M,N /3*.FALSE./
12366 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
12370 The issue raised by the above sample program is: what is the
12371 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
12372 @code{LOGICAL} operands?
12374 Some programmers will argue that it is the same as the precedence
12375 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
12377 By this interpretation, the subexpression @samp{M.EQ.N} must be
12378 evaluated first in the above program, resulting in a program that,
12379 when run, does not execute the @code{PRINT} statement.
12381 Other programmers will argue that the precedence is the same as
12382 the precedence for @code{.EQV.}, which is restricted by the standards
12383 to @code{LOGICAL} operands.
12384 By this interpretation, the subexpression @samp{L.AND.M} must be
12385 evaluated first, resulting in a program that @emph{does} execute
12386 the @code{PRINT} statement.
12388 Assigning arbitrary semantic interpretations to syntactic expressions
12389 that might legitimately have more than one ``obvious'' interpretation
12390 is generally unwise.
12392 The creators of the various Fortran standards have done a good job
12393 in this case, requiring a distinct set of operators (which have their
12394 own distinct precedence) to compare @code{LOGICAL} operands.
12395 This requirement results in expression syntax with more certain
12396 precedence (without requiring substantial context), making it easier
12397 for programmers to read existing code.
12398 @code{g77} will avoid muddying up elements of the Fortran language
12399 that were well-designed in the first place.
12401 (Ask C programmers about the precedence of expressions such as
12402 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
12403 you, without knowing more context, whether the @samp{&} and @samp{-}
12404 operators are infix (binary) or unary!)
12406 @node Order of Side Effects
12407 @subsection Order of Side Effects
12408 @cindex side effects, order of evaluation
12409 @cindex order of evaluation, side effects
12411 @code{g77} does not necessarily produce code that, when run, performs
12412 side effects (such as those performed by function invocations)
12413 in the same order as in some other compiler---or even in the same
12414 order as another version, port, or invocation (using different
12415 command-line options) of @code{g77}.
12417 It is never safe to depend on the order of evaluation of side effects.
12418 For example, an expression like this may very well behave differently
12419 from one compiler to another:
12422 J = IFUNC() - IFUNC()
12426 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
12428 Either invocation might happen first.
12429 If @samp{IFUNC} returns 5 the first time it is invoked, and
12430 returns 12 the second time, @samp{J} might end up with the
12431 value @samp{7}, or it might end up with @samp{-7}.
12433 Generally, in Fortran, procedures with side-effects intended to
12434 be visible to the caller are best designed as @emph{subroutines},
12436 Examples of such side-effects include:
12440 The generation of random numbers
12441 that are intended to influence return values.
12445 (other than internal I/O to local variables).
12448 Updating information in common blocks.
12451 An example of a side-effect that is not intended to be visible
12452 to the caller is a function that maintains a cache of recently
12453 calculated results, intended solely to speed repeated invocations
12454 of the function with identical arguments.
12455 Such a function can be safely used in expressions, because
12456 if the compiler optimizes away one or more calls to the
12457 function, operation of the program is unaffected (aside
12458 from being speeded up).
12460 @node Warnings and Errors
12461 @section Warning Messages and Error Messages
12463 @cindex error messages
12464 @cindex warnings vs errors
12465 @cindex messages, warning and error
12466 The GNU compiler can produce two kinds of diagnostics: errors and
12468 Each kind has a different purpose:
12472 @emph{Errors} report problems that make it impossible to compile your
12474 GNU Fortran reports errors with the source file name, line
12475 number, and column within the line where the problem is apparent.
12478 @emph{Warnings} report other unusual conditions in your code that
12479 @emph{might} indicate a problem, although compilation can (and does)
12481 Warning messages also report the source file name, line number,
12482 and column information,
12483 but include the text @samp{warning:} to distinguish them
12484 from error messages.
12487 Warnings might indicate danger points where you should check to make sure
12488 that your program really does what you intend; or the use of obsolete
12489 features; or the use of nonstandard features of GNU Fortran.
12490 Many warnings are issued only if you ask for them, with one of the
12491 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
12494 @emph{Note:} Currently, the text of the line and a pointer to the column
12495 is printed in most @code{g77} diagnostics.
12496 Probably, as of version 0.6, @code{g77} will
12497 no longer print the text of the source line, instead printing
12498 the column number following the file name and line number in
12499 a form that GNU Emacs recognizes.
12500 This change is expected to speed up and reduce the memory usage
12501 of the @code{g77} compiler.
12503 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
12505 @c GNU Fortran always tries to compile your program if possible; it never
12506 @c gratuitously rejects a program whose meaning is clear merely because
12507 @c (for instance) it fails to conform to a standard. In some cases,
12508 @c however, the Fortran standard specifies that certain extensions are
12509 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
12510 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
12511 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
12512 @c This does not mean that @emph{all} non-ANSI constructs get warnings
12515 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
12516 more detail on these and related command-line options.
12518 @node Open Questions
12519 @chapter Open Questions
12521 Please consider offering useful answers to these questions!
12525 @code{LOC()} and other intrinsics are probably somewhat misclassified.
12526 Is the a need for more precise classification of intrinsics, and if so,
12527 what are the appropriate groupings?
12528 Is there a need to individually
12529 enable/disable/delete/hide intrinsics from the command line?
12533 @chapter Reporting Bugs
12535 @cindex reporting bugs
12537 Your bug reports play an essential role in making GNU Fortran reliable.
12539 When you encounter a problem, the first thing to do is to see if it is
12542 If it isn't known, then you should report the problem.
12544 Reporting a bug might help you by bringing a solution to your problem, or
12546 (If it does not, look in the service directory; see
12548 In any case, the principal function of a bug report is
12549 to help the entire community by making the next version of GNU Fortran work
12551 Bug reports are your contribution to the maintenance of GNU Fortran.
12553 Since the maintainers are very overloaded, we cannot respond to every
12555 However, if the bug has not been fixed, we are likely to
12556 send you a patch and ask you to tell us whether it works.
12558 In order for a bug report to serve its purpose, you must include the
12559 information that makes for fixing the bug.
12562 * Criteria: Bug Criteria. Have you really found a bug?
12563 * Where: Bug Lists. Where to send your bug report.
12564 * Reporting: Bug Reporting. How to report a bug effectively.
12565 * Patches: Sending Patches. How to send a patch for GNU Fortran.
12568 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
12569 for information on problems we already know about.
12571 @xref{Service,,How To Get Help with GNU Fortran},
12572 for information on where to ask for help.
12575 @section Have You Found a Bug?
12576 @cindex bug criteria
12578 If you are not sure whether you have found a bug, here are some guidelines:
12581 @cindex fatal signal
12584 If the compiler gets a fatal signal, for any input whatever, that is a
12586 Reliable compilers never crash---they just remain obsolete.
12588 @cindex invalid assembly code
12589 @cindex assembly code, invalid
12591 If the compiler produces invalid assembly code, for any input whatever,
12592 @c (except an @code{asm} statement),
12593 that is a compiler bug, unless the
12594 compiler reports errors (not just warnings) which would ordinarily
12595 prevent the assembler from being run.
12597 @cindex undefined behavior
12598 @cindex undefined function value
12600 If the compiler produces valid assembly code that does not correctly
12601 execute the input source code, that is a compiler bug.
12603 However, you must double-check to make sure, because you might have run
12604 into an incompatibility between GNU Fortran and traditional Fortran.
12605 @c (@pxref{Incompatibilities}).
12606 These incompatibilities might be considered
12607 bugs, but they are inescapable consequences of valuable features.
12609 Or you might have a program whose behavior is undefined, which happened
12610 by chance to give the desired results with another Fortran compiler.
12611 It is best to check the relevant Fortran standard thoroughly if
12612 it is possible that the program indeed does something undefined.
12614 After you have localized the error to a single source line, it should
12615 be easy to check for these things.
12616 If your program is correct and well defined, you have found
12619 It might help if, in your submission, you identified the specific
12620 language in the relevant Fortran standard that specifies the
12621 desired behavior, if it isn't likely to be obvious and agreed-upon
12622 by all Fortran users.
12625 If the compiler produces an error message for valid input, that is a
12628 @cindex invalid input
12630 If the compiler does not produce an error message for invalid input,
12631 that is a compiler bug.
12632 However, you should note that your idea of
12633 ``invalid input'' might be someone else's idea
12634 of ``an extension'' or ``support for traditional practice''.
12637 If you are an experienced user of Fortran compilers, your suggestions
12638 for improvement of GNU Fortran are welcome in any case.
12641 Many, perhaps most, bug reports against @code{g77} turn out to
12642 be bugs in the user's code.
12643 While we find such bug reports educational, they sometimes take
12644 a considerable amount of time to track down or at least respond
12645 to---time we could be spending making @code{g77}, not some user's
12648 Some steps you can take to verify that the bug is not certainly
12649 in the code you're compiling with @code{g77}:
12653 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
12654 These options enable many useful warning; the @samp{-O} option
12655 enables flow analysis that enables the uninitialized-variable
12658 If you investigate the warnings and find evidence of possible bugs
12659 in your code, fix them first and retry @code{g77}.
12662 Compile your code using the @code{g77} options @samp{-finit-local-zero},
12663 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
12664 combinations thereof.
12666 If your code works with any of these combinations, that is not
12667 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
12668 by your code might simply be avoided, or have a different, more subtle
12669 effect, when different options are used---but it can be a
12670 strong indicator that your code is making unwarranted assumptions
12671 about the Fortran dialect and/or underlying machine it is
12672 being compiled and run on.
12674 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
12675 for information on the @samp{-fno-automatic} and
12676 @samp{-finit-local-zero} options and how to convert
12677 their use into selective changes in your own code.
12681 Validate your code with @code{ftnchek} or a similar code-checking
12683 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
12684 or @uref{ftp://ftp.dsm.fordham.edu}.
12687 @cindex Makefile example
12688 Here are some sample @file{Makefile} rules using @code{ftnchek}
12689 ``project'' files to do cross-file checking and @code{sfmakedepend}
12690 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
12691 to maintain dependencies automatically.
12692 These assume the use of GNU @code{make}.
12695 # Dummy suffix for ftnchek targets:
12699 # How to compile .f files (for implicit rule):
12701 # Assume `include' directory:
12702 FFLAGS = -Iinclude -g -O -Wall
12704 # Flags for ftnchek:
12705 CHEK1 = -array=0 -include=includes -noarray
12706 CHEK2 = -nonovice -usage=1 -notruncation
12707 CHEKFLAGS = $(CHEK1) $(CHEK2)
12709 # Run ftnchek with all the .prj files except the one corresponding
12710 # to the target's root:
12712 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
12713 -noextern -library $<
12715 # Derive a project file from a source file:
12717 ftnchek $(CHEKFLAGS) -noextern -project -library $<
12719 # The list of objects is assumed to be in variable OBJS.
12720 # Sources corresponding to the objects:
12721 SRCS = $(OBJS:%.o=%.f)
12722 # ftnchek project files:
12723 PRJS = $(OBJS:%.o=%.prj)
12725 # Build the program
12727 $(FC) -o $@ $(OBJS)
12729 chekall: $(PRJS) ; \
12730 ftnchek $(CHEKFLAGS) $(PRJS)
12734 # For Emacs M-x find-tag:
12738 # Rebuild dependencies:
12740 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
12744 Try your code out using other Fortran compilers, such as @code{f2c}.
12745 If it does not work on at least one other compiler (assuming the
12746 compiler supports the features the code needs), that is a strong
12747 indicator of a bug in the code.
12749 However, even if your code works on many compilers @emph{except}
12750 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
12751 It might mean the bug is in your code, and that @code{g77} simply
12752 exposes it more readily than other compilers.
12756 @section Where to Report Bugs
12757 @cindex bug report mailing lists
12758 @kindex @value{email-bugs}
12759 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
12761 Often people think of posting bug reports to a newsgroup instead of
12763 This sometimes appears to work, but it has one problem which can be
12764 crucial: a newsgroup posting does not contain a mail path back to the
12766 Thus, if maintainers need more information, they might be unable
12767 to reach you. For this reason, you should always send bug reports by
12768 mail to the proper mailing list.
12770 As a last resort, send bug reports on paper to:
12774 Free Software Foundation
12775 59 Temple Place - Suite 330
12776 Boston, MA 02111-1307, USA
12779 @node Bug Reporting
12780 @section How to Report Bugs
12781 @cindex compiler bugs, reporting
12783 The fundamental principle of reporting bugs usefully is this:
12784 @strong{report all the facts}.
12785 If you are not sure whether to state a
12786 fact or leave it out, state it!
12788 Often people omit facts because they think they know what causes the
12789 problem and they conclude that some details don't matter.
12791 assume that the name of the variable you use in an example does not matter.
12792 Well, probably it doesn't, but one cannot be sure.
12793 Perhaps the bug is a
12794 stray memory reference which happens to fetch from the location where that
12795 name is stored in memory; perhaps, if the name were different, the contents
12796 of that location would fool the compiler into doing the right thing despite
12798 Play it safe and give a specific, complete example.
12800 easiest thing for you to do, and the most helpful.
12802 Keep in mind that the purpose of a bug report is to enable someone to
12803 fix the bug if it is not known.
12804 It isn't very important what happens if
12805 the bug is already known.
12806 Therefore, always write your bug reports on
12807 the assumption that the bug is not known.
12809 Sometimes people give a few sketchy facts and ask, ``Does this ring a
12811 This cannot help us fix a bug, so it is rarely helpful.
12812 We respond by asking for enough details to enable us to investigate.
12813 You might as well expedite matters by sending them to begin with.
12814 (Besides, there are enough bells ringing around here as it is.)
12816 Try to make your bug report self-contained.
12817 If we have to ask you for
12818 more information, it is best if you include all the previous information
12819 in your response, as well as the information that was missing.
12821 Please report each bug in a separate message.
12822 This makes it easier for
12823 us to track which bugs have been fixed and to forward your bugs reports
12824 to the appropriate maintainer.
12826 Do not compress and encode any part of your bug report using programs
12827 such as @file{uuencode}.
12828 If you do so it will slow down the processing
12830 If you must submit multiple large files, use @file{shar},
12831 which allows us to read your message without having to run any
12832 decompression programs.
12834 (As a special exception for GNU Fortran bug-reporting, at least
12835 for now, if you are sending more than a few lines of code, if
12836 your program's source file format contains ``interesting'' things
12837 like trailing spaces or strange characters, or if you need to
12838 include binary data files, it is acceptable to put all the
12839 files together in a @code{tar} archive, and, whether you need to
12840 do that, it is acceptable to then compress the single file (@code{tar}
12841 archive or source file)
12842 using @code{gzip} and encode it via @code{uuencode}.
12843 Do not use any MIME stuff---the current maintainer can't decode this.
12844 Using @code{compress} instead of @code{gzip} is acceptable, assuming
12845 you have licensed the use of the patented algorithm in
12846 @code{compress} from Unisys.)
12848 To enable someone to investigate the bug, you should include all these
12853 The version of GNU Fortran.
12854 You can get this by running @code{g77} with the @samp{-v} option.
12855 (Ignore any error messages that might be displayed
12856 when the linker is run.)
12858 Without this, we won't know whether there is any point in looking for
12859 the bug in the current version of GNU Fortran.
12862 @cindex preprocessor
12863 @cindex cpp program
12864 @cindex programs, cpp
12865 A complete input file that will reproduce the bug.
12866 If the bug is in the compiler proper (@file{f771}) and
12867 you are using the C preprocessor, run your
12868 source file through the C preprocessor by doing @samp{g77 -E
12869 @var{sourcefile} > @var{outfile}}, then include the contents of
12870 @var{outfile} in the bug report. (When you do this, use the same
12871 @samp{-I}, @samp{-D} or @samp{-U} options that you used in actual
12874 A single statement is not enough of an example.
12875 In order to compile it,
12876 it must be embedded in a complete file of compiler input; and the bug
12877 might depend on the details of how this is done.
12879 Without a real example one can compile, all anyone can do about your bug
12880 report is wish you luck. It would be futile to try to guess how to
12881 provoke the bug. For example, bugs in register allocation and reloading
12882 frequently depend on every little detail of the function they happen in.
12885 @cindex included files
12886 @cindex INCLUDE directive
12887 @cindex directive, INCLUDE
12888 @cindex #include directive
12889 @cindex directive, #include
12890 Note that you should include with your bug report any files
12891 included by the source file
12892 (via the @code{#include} or @code{INCLUDE} directive)
12893 that you send, and any files they include, and so on.
12895 It is not necessary to replace
12896 the @code{#include} and @code{INCLUDE} directives
12897 with the actual files in the version of the source file that
12898 you send, but it might make submitting the bug report easier
12900 However, be sure to @emph{reproduce} the bug using the @emph{exact}
12901 version of the source material you submit, to avoid wild-goose
12905 The command arguments you gave GNU Fortran to compile that example
12906 and observe the bug. For example, did you use @samp{-O}? To guarantee
12907 you won't omit something important, list all the options.
12909 If we were to try to guess the arguments, we would probably guess wrong
12910 and then we would not encounter the bug.
12913 The type of machine you are using, and the operating system name and
12915 (Much of this information is printed by @samp{g77 -v}---if you
12916 include that, send along any additional info you have that you
12917 don't see clearly represented in that output.)
12920 The operands you gave to the @code{configure} command when you installed
12924 A complete list of any modifications you have made to the compiler
12925 source. (We don't promise to investigate the bug unless it happens in
12926 an unmodified compiler. But if you've made modifications and don't tell
12927 us, then you are sending us on a wild-goose chase.)
12929 Be precise about these changes. A description in English is not
12930 enough---send a context diff for them.
12932 Adding files of your own (such as a machine description for a machine we
12933 don't support) is a modification of the compiler source.
12936 Details of any other deviations from the standard procedure for installing
12940 A description of what behavior you observe that you believe is
12941 incorrect. For example, ``The compiler gets a fatal signal,'' or,
12942 ``The assembler instruction at line 208 in the output is incorrect.''
12944 Of course, if the bug is that the compiler gets a fatal signal, then one
12945 can't miss it. But if the bug is incorrect output, the maintainer might
12946 not notice unless it is glaringly wrong. None of us has time to study
12947 all the assembler code from a 50-line Fortran program just on the chance that
12948 one instruction might be wrong. We need @emph{you} to do this part!
12950 Even if the problem you experience is a fatal signal, you should still
12951 say so explicitly. Suppose something strange is going on, such as, your
12952 copy of the compiler is out of synch, or you have encountered a bug in
12953 the C library on your system. (This has happened!) Your copy might
12954 crash and the copy here would not. If you @i{said} to expect a crash,
12955 then when the compiler here fails to crash, we would know that the bug
12956 was not happening. If you don't say to expect a crash, then we would
12957 not know whether the bug was happening. We would not be able to draw
12958 any conclusion from our observations.
12960 If the problem is a diagnostic when building GNU Fortran with some other
12961 compiler, say whether it is a warning or an error.
12963 Often the observed symptom is incorrect output when your program is run.
12964 Sad to say, this is not enough information unless the program is short
12965 and simple. None of us has time to study a large program to figure out
12966 how it would work if compiled correctly, much less which line of it was
12967 compiled wrong. So you will have to do that. Tell us which source line
12968 it is, and what incorrect result happens when that line is executed. A
12969 person who understands the program can find this as easily as finding a
12970 bug in the program itself.
12973 If you send examples of assembler code output from GNU Fortran,
12974 please use @samp{-g} when you make them. The debugging information
12975 includes source line numbers which are essential for correlating the
12976 output with the input.
12979 If you wish to mention something in the GNU Fortran source, refer to it by
12980 context, not by line number.
12982 The line numbers in the development sources don't match those in your
12983 sources. Your line numbers would convey no convenient information to the
12987 Additional information from a debugger might enable someone to find a
12988 problem on a machine which he does not have available. However, you
12989 need to think when you collect this information if you want it to have
12990 any chance of being useful.
12992 @cindex backtrace for bug reports
12993 For example, many people send just a backtrace, but that is never
12994 useful by itself. A simple backtrace with arguments conveys little
12995 about GNU Fortran because the compiler is largely data-driven; the same
12996 functions are called over and over for different RTL insns, doing
12997 different things depending on the details of the insn.
12999 Most of the arguments listed in the backtrace are useless because they
13000 are pointers to RTL list structure. The numeric values of the
13001 pointers, which the debugger prints in the backtrace, have no
13002 significance whatever; all that matters is the contents of the objects
13003 they point to (and most of the contents are other such pointers).
13005 In addition, most compiler passes consist of one or more loops that
13006 scan the RTL insn sequence. The most vital piece of information about
13007 such a loop---which insn it has reached---is usually in a local variable,
13008 not in an argument.
13011 What you need to provide in addition to a backtrace are the values of
13012 the local variables for several stack frames up. When a local
13013 variable or an argument is an RTX, first print its value and then use
13014 the GDB command @code{pr} to print the RTL expression that it points
13015 to. (If GDB doesn't run on your machine, use your debugger to call
13016 the function @code{debug_rtx} with the RTX as an argument.) In
13017 general, whenever a variable is a pointer, its value is no use
13018 without the data it points to.
13021 Here are some things that are not necessary:
13025 A description of the envelope of the bug.
13027 Often people who encounter a bug spend a lot of time investigating
13028 which changes to the input file will make the bug go away and which
13029 changes will not affect it.
13031 This is often time consuming and not very useful, because the way we
13032 will find the bug is by running a single example under the debugger with
13033 breakpoints, not by pure deduction from a series of examples. You might
13034 as well save your time for something else.
13036 Of course, if you can find a simpler example to report @emph{instead} of
13037 the original one, that is a convenience. Errors in the output will be
13038 easier to spot, running under the debugger will take less time, etc.
13039 Most GNU Fortran bugs involve just one function, so the most straightforward
13040 way to simplify an example is to delete all the function definitions
13041 except the one where the bug occurs. Those earlier in the file may be
13042 replaced by external declarations if the crucial function depends on
13043 them. (Exception: inline functions might affect compilation of functions
13044 defined later in the file.)
13046 However, simplification is not vital; if you don't want to do this,
13047 report the bug anyway and send the entire test case you used.
13050 In particular, some people insert conditionals @samp{#ifdef BUG} around
13051 a statement which, if removed, makes the bug not happen. These are just
13052 clutter; we won't pay any attention to them anyway. Besides, you should
13053 send us preprocessor output, and that can't have conditionals.
13056 A patch for the bug.
13058 A patch for the bug is useful if it is a good one. But don't omit the
13059 necessary information, such as the test case, on the assumption that a
13060 patch is all we need. We might see problems with your patch and decide
13061 to fix the problem another way, or we might not understand it at all.
13063 Sometimes with a program as complicated as GNU Fortran it is very hard to
13064 construct an example that will make the program follow a certain path
13065 through the code. If you don't send the example, we won't be able to
13066 construct one, so we won't be able to verify that the bug is fixed.
13068 And if we can't understand what bug you are trying to fix, or why your
13069 patch should be an improvement, we won't install it. A test case will
13070 help us to understand.
13072 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13073 understand and install your patches.
13076 A guess about what the bug is or what it depends on.
13078 Such guesses are usually wrong. Even the maintainer can't guess right
13079 about such things without first using the debugger to find the facts.
13084 We have no way of examining a core dump for your type of machine
13085 unless we have an identical system---and if we do have one,
13086 we should be able to reproduce the crash ourselves.
13089 @node Sending Patches
13090 @section Sending Patches for GNU Fortran
13092 If you would like to write bug fixes or improvements for the GNU Fortran
13093 compiler, that is very helpful.
13094 Send suggested fixes to the bug report
13095 mailing list, @email{@value{email-bugs}}.
13097 Please follow these guidelines so we can study your patches efficiently.
13098 If you don't follow these guidelines, your information might still be
13099 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13100 of work in the best of circumstances, and we can't keep up unless you do
13105 Send an explanation with your changes of what problem they fix or what
13106 improvement they bring about. For a bug fix, just include a copy of the
13107 bug report, and explain why the change fixes the bug.
13109 (Referring to a bug report is not as good as including it, because then
13110 we will have to look it up, and we have probably already deleted it if
13111 we've already fixed the bug.)
13114 Always include a proper bug report for the problem you think you have
13115 fixed. We need to convince ourselves that the change is right before
13116 installing it. Even if it is right, we might have trouble judging it if
13117 we don't have a way to reproduce the problem.
13120 Include all the comments that are appropriate to help people reading the
13121 source in the future understand why this change was needed.
13124 Don't mix together changes made for different reasons.
13125 Send them @emph{individually}.
13127 If you make two changes for separate reasons, then we might not want to
13128 install them both. We might want to install just one. If you send them
13129 all jumbled together in a single set of diffs, we have to do extra work
13130 to disentangle them---to figure out which parts of the change serve
13131 which purpose. If we don't have time for this, we might have to ignore
13132 your changes entirely.
13134 If you send each change as soon as you have written it, with its own
13135 explanation, then the two changes never get tangled up, and we can
13136 consider each one properly without any extra work to disentangle them.
13138 Ideally, each change you send should be impossible to subdivide into
13139 parts that we might want to consider separately, because each of its
13140 parts gets its motivation from the other parts.
13143 Send each change as soon as that change is finished. Sometimes people
13144 think they are helping us by accumulating many changes to send them all
13145 together. As explained above, this is absolutely the worst thing you
13148 Since you should send each change separately, you might as well send it
13149 right away. That gives us the option of installing it immediately if it
13153 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13154 for us to install reliably. More than that, they make it hard for us to
13155 study the diffs to decide whether we want to install them. Unidiff
13156 format is better than contextless diffs, but not as easy to read as
13159 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13160 function that each change occurs in.
13161 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13164 Write the change log entries for your changes. We get lots of changes,
13165 and we don't have time to do all the change log writing ourselves.
13167 Read the @file{ChangeLog} file to see what sorts of information to put
13168 in, and to learn the style that we use. The purpose of the change log
13169 is to show people where to find what was changed. So you need to be
13170 specific about what functions you changed; in large functions, it's
13171 often helpful to indicate where within the function the change was.
13173 On the other hand, once you have shown people where to find the change,
13174 you need not explain its purpose. Thus, if you add a new function, all
13175 you need to say about it is that it is new. If you feel that the
13176 purpose needs explaining, it probably does---but the explanation will be
13177 much more useful if you put it in comments in the code.
13179 If you would like your name to appear in the header line for who made
13180 the change, send us the header line.
13183 When you write the fix, keep in mind that we can't install a change that
13184 would break other systems.
13186 People often suggest fixing a problem by changing machine-independent
13187 files such as @file{toplev.c} to do something special that a particular
13188 system needs. Sometimes it is totally obvious that such changes would
13189 break GNU Fortran for almost all users. We can't possibly make a change like
13190 that. At best it might tell us how to write another patch that would
13191 solve the problem acceptably.
13193 Sometimes people send fixes that @emph{might} be an improvement in
13194 general---but it is hard to be sure of this. It's hard to install
13195 such changes because we have to study them very carefully. Of course,
13196 a good explanation of the reasoning by which you concluded the change
13197 was correct can help convince us.
13199 The safest changes are changes to the configuration files for a
13200 particular machine. These are safe because they can't create new bugs
13203 Please help us keep up with the workload by designing the patch in a
13204 form that is good to install.
13208 @chapter How To Get Help with GNU Fortran
13210 If you need help installing, using or changing GNU Fortran, there are two
13215 Look in the service directory for someone who might help you for a fee.
13216 The service directory is found in the file named @file{SERVICE} in the
13217 GNU CC distribution.
13220 Send a message to @email{@value{email-general}}.
13225 @node Adding Options
13226 @chapter Adding Options
13227 @cindex options, adding
13228 @cindex adding options
13230 To add a new command-line option to @code{g77}, first decide
13231 what kind of option you wish to add.
13232 Search the @code{g77} and @code{gcc} documentation for one
13233 or more options that is most closely like the one you want to add
13234 (in terms of what kind of effect it has, and so on) to
13235 help clarify its nature.
13239 @emph{Fortran options} are options that apply only
13240 when compiling Fortran programs.
13241 They are accepted by @code{g77} and @code{gcc}, but
13242 they apply only when compiling Fortran programs.
13245 @emph{Compiler options} are options that apply
13246 when compiling most any kind of program.
13249 @emph{Fortran options} are listed in the file
13250 @file{@value{path-g77}/lang-options.h},
13251 which is used during the build of @code{gcc} to
13252 build a list of all options that are accepted by
13253 at least one language's compiler.
13254 This list goes into the @samp{lang_options} array
13255 in @file{gcc/toplev.c}, which uses this array to
13256 determine whether a particular option should be
13257 offered to the linked-in front end for processing
13258 by calling @samp{lang_option_decode}, which, for
13259 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13260 calls @samp{ffe_decode_option}.
13262 If the linked-in front end ``rejects'' a
13263 particular option passed to it, @file{toplev.c}
13264 just ignores the option, because @emph{some}
13265 language's compiler is willing to accept it.
13267 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13268 to work, even though Fortran compilation does
13269 not currently support the @samp{-fno-asm} option;
13270 even though the @code{f771} version of @samp{lang_decode_option}
13271 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13272 produce a diagnostic because some other language (C)
13275 This also means that commands like
13276 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13277 despite the fact that no phase of the command was
13278 able to recognize and process @samp{-fno-asm}---perhaps
13279 a warning about this would be helpful if it were
13282 Code that processes Fortran options is found in
13283 @file{@value{path-g77}/top.c}, function @samp{ffe_decode_option}.
13284 This code needs to check positive and negative forms
13287 The defaults for Fortran options are set in their
13288 global definitions, also found in @file{@value{path-g77}/top.c}.
13289 Many of these defaults are actually macros defined
13290 in @file{@value{path-g77}/target.h}, since they might be
13292 However, since, in practice, GNU compilers
13293 should behave the same way on all configurations
13294 (especially when it comes to language constructs),
13295 the practice of setting defaults in @file{target.h}
13296 is likely to be deprecated and, ultimately, stopped
13297 in future versions of @code{g77}.
13299 Accessor macros for Fortran options, used by code
13300 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13302 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13303 in the array @samp{f_options}.
13304 An option not listed in @samp{lang_options} is
13305 looked up in @samp{f_options} and handled from there.
13307 The defaults for compiler options are set in the
13308 global definitions for the corresponding variables,
13309 some of which are in @file{gcc/toplev.c}.
13311 You can set different defaults for @emph{Fortran-oriented}
13312 or @emph{Fortran-reticent} compiler options by changing
13313 the way @code{f771} handles the @samp{-fset-g77-defaults}
13314 option, which is always provided as the first option when
13315 called by @code{g77} or @code{gcc}.
13317 This code is in @samp{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13318 Have it change just the variables that you want to default
13319 to a different setting for Fortran compiles compared to
13320 compiles of other languages.
13322 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13323 automatically because of the specification information
13324 kept in @file{@value{path-g77}/lang-specs.h}.
13325 This file tells the @code{gcc} command how to recognize,
13326 in this case, Fortran source files (those to be preprocessed,
13327 and those that are not), and further, how to invoke the
13328 appropriate programs (including @code{f771}) to process
13329 those source files.
13331 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
13332 @samp{-fversion}, and other options are passed, as appropriate,
13333 even when the user has not explicitly specified them.
13334 Other ``internal'' options such as @samp{-quiet} also
13335 are passed via this mechanism.
13341 If you want to contribute to @code{g77} by doing research,
13342 design, specification, documentation, coding, or testing,
13343 the following information should give you some ideas.
13346 * Efficiency:: Make @code{g77} itself compile code faster.
13347 * Better Optimization:: Teach @code{g77} to generate faster code.
13348 * Simplify Porting:: Make @code{g77} easier to configure, build,
13350 * More Extensions:: Features many users won't know to ask for.
13351 * Machine Model:: @code{g77} should better leverage @code{gcc}.
13352 * Internals Documentation:: Make maintenance easier.
13353 * Internals Improvements:: Make internals more robust.
13354 * Better Diagnostics:: Make using @code{g77} on new code easier.
13358 @section Improve Efficiency
13361 Don't bother doing any performance analysis until most of the
13362 following items are taken care of, because there's no question
13363 they represent serious space/time problems, although some of
13364 them show up only given certain kinds of (popular) input.
13368 Improve @samp{malloc} package and its uses to specify more info about
13369 memory pools and, where feasible, use obstacks to implement them.
13372 Skip over uninitialized portions of aggregate areas (arrays,
13373 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
13374 This would reduce memory usage for large initialized aggregate
13375 areas, even ones with only one initialized element.
13377 As of version 0.5.18, a portion of this item has already been
13381 Prescan the statement (in @file{sta.c}) so that the nature of the statement
13382 is determined as much as possible by looking entirely at its form,
13383 and not looking at any context (previous statements, including types
13385 This would allow ripping out of the statement-confirmation,
13386 symbol retraction/confirmation, and diagnostic inhibition
13388 Plus, it would result in much-improved diagnostics.
13389 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
13390 is not a subroutine intrinsic, would result actual error instead of the
13391 unimplemented-statement catch-all.
13394 Throughout @code{g77}, don't pass line/column pairs where
13395 a simple @samp{ffewhere} type, which points to the error as much as is
13396 desired by the configuration, will do, and don't pass @samp{ffelexToken} types
13397 where a simple @samp{ffewhere} type will do.
13398 Then, allow new default
13399 configuration of @samp{ffewhere} such that the source line text is not
13400 preserved, and leave it to things like Emacs' next-error function
13401 to point to them (now that @samp{next-error} supports column,
13402 or, perhaps, character-offset, numbers).
13403 The change in calling sequences should improve performance somewhat,
13404 as should not having to save source lines.
13405 (Whether this whole
13406 item will improve performance is questionable, but it should
13407 improve maintainability.)
13410 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
13411 as regards the assembly output.
13412 Some of this might require improving
13413 the back end, but lots of improvement in space/time required in @code{g77}
13414 itself can be fairly easily obtained without touching the back end.
13415 Maybe type-conversion, where necessary, can be speeded up as well in
13416 cases like the one shown (converting the @samp{2} into @samp{2.}).
13419 If analysis shows it to be worthwhile, optimize @file{lex.c}.
13422 Consider redesigning @file{lex.c} to not need any feedback
13423 during tokenization, by keeping track of enough parse state on its
13427 @node Better Optimization
13428 @section Better Optimization
13429 @cindex optimization, better
13430 @cindex code generation, improving
13432 Much of this work should be put off until after @code{g77} has
13433 all the features necessary for its widespread acceptance as a
13434 useful F77 compiler.
13435 However, perhaps this work can be done in parallel during
13436 the feature-adding work.
13440 Do the equivalent of the trick of putting @samp{extern inline} in front
13441 of every function definition in @code{libg2c} and #include'ing the resulting
13442 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
13443 that are at all worth inlining.
13444 (Some of this has already been done, such as for integral exponentiation.)
13447 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
13448 and it's clear that types line up
13449 and @samp{CHAR_VAR} is addressable or not a @samp{VAR_DECL},
13450 make @samp{CHAR_VAR}, not a
13451 temporary, be the receiver for @samp{CHAR_FUNC}.
13452 (This is now done for @code{COMPLEX} variables.)
13455 Design and implement Fortran-specific optimizations that don't
13456 really belong in the back end, or where the front end needs to
13457 give the back end more info than it currently does.
13460 Design and implement a new run-time library interface, with the
13461 code going into @code{libgcc} so no special linking is required to
13462 link Fortran programs using standard language features.
13464 would speed up lots of things, from I/O (using precompiled formats,
13465 doing just one, or, at most, very few, calls for arrays or array sections,
13466 and so on) to general computing (array/section implementations of
13467 various intrinsics, implementation of commonly performed loops that
13468 aren't likely to be optimally compiled otherwise, etc.).
13470 Among the important things the library would do are:
13474 Be a one-stop-shop-type
13475 library, hence shareable and usable by all, in that what are now
13476 library-build-time options in @code{libg2c} would be moved at least to the
13477 @code{g77} compile phase, if not to finer grains (such as choosing how
13478 list-directed I/O formatting is done by default at @code{OPEN} time, for
13479 preconnected units via options or even statements in the main program
13480 unit, maybe even on a per-I/O basis with appropriate pragma-like
13485 Probably requiring the new library design, change interface to
13486 normally have @code{COMPLEX} functions return their values in the way
13487 @code{gcc} would if they were declared @code{__complex__ float},
13489 the mechanism currently used by @code{CHARACTER} functions (whereby the
13490 functions are compiled as returning void and their first arg is
13491 a pointer to where to store the result).
13492 (Don't append underscores to
13493 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
13494 @code{gcc} rather than @code{f2c} calling conventions.)
13497 Do something useful with @samp{doiter} references where possible.
13498 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
13499 a @code{DO} loop that uses @samp{I} as the
13500 iteration variable, and the back end might find that info useful
13501 in determining whether it needs to read @samp{I} back into a register after
13503 (It normally has to do that, unless it knows @samp{FOO} never
13504 modifies its passed-by-reference argument, which is rarely the case
13505 for Fortran-77 code.)
13508 @node Simplify Porting
13509 @section Simplify Porting
13510 @cindex porting, simplify
13511 @cindex simplify porting
13513 Making @code{g77} easier to configure, port, build, and install, either
13514 as a single-system compiler or as a cross-compiler, would be
13519 A new library (replacing @code{libg2c}) should improve portability as well as
13520 produce more optimal code.
13521 Further, @code{g77} and the new library should
13522 conspire to simplify naming of externals, such as by removing unnecessarily
13523 added underscores, and to reduce/eliminate the possibility of naming
13524 conflicts, while making debugger more straightforward.
13527 make multi-language applications more feasible, such as by providing
13528 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
13532 Possibly related to a new library, @code{g77} should produce the equivalent
13533 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
13534 main program unit, instead of compiling something that must be
13535 called by a library
13536 implementation of @code{main()}.
13538 This would do many useful things such as
13539 provide more flexibility in terms of setting up exception handling,
13540 not requiring programmers to start their debugging sessions with
13541 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
13544 The GBE needs to understand the difference between alignment
13545 requirements and desires.
13546 For example, on Intel x86 machines, @code{g77} currently imposes
13547 overly strict alignment requirements, due to the back end, but it
13548 would be useful for Fortran and C programmers to be able to override
13549 these @emph{recommendations} as long as they don't violate the actual
13550 processor @emph{requirements}.
13553 @node More Extensions
13554 @section More Extensions
13555 @cindex extensions, more
13557 These extensions are not the sort of things users ask for ``by name'',
13558 but they might improve the usability of @code{g77}, and Fortran in
13559 general, in the long run.
13560 Some of these items really pertain to improving @code{g77} internals
13561 so that some popular extensions can be more easily supported.
13565 Look through all the documentation on the GNU Fortran language,
13566 dialects, compiler, missing features, bugs, and so on.
13567 Many mentions of incomplete or missing features are
13568 sprinkled throughout.
13569 It is not worth repeating them here.
13572 @cindex concatenation
13573 @cindex CHARACTER*(*)
13574 Support arbitrary operands for concatenation, even in contexts where
13575 run-time allocation is required.
13578 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
13580 The idea is to provide a forward-looking, effective
13581 replacement for things like the old-style @code{PARAMETER} statement
13583 really need typelessness in a maintainable, portable, clearly documented
13585 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
13586 and whatever else might come along.
13587 (This is not really a call for polymorphism per se, just
13588 an ability to express limited, syntactic polymorphism.)
13591 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
13594 Support arbitrary file unit numbers, instead of limiting them
13595 to 0 through @samp{MXUNIT-1}.
13596 (This is a @code{libg2c} issue.)
13599 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
13600 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
13601 later @code{UNIT=} in the first example is invalid.
13602 Make sure this is what users of this feature would expect.
13605 Currently @code{g77} disallows @samp{READ(1'10)} since
13606 it is an obnoxious syntax, but
13607 supporting it might be pretty easy if needed.
13608 More details are needed, such
13609 as whether general expressions separated by an apostrophe are supported,
13610 or maybe the record number can be a general expression, and so on.
13613 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
13615 Currently there is no support at all
13616 for @code{%FILL} in @code{STRUCTURE} and related syntax,
13617 whereas the rest of the
13618 stuff has at least some parsing support.
13619 This requires either major
13620 changes to @code{libg2c} or its replacement.
13623 F90 and @code{g77} probably disagree about label scoping relative to
13624 @code{INTERFACE} and @code{END INTERFACE}, and their contained
13625 procedure interface bodies (blocks?).
13628 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
13629 since that was added after S8.112.
13632 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
13633 with the final form of the standard (it was vague at S8.112).
13636 It seems to be an ``open'' question whether a file, immediately after being
13637 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
13638 might be nice to offer an option of opening to ``undefined'' status, requiring
13639 an explicit absolute-positioning operation to be performed before any
13640 other (besides @code{CLOSE}) to assist in making applications port to systems
13641 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
13644 @node Machine Model
13645 @section Machine Model
13647 This items pertain to generalizing @code{g77}'s view of
13648 the machine model to more fully accept whatever the GBE
13649 provides it via its configuration.
13653 Switch to using @samp{REAL_VALUE_TYPE} to represent floating-point constants
13654 exclusively so the target float format need not be required.
13656 means changing the way @code{g77} handles initialization of aggregate areas
13657 having more than one type, such as @code{REAL} and @code{INTEGER},
13659 it initializes them as if they were arrays of @code{char} and uses the
13660 bit patterns of the constants of the various types in them to determine
13661 what to stuff in elements of the arrays.
13664 Rely more and more on back-end info and capabilities, especially in the
13665 area of constants (where having the @code{g77} front-end's IL just store
13666 the appropriate tree nodes containing constants might be best).
13669 Suite of C and Fortran programs that a user/administrator can run on a
13670 machine to help determine the configuration for @code{g77} before building
13671 and help determine if the compiler works (especially with whatever
13672 libraries are installed) after building.
13675 @node Internals Documentation
13676 @section Internals Documentation
13678 Better info on how @code{g77} works and how to port it is needed.
13679 Much of this should be done only after the redesign planned for
13682 @node Internals Improvements
13683 @section Internals Improvements
13685 Some more items that would make @code{g77} more reliable
13686 and easier to maintain:
13690 Generally make expression handling focus
13691 more on critical syntax stuff, leaving semantics to callers.
13693 anything a caller can check, semantically, let it do so, rather
13694 than having @file{expr.c} do it.
13695 (Exceptions might include things like
13696 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
13698 important to preserve the left-to-right-in-source order of production
13702 Come up with better naming conventions for @samp{-D} to establish requirements
13703 to achieve desired implementation dialect via @file{proj.h}.
13706 Clean up used tokens and @samp{ffewhere}s in @samp{ffeglobal_terminate_1}.
13709 Replace @file{sta.c} @samp{outpooldisp} mechanism with @samp{malloc_pool_use}.
13712 Check for @samp{opANY} in more places in @file{com.c}, @file{std.c},
13713 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
13714 (after determining if there is indeed no real need for it).
13717 Utility to read and check @file{bad.def} messages and their references in the
13718 code, to make sure calls are consistent with message templates.
13721 Search and fix @samp{&ffe@dots{}} and similar so that
13722 @samp{ffe@dots{}ptr@dots{}} macros are
13723 available instead (a good argument for wishing this could have written all
13724 this stuff in C++, perhaps).
13725 On the other hand, it's questionable whether this sort of
13726 improvement is really necessary, given the availability of
13727 tools such as Emacs and Perl, which make finding any
13728 address-taking of structure members easy enough?
13731 Some modules truly export the member names of their structures (and the
13732 structures themselves), maybe fix this, and fix other modules that just
13733 appear to as well (by appending @samp{_}, though it'd be ugly and probably
13734 not worth the time).
13737 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
13739 and use them throughout @code{g77} source code (especially in the definitions
13740 of access macros in @samp{.h} files) so they can be tailored
13741 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
13744 Decorate throughout with @code{const} and other such stuff.
13747 All F90 notational derivations in the source code are still based
13748 on the S8.112 version of the draft standard.
13749 Probably should update
13750 to the official standard, or put documentation of the rules as used
13751 in the code@dots{}uh@dots{}in the code.
13754 Some @samp{ffebld_new} calls (those outside of @file{ffeexpr.c} or
13755 inside but invoked via paths not involving @samp{ffeexpr_lhs} or
13756 @samp{ffeexpr_rhs}) might be creating things
13757 in improper pools, leading to such things staying around too long or
13758 (doubtful, but possible and dangerous) not long enough.
13761 Some @samp{ffebld_list_new} (or whatever) calls might not be matched by
13762 @samp{ffebld_list_bottom} (or whatever) calls, which might someday matter.
13763 (It definitely is not a problem just yet.)
13766 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
13767 due to alignment/mismatch or other problems---they end up without
13768 @samp{ffestorag} objects, so maybe the backend (and other parts of the front
13769 end) can notice that and handle like an @samp{opANY} (do what it wants, just
13770 don't complain or crash).
13771 Most of this seems to have been addressed
13772 by now, but a code review wouldn't hurt.
13775 @node Better Diagnostics
13776 @section Better Diagnostics
13778 These are things users might not ask about, or that need to
13779 be looked into, before worrying about.
13780 Also here are items that involve reducing unnecessary diagnostic
13785 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
13786 lengths, type classes, and so on),
13787 @samp{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
13791 Speed up and improve error handling for data when repeat-count is
13793 For example, don't output 20 unnecessary messages after the
13794 first necessary one for:
13799 DATA (X(I), J= 1, 20) /20*5/
13804 (The @code{CONTINUE} statement ensures the @code{DATA} statement
13805 is processed in the context of executable, not specification,
13812 @chapter Diagnostics
13813 @cindex diagnostics
13815 Some diagnostics produced by @code{g77} require sufficient explanation
13816 that the explanations are given below, and the diagnostics themselves
13817 identify the appropriate explanation.
13819 Identification uses the GNU Info format---specifically, the @code{info}
13820 command that displays the explanation is given within square
13821 brackets in the diagnostic.
13825 foo.f:5: Invalid statement [info -f g77 M FOOEY]
13828 More details about the above diagnostic is found in the @code{g77} Info
13829 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
13830 which is displayed by typing the UNIX command
13831 @samp{info -f g77 M FOOEY}.
13833 Other Info readers, such as EMACS, may be just as easily used to display
13834 the pertinent node.
13835 In the above example, @samp{g77} is the Info document name,
13836 @samp{M} is the top-level menu item to select,
13837 and, in that node (named @samp{Diagnostics}, the name of
13838 this chapter, which is the very text you're reading now),
13839 @samp{FOOEY} is the menu item to select.
13842 In this printed version of the @code{g77} manual, the above example
13843 points to a section, below, entitled @samp{FOOEY}---though, of course,
13844 as the above is just a sample, no such section exists.
13848 * CMPAMBIG:: Ambiguous use of intrinsic.
13849 * EXPIMP:: Intrinsic used explicitly and implicitly.
13850 * INTGLOB:: Intrinsic also used as name of global.
13851 * LEX:: Various lexer messages
13852 * GLOBALS:: Disagreements about globals.
13853 * LINKFAIL:: When linking @samp{f771} fails.
13857 @section @code{CMPAMBIG}
13861 Ambiguous use of intrinsic @var{intrinsic} @dots{}
13864 The type of the argument to the invocation of the @var{intrinsic}
13865 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
13866 Typically, it is @code{COMPLEX(KIND=2)}, also known as
13867 @code{DOUBLE COMPLEX}.
13869 The interpretation of this invocation depends on the particular
13870 dialect of Fortran for which the code was written.
13871 Some dialects convert the real part of the argument to
13872 @code{REAL(KIND=1)}, thus losing precision; other dialects,
13873 and Fortran 90, do no such conversion.
13875 So, GNU Fortran rejects such invocations except under certain
13876 circumstances, to avoid making an incorrect assumption that results
13877 in generating the wrong code.
13879 To determine the dialect of the program unit, perhaps even whether
13880 that particular invocation is properly coded, determine how the
13881 result of the intrinsic is used.
13883 The result of @var{intrinsic} is expected (by the original programmer)
13884 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
13888 It is passed as an argument to a procedure that explicitly or
13889 implicitly declares that argument @code{REAL(KIND=1)}.
13892 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
13893 statement specifying the dummy argument corresponding to an
13894 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
13895 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
13896 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
13897 of @code{REAL(KIND=2)}.
13900 It is used in a context that would otherwise not include
13901 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
13902 invocation as @code{REAL(KIND=2)} would result in unnecessary
13903 promotions and (typically) more expensive operations on the
13914 The above example suggests the programmer expected the real part
13915 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
13916 multiplied by @samp{T} (presumed, along with @samp{R} above, to
13917 be type @code{REAL(KIND=1)}).
13919 Otherwise, the conversion would have to be delayed until after
13920 the multiplication, requiring not only an extra conversion
13921 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
13922 expensive multiplication (a double-precision multiplication instead
13923 of a single-precision one).
13926 The result of @var{intrinsic} is expected (by the original programmer)
13927 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
13931 It is passed as an argument to a procedure that explicitly or
13932 implicitly declares that argument @code{REAL(KIND=2)}.
13934 For example, a procedure specifying a @code{DOUBLE PRECISION}
13935 dummy argument corresponding to an
13936 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
13937 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
13938 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
13939 of @code{REAL(KIND=1)}.
13942 It is used in an expression context that includes
13943 other @code{REAL(KIND=2)} operands,
13944 or is assigned to a @code{REAL(KIND=2)} variable or array element.
13950 DOUBLE PRECISION R, T
13955 The above example suggests the programmer expected the real part
13956 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
13957 by the @code{REAL()} intrinsic.
13959 Otherwise, the conversion would have to be immediately followed
13960 by a conversion back to @code{REAL(KIND=2)}, losing
13961 the original, full precision of the real part of @code{Z},
13962 before being multiplied by @samp{T}.
13965 Once you have determined whether a particular invocation of @var{intrinsic}
13966 expects the Fortran 90 interpretation, you can:
13970 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
13971 @samp{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
13973 if it expected the Fortran 90 interpretation.
13975 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
13976 some other type, such as @code{COMPLEX*32}, you should use the
13977 appropriate intrinsic, such as the one to convert to @code{REAL*16}
13978 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
13979 @code{QIMAG()} in place of @code{DIMAG()}).
13982 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
13984 This converts to @code{REAL(KIND=1)} in all working
13988 If you don't want to change the code, and you are certain that all
13989 ambiguous invocations of @var{intrinsic} in the source file have
13990 the same expectation regarding interpretation, you can:
13994 Compile with the @code{g77} option @samp{-ff90}, to enable the
13995 Fortran 90 interpretation.
13998 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
13999 to enable the non-Fortran-90 interpretations.
14002 @xref{REAL() and AIMAG() of Complex}, for more information on this
14005 Note: If the above suggestions don't produce enough evidence
14006 as to whether a particular program expects the Fortran 90
14007 interpretation of this ambiguous invocation of @var{intrinsic},
14008 there is one more thing you can try.
14010 If you have access to most or all the compilers used on the
14011 program to create successfully tested and deployed executables,
14012 read the documentation for, and @emph{also} test out, each compiler
14013 to determine how it treats the @var{intrinsic} intrinsic in
14015 (If all the compilers don't agree on an interpretation, there
14016 might be lurking bugs in the deployed versions of the program.)
14018 The following sample program might help:
14020 @cindex JCB003 program
14024 C Written by James Craig Burley 1997-02-23.
14025 C Contact via Internet email: burley@@gnu.org
14027 C Determine how compilers handle non-standard REAL
14028 C and AIMAG on DOUBLE COMPLEX operands.
14036 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14037 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14041 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14042 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14045 C Just to make sure compiler doesn't use naive flow
14046 C analysis to optimize away careful work above,
14047 C which might invalidate results....
14049 SUBROUTINE DUMDUM(Z, R)
14055 If the above program prints contradictory results on a
14056 particular compiler, run away!
14059 @section @code{EXPIMP}
14063 Intrinsic @var{intrinsic} referenced @dots{}
14066 The @var{intrinsic} is explicitly declared in one program
14067 unit in the source file and implicitly used as an intrinsic
14068 in another program unit in the same source file.
14070 This diagnostic is designed to catch cases where a program
14071 might depend on using the name @var{intrinsic} as an intrinsic
14072 in one program unit and as a global name (such as the name
14073 of a subroutine or function) in another, but @code{g77} recognizes
14074 the name as an intrinsic in both cases.
14076 After verifying that the program unit making implicit use
14077 of the intrinsic is indeed written expecting the intrinsic,
14078 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14079 program unit to prevent this warning.
14081 This and related warnings are disabled by using
14082 the @samp{-Wno-globals} option when compiling.
14084 Note that this warning is not issued for standard intrinsics.
14085 Standard intrinsics include those described in the FORTRAN 77
14086 standard and, if @samp{-ff90} is specified, those described
14087 in the Fortran 90 standard.
14088 Such intrinsics are not as likely to be confused with user
14089 procedures as intrinsics provided as extensions to the
14090 standard by @code{g77}.
14093 @section @code{INTGLOB}
14097 Same name `@var{intrinsic}' given @dots{}
14100 The name @var{intrinsic} is used for a global entity (a common
14101 block or a program unit) in one program unit and implicitly
14102 used as an intrinsic in another program unit.
14104 This diagnostic is designed to catch cases where a program
14105 intends to use a name entirely as a global name, but @code{g77}
14106 recognizes the name as an intrinsic in the program unit that
14107 references the name, a situation that would likely produce
14113 INTEGER FUNCTION TIME()
14119 PRINT *, 'Time is ', TIME()
14123 The above example defines a program unit named @samp{TIME}, but
14124 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14125 is normally treated by @code{g77} as a reference to the intrinsic
14126 @code{TIME()} (unless a command-line option that prevents such
14127 treatment has been specified).
14129 As a result, the program @samp{SAMP} will @emph{not}
14130 invoke the @samp{TIME} function in the same source file.
14132 Since @code{g77} recognizes @code{libU77} procedures as
14133 intrinsics, and since some existing code uses the same names
14134 for its own procedures as used by some @code{libU77}
14135 procedures, this situation is expected to arise often enough
14136 to make this sort of warning worth issuing.
14138 After verifying that the program unit making implicit use
14139 of the intrinsic is indeed written expecting the intrinsic,
14140 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14141 program unit to prevent this warning.
14143 Or, if you believe the program unit is designed to invoke the
14144 program-defined procedure instead of the intrinsic (as
14145 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14146 statement to the program unit that references the name to
14147 prevent this warning.
14149 This and related warnings are disabled by using
14150 the @samp{-Wno-globals} option when compiling.
14152 Note that this warning is not issued for standard intrinsics.
14153 Standard intrinsics include those described in the FORTRAN 77
14154 standard and, if @samp{-ff90} is specified, those described
14155 in the Fortran 90 standard.
14156 Such intrinsics are not as likely to be confused with user
14157 procedures as intrinsics provided as extensions to the
14158 standard by @code{g77}.
14161 @section @code{LEX}
14165 Unrecognized character @dots{}
14166 Invalid first character @dots{}
14167 Line too long @dots{}
14168 Non-numeric character @dots{}
14169 Continuation indicator @dots{}
14170 Label at @dots{} invalid with continuation line indicator @dots{}
14171 Character constant @dots{}
14172 Continuation line @dots{}
14173 Statement at @dots{} begins with invalid token
14176 Although the diagnostics identify specific problems, they can
14177 be produced when general problems such as the following occur:
14181 The source file contains something other than Fortran code.
14183 If the code in the file does not look like many of the examples
14184 elsewhere in this document, it might not be Fortran code.
14185 (Note that Fortran code often is written in lower case letters,
14186 while the examples in this document use upper case letters,
14187 for stylistic reasons.)
14189 For example, if the file contains lots of strange-looking
14190 characters, it might be APL source code; if it contains lots
14191 of parentheses, it might be Lisp source code; if it
14192 contains lots of bugs, it might be C++ source code.
14195 The source file contains free-form Fortran code, but @samp{-ffree-form}
14196 was not specified on the command line to compile it.
14198 Free form is a newer form for Fortran code.
14199 The older, classic form is called fixed form.
14201 Fixed-form code is visually fairly distinctive, because
14202 numerical labels and comments are all that appear in
14203 the first five columns of a line, the sixth column is
14204 reserved to denote continuation lines,
14205 and actual statements start at or beyond column 7.
14206 Spaces generally are not significant, so if you
14207 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14208 you are looking at fixed-form code.
14209 Comment lines are indicated by the letter @samp{C} or the symbol
14210 @samp{*} in column 1.
14211 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14212 which many compilers support.)
14214 Free-form code is distinguished from fixed-form source
14215 primarily by the fact that statements may start anywhere.
14216 (If lots of statements start in columns 1 through 6,
14217 that's a strong indicator of free-form source.)
14218 Consecutive keywords must be separated by spaces, so
14219 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14220 There are no comment lines per se, but @samp{!} starts a
14221 comment anywhere in a line (other than within a character or
14222 hollerith constant).
14224 @xref{Source Form}, for more information.
14227 The source file is in fixed form and has been edited without
14228 sensitivity to the column requirements.
14230 Statements in fixed-form code must be entirely contained within
14231 columns 7 through 72 on a given line.
14232 Starting them ``early'' is more likely to result in diagnostics
14233 than finishing them ``late'', though both kinds of errors are
14234 often caught at compile time.
14236 For example, if the following code fragment is edited by following
14237 the commented instructions literally, the result, shown afterward,
14238 would produce a diagnostic when compiled:
14241 C On XYZZY systems, remove "C" on next line:
14245 The result of editing the above line might be:
14248 C On XYZZY systems, remove "C" on next line:
14252 However, that leaves the first @samp{C} in the @samp{CALL}
14253 statement in column 6, making it a comment line, which is
14254 not really what the author intended, and which is likely
14255 to result in one of the above-listed diagnostics.
14257 @emph{Replacing} the @samp{C} in column 1 with a space
14258 is the proper change to make, to ensure the @samp{CALL}
14259 keyword starts in or after column 7.
14261 Another common mistake like this is to forget that fixed-form
14262 source lines are significant through only column 72, and that,
14263 normally, any text beyond column 72 is ignored or is diagnosed
14266 @xref{Source Form}, for more information.
14269 The source file requires preprocessing, and the preprocessing
14270 is not being specified at compile time.
14272 A source file containing lines beginning with @code{#define},
14273 @code{#include}, @code{#if}, and so on is likely one that
14274 requires preprocessing.
14276 If the file's suffix is @samp{.f} or @samp{.for}, the file
14277 will normally be compiled @emph{without} preprocessing by @code{g77}.
14279 Change the file's suffix from @samp{.f} to @samp{.F} (or, on
14280 systems with case-insensitive file names, to @samp{.fpp}) or
14281 from @samp{.for} to @samp{.fpp}.
14282 @code{g77} compiles files with such names @emph{with}
14285 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14286 the language @samp{f77-cpp-input} for Fortran files that
14287 require preprocessing.
14288 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14291 The source file is preprocessed, and the results of preprocessing
14292 result in syntactic errors that are not necessarily obvious to
14293 someone examining the source file itself.
14295 Examples of errors resulting from preprocessor macro expansion
14296 include exceeding the line-length limit, improperly starting,
14297 terminating, or incorporating the apostrophe or double-quote in
14298 a character constant, improperly forming a hollerith constant,
14301 @xref{Overall Options,,Options Controlling the Kind of Output},
14302 for suggestions about how to use, and not use, preprocessing
14307 @section @code{GLOBALS}
14311 Global name @var{name} defined at @dots{} already defined@dots{}
14312 Global name @var{name} at @dots{} has different type@dots{}
14313 Too many arguments passed to @var{name} at @dots{}
14314 Too few arguments passed to @var{name} at @dots{}
14315 Argument #@var{n} of @var{name} is @dots{}
14318 These messages all identify disagreements about the
14319 global procedure named @var{name} among different program
14320 units (usually including @var{name} itself).
14322 These disagreements, if not diagnosed, could result in a
14323 compiler crash if the compiler attempted to inline a reference
14324 to @var{name} within a calling program unit that disagreed
14325 with the @var{name} program unit regarding whether the
14326 procedure is a subroutine or function, the type of the
14327 return value of the procedure (if it is a function), the
14328 number of arguments the procedure accepts, or the type
14331 Such disagreements @emph{should} be fixed in the Fortran
14333 However, if that is not immediately practical, and the code
14334 has been working for some time, it is possible it will work
14335 when compiled by @code{g77} with the @samp{-fno-globals} option.
14337 The @samp{-fno-globals} option disables these diagnostics, and
14338 also disables all inlining of references to global procedures
14339 to avoid compiler crashes.
14340 The diagnostics are actually produced, but as warnings, unless
14341 the @samp{-Wno-globals} option also is specified.
14343 After using @samp{-fno-globals} to work around these problems,
14344 it is wise to stop using that option and address them by fixing
14345 the Fortran code, because such problems, while they might not
14346 actually result in bugs on some systems, indicate that the code
14347 is not as portable as it could be.
14348 In particular, the code might appear to work on a particular
14349 system, but have bugs that affect the reliability of the data
14350 without exhibiting any other outward manifestations of the bugs.
14353 @section @code{LINKFAIL}
14357 If the above command failed due to an unresolved reference
14358 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
14359 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
14360 for information on what causes this, how to work around
14361 the problem by editing $@{srcdir@}/proj.c, and what else to do.
14364 @xref{Missing strtoul or bsearch}, for more information on
14366 which occurs only in releases of @code{g77}
14367 based on @code{gcc}.
14368 (It does not occur in @code{egcs}.)
14370 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
14371 due to a linker bug in coping with the @samp{-bbigtoc} option
14372 which leads to a @samp{Relocation overflow} error.
14374 Compiling with @samp{-mminimal-toc}
14375 might solve this problem, e.g.@: by adding
14377 BOOT_CFLAGS='-mminimal-toc -O2 -g'
14379 to the @code{make bootstrap} command line.