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-09-01
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 (versus 0.5.24):
3316 @cindex double-precision performance
3317 @cindex -malign-double
3319 Align static double-precision variables and arrays
3320 on Intel x86 targets
3321 regardless of whether @samp{-malign-double} is specified.
3323 Generally, this affects only local variables and arrays
3324 having the @code{SAVE} attribute
3325 or given initial values via @code{DATA}.
3328 @heading In @code{egcs} 1.1 (versus @code{egcs} 1.0.3):
3331 Support @samp{FORMAT(I<@var{expr}>)} when @var{expr} is a
3332 compile-time constant @code{INTEGER} expression.
3335 Fix @code{g77} @samp{-g} option so procedures that
3336 use @samp{ENTRY} can be stepped through, line by line,
3340 Allow any @code{REAL} argument to intrinsics
3341 @code{Second} and @code{CPU_Time}.
3344 Use @code{tempnam}, if available, to open scratch files
3345 (as in @samp{OPEN(STATUS='SCRATCH')})
3346 so that the @code{TMPDIR} environment variable,
3347 if present, is used.
3350 @code{g77}'s version of @code{libf2c} separates out
3351 the setting of global state
3352 (such as command-line arguments and signal handling)
3353 from @file{main.o} into distinct, new library
3356 This should make it easier to write portable applications
3357 that have their own (non-Fortran) @code{main()} routine
3358 properly set up the @code{libf2c} environment, even
3359 when @code{libf2c} (now @code{libg2c}) is a shared library.
3362 The @code{g77} command now expects the run-time library
3363 to be named @code{libg2c.a} instead of @code{libf2c.a},
3364 to ensure that a version other than the one built and
3365 installed as part of the same @code{g77} version is picked up.
3368 Some diagnostics have been changed from warnings to errors,
3369 to prevent inadvertent use of the resulting, probably buggy,
3371 These mostly include diagnostics about use of unsupported features
3372 in the @code{OPEN}, @code{INQUIRE}, @code{READ}, and
3373 @code{WRITE} statements,
3374 and about truncations of various sorts of constants.
3377 @heading In 0.5.24 and @code{egcs} 1.1 (versus 0.5.23):
3380 @code{g77} now treats @samp{%LOC(@var{expr})} and
3381 @samp{LOC(@var{expr})} as ``ordinary'' expressions
3382 when they are used as arguments in procedure calls.
3383 This change applies only to global (filewide) analysis,
3384 making it consistent with
3385 how @code{g77} actually generates code
3388 Previously, @code{g77} treated these expressions
3389 as denoting special ``pointer'' arguments
3390 for the purposes of filewide analysis.
3393 The @code{g77} driver now ensures that @samp{-lg2c}
3394 is specified in the link phase prior to any
3395 occurrence of @samp{-lm}.
3396 This prevents accidentally linking to a routine
3397 in the SunOS4 @samp{-lm} library
3398 when the generated code wants to link to the one
3399 in @code{libf2c} (@code{libg2c}).
3402 @code{g77} emits more debugging information when
3405 This new information allows, for example,
3406 @kbd{which __g77_length_a} to be used in @code{gdb}
3407 to determine the type of the phantom length argument
3408 supplied with @samp{CHARACTER} variables.
3410 This information pertains to internally-generated
3411 type, variable, and other information,
3412 not to the longstanding deficiencies vis-a-vis
3413 @samp{COMMON} and @samp{EQUIVALENCE}.
3416 The F90 @samp{Date_and_Time} intrinsic now is
3420 The F90 @samp{System_Clock} intrinsic allows
3421 the optional arguments (except for the @samp{Count}
3422 argument) to be omitted.
3428 This release contains several regressions against
3429 version 0.5.22 of @code{g77}, due to using the
3430 ``vanilla'' @code{gcc} back end instead of patching
3431 it to fix a few bugs and improve performance in a
3434 @xref{Actual Bugs,,Actual Bugs We Haven't Fixed Yet},
3435 available in plain-text format in @code{gcc/f/BUGS},
3436 for information on the known bugs in this version,
3437 including the regressions.
3439 Features that have been dropped from this version
3440 of @code{g77} due to their being implemented
3441 via @code{g77}-specific patches to the @code{gcc}
3442 back end in previous releases include:
3446 Support for @code{__restrict__} keyword,
3447 the options @samp{-fargument-alias}, @samp{-fargument-noalias},
3448 and @samp{-fargument-noalias-global},
3449 and the corresponding alias-analysis code.
3451 (@code{egcs} has the alias-analysis
3452 code, but not the @code{__restrict__} keyword.
3453 @code{egcs} @code{g77} users benefit from the alias-analysis
3454 code despite the lack of the @code{__restrict__} keyword,
3455 which is a C-language construct.)
3458 Support for the GNU compiler options
3459 @samp{-fmove-all-movables},
3460 @samp{-freduce-all-givs},
3461 and @samp{-frerun-loop-opt}.
3463 (@code{egcs} supports these options.
3464 @code{g77} users of @code{egcs} benefit from them even if
3465 they are not explicitly specified,
3466 because the defaults are optimized for @code{g77} users.)
3469 Support for the @samp{-W} option warning about
3470 integer division by zero.
3473 The Intel x86-specific option @samp{-malign-double}
3474 applying to stack-allocated data
3475 as well as statically-allocate data.
3479 Support @code{gcc} version 2.8,
3480 and remove support for prior versions of @code{gcc}.
3482 @cindex -@w{}-driver option
3483 @cindex g77 options, -@w{}-driver
3484 @cindex options, -@w{}-driver
3486 Remove support for the @samp{--driver} option,
3487 as @code{g77} now does all the driving,
3488 just like @code{gcc}.
3491 The @code{g77} command now expects the run-time library
3492 to be named @code{libg2c.a} instead of @code{libf2c.a},
3493 to ensure that a version other than the one built and
3494 installed as part of the same @code{g77} version is picked up.
3497 @code{g77}'s version of @code{libf2c} separates out
3498 the setting of global state
3499 (such as command-line arguments and signal handling)
3500 from @file{main.o} into distinct, new library
3503 This should make it easier to write portable applications
3504 that have their own (non-Fortran) @code{main()} routine
3505 properly set up the @code{libf2c} environment, even
3506 when @code{libf2c} (now @code{libg2c}) is a shared library.
3509 Some diagnostics have been changed from warnings to errors,
3510 to prevent inadvertent use of the resulting, probably buggy,
3512 These mostly include diagnostics about use of unsupported features
3513 in the @code{OPEN}, @code{INQUIRE}, @code{READ}, and
3514 @code{WRITE} statements,
3515 and about truncations of various sorts of constants.
3521 Fix @code{Signal} intrinsic so it offers portable
3522 support for 64-bit systems (such as Digital Alphas
3526 Support @samp{FORMAT(I<@var{expr}>)} when @var{expr} is a
3527 compile-time constant @code{INTEGER} expression.
3530 Fix @code{g77} @samp{-g} option so procedures that
3531 use @samp{ENTRY} can be stepped through, line by line,
3535 Allow any @code{REAL} argument to intrinsics
3536 @code{Second} and @code{CPU_Time}.
3539 Allow any numeric argument to intrinsics
3540 @code{Int2} and @code{Int8}.
3543 Use @code{tempnam}, if available, to open scratch files
3544 (as in @samp{OPEN(STATUS='SCRATCH')})
3545 so that the @code{TMPDIR} environment variable,
3546 if present, is used.
3549 Rename the @code{gcc} keyword @code{restrict} to
3550 @code{__restrict__}, to avoid rejecting valid, existing,
3552 Support for @code{restrict} is now more like support
3556 Fix @samp{-fugly-comma} to affect invocations of
3557 only external procedures.
3558 Restore rejection of gratuitous trailing omitted
3559 arguments to intrinsics, as in @samp{I=MAX(3,4,,)}.
3562 Fix compiler so it accepts @samp{-fgnu-intrinsics-*} and
3563 @samp{-fbadu77-intrinsics-*} options.
3566 @heading In @code{egcs} 1.0.2 (versus @code{egcs} 1.0.1):
3569 Fix compiler so it accepts @samp{-fgnu-intrinsics-*} and
3570 @samp{-fbadu77-intrinsics-*} options.
3573 @heading In @code{egcs} 1.0 (versus 0.5.21):
3576 Version 1.0 of @code{egcs}
3577 contains several regressions against
3578 version 0.5.21 of @code{g77},
3580 ``vanilla'' @code{gcc} back end instead of patching
3581 it to fix a few bugs and improve performance in a
3584 @xref{Actual Bugs,,Actual Bugs We Haven't Fixed Yet},
3585 available in plain-text format in @code{gcc/f/BUGS},
3586 for information on the known bugs in this version,
3587 including the regressions.
3589 Features that have been dropped from this version
3590 of @code{g77} due to their being implemented
3591 via @code{g77}-specific patches to the @code{gcc}
3592 back end in previous releases include:
3596 Support for the C-language @code{restrict} keyword.
3599 Support for the @samp{-W} option warning about
3600 integer division by zero.
3603 The Intel x86-specific option @samp{-malign-double}
3604 applying to stack-allocated data
3605 as well as statically-allocate data.
3608 @cindex -@w{}-driver option
3609 @cindex g77 options, -@w{}-driver
3610 @cindex options, -@w{}-driver
3612 Remove support for the @samp{--driver} option,
3613 as @code{g77} now does all the driving,
3614 just like @code{gcc}.
3617 Allow any numeric argument to intrinsics
3618 @code{Int2} and @code{Int8}.
3624 When the @samp{-W} option is specified, @code{gcc}, @code{g77},
3625 and other GNU compilers that incorporate the @code{gcc}
3626 back end as modified by @code{g77}, issue
3627 a warning about integer division by constant zero.
3630 New option @samp{-Wno-globals} disables warnings
3631 about ``suspicious'' use of a name both as a global
3632 name and as the implicit name of an intrinsic, and
3633 warnings about disagreements over the number or natures of
3634 arguments passed to global procedures, or the
3635 natures of the procedures themselves.
3637 The default is to issue such warnings, which are
3638 new as of this version of @code{g77}.
3641 New option @samp{-fno-globals} disables diagnostics
3642 about potentially fatal disagreements
3643 analysis problems, such as disagreements over the
3644 number or natures of arguments passed to global
3645 procedures, or the natures of those procedures themselves.
3647 The default is to issue such diagnostics and flag
3648 the compilation as unsuccessful.
3649 With this option, the diagnostics are issued as
3650 warnings, or, if @samp{-Wno-globals} is specified,
3651 are not issued at all.
3653 This option also disables inlining of global procedures,
3654 to avoid compiler crashes resulting from coding errors
3655 that these diagnostics normally would identify.
3658 Fix @code{libU77} routines that accept file and other names
3659 to strip trailing blanks from them, for consistency
3660 with other implementations.
3661 Blanks may be forcibly appended to such names by
3662 appending a single null character (@samp{CHAR(0)})
3663 to the significant trailing blanks.
3666 Fix @code{CHMOD} intrinsic to work with file names
3667 that have embedded blanks, commas, and so on.
3670 Fix @code{SIGNAL} intrinsic so it accepts an
3671 optional third @samp{Status} argument.
3674 Make many changes to @code{libU77} intrinsics to
3675 support existing code more directly.
3677 Such changes include allowing both subroutine and
3678 function forms of many routines, changing @code{MCLOCK()}
3679 and @code{TIME()} to return @code{INTEGER(KIND=1)} values,
3680 introducing @code{MCLOCK8()} and @code{TIME8()} to
3681 return @code{INTEGER(KIND=2)} values,
3682 and placing functions that are intended to perform
3683 side effects in a new intrinsic group, @code{badu77}.
3686 Add options @samp{-fbadu77-intrinsics-delete},
3687 @samp{-fbadu77-intrinsics-hide}, and so on.
3690 Add @code{INT2} and @code{INT8} intrinsics.
3693 Add @code{CPU_TIME} intrinsic.
3696 Add @code{ALARM} intrinsic.
3699 @code{CTIME} intrinsic now accepts any @code{INTEGER}
3700 argument, not just @code{INTEGER(KIND=2)}.
3703 @code{g77} driver now prints version information (such as produced
3704 by @kbd{g77 -v}) to @code{stderr} instead of @code{stdout}.
3707 The @samp{.r} suffix now designates a Ratfor source file,
3708 to be preprocessed via the @code{ratfor} command, available
3715 The @samp{-fno-typeless-boz} option is now the default.
3717 This option specifies that non-decimal-radix
3718 constants using the prefixed-radix form (such as @samp{Z'1234'})
3719 are to be interpreted as @code{INTEGER(KIND=1)} constants.
3720 Specify @samp{-ftypeless-boz} to cause such
3721 constants to be interpreted as typeless.
3723 (Version 0.5.19 introduced @samp{-fno-typeless-boz} and
3726 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
3727 for information on the @samp{-ftypeless-boz} option.
3730 Options @samp{-ff90-intrinsics-enable} and
3731 @samp{-fvxt-intrinsics-enable} now are the
3734 Some programs might use names that clash with
3735 intrinsic names defined (and now enabled) by these
3736 options or by the new @code{libU77} intrinsics.
3737 Users of such programs might need to compile them
3738 differently (using, for example, @samp{-ff90-intrinsics-disable})
3739 or, better yet, insert appropriate @code{EXTERNAL}
3740 statements specifying that these names are not intended
3741 to be names of intrinsics.
3744 The @samp{ALWAYS_FLUSH} macro is no longer defined when
3745 building @code{libf2c}, which should result in improved
3746 I/O performance, especially over NFS.
3748 @emph{Note:} If you have code that depends on the behavior
3749 of @code{libf2c} when built with @samp{ALWAYS_FLUSH} defined,
3750 you will have to modify @code{libf2c} accordingly before
3751 building it from this and future versions of @code{g77}.
3753 @xref{Output Assumed To Flush}, for more information.
3756 Dave Love's implementation of @code{libU77} has been
3757 added to the version of @code{libf2c} distributed with
3758 and built as part of @code{g77}.
3759 @code{g77} now knows about the routines in this library
3763 New option @samp{-fvxt} specifies that the
3764 source file is written in VXT Fortran, instead of GNU Fortran.
3766 @xref{VXT Fortran}, for more information on the constructs
3767 recognized when the @samp{-fvxt} option is specified.
3770 The @samp{-fvxt-not-f90} option has been deleted,
3771 along with its inverse, @samp{-ff90-not-vxt}.
3773 If you used one of these deleted options, you should
3774 re-read the pertinent documentation to determine which
3775 options, if any, are appropriate for compiling your
3776 code with this version of @code{g77}.
3778 @xref{Other Dialects}, for more information.
3781 The @samp{-fugly} option now issues a warning, as it
3782 likely will be removed in a future version.
3784 (Enabling all the @samp{-fugly-*} options is unlikely
3785 to be feasible, or sensible, in the future,
3786 so users should learn to specify only those
3787 @samp{-fugly-*} options they really need for a
3788 particular source file.)
3791 The @samp{-fugly-assumed} option, introduced in
3792 version 0.5.19, has been changed to
3793 better accommodate old and new code.
3794 @xref{Ugly Assumed-Size Arrays}, for more information.
3797 Related to supporting Alpha (AXP) machines, the @code{LOC()}
3798 intrinsic and @code{%LOC()} construct now return
3799 values of @code{INTEGER(KIND=0)} type,
3800 as defined by the GNU Fortran language.
3802 This type is wide enough
3803 (holds the same number of bits)
3804 as the character-pointer type on the machine.
3806 On most machines, this won't make a difference,
3807 whereas, on Alphas and other systems with 64-bit pointers,
3808 the @code{INTEGER(KIND=0)} type is equivalent to @code{INTEGER(KIND=2)}
3809 (often referred to as @code{INTEGER*8})
3810 instead of the more common @code{INTEGER(KIND=1)}
3811 (often referred to as @code{INTEGER*4}).
3814 Emulate @code{COMPLEX} arithmetic in the @code{g77} front
3815 end, to avoid bugs in @code{complex} support in the
3816 @code{gcc} back end.
3817 New option @samp{-fno-emulate-complex}
3818 causes @code{g77} to revert the 0.5.19 behavior.
3821 Dummy arguments are no longer assumed to potentially alias
3823 other dummy arguments or @code{COMMON} areas when any of
3824 these are defined (assigned to) by Fortran code.
3826 This can result in faster and/or smaller programs when
3827 compiling with optimization enabled, though on some
3828 systems this effect is observed only when @samp{-fforce-addr}
3831 New options @samp{-falias-check}, @samp{-fargument-alias},
3832 @samp{-fargument-noalias},
3833 and @samp{-fno-argument-noalias-global} control the
3834 way @code{g77} handles potential aliasing.
3836 @xref{Aliasing Assumed To Work}, for detailed information on why the
3837 new defaults might result in some programs no longer working the way they
3838 did when compiled by previous versions of @code{g77}.
3841 New option @samp{-fugly-assign} specifies that the
3842 same memory locations are to be used to hold the
3843 values assigned by both statements @samp{I = 3} and
3844 @samp{ASSIGN 10 TO I}, for example.
3845 (Normally, @code{g77} uses a separate memory location
3846 to hold assigned statement labels.)
3848 @xref{Ugly Assigned Labels}, for more information.
3851 @code{FORMAT} and @code{ENTRY} statements now are allowed to
3852 precede @code{IMPLICIT NONE} statements.
3855 Enable full support of @code{INTEGER(KIND=2)}
3856 (often referred to as @code{INTEGER*8})
3858 @code{libf2c} and @file{f2c.h} so that @code{f2c} users
3859 may make full use of its features via the @code{g77}
3860 version of @file{f2c.h} and the @code{INTEGER(KIND=2)}
3861 support routines in the @code{g77} version of @code{libf2c}.
3864 Improve @code{g77} driver and @code{libf2c} so that @samp{g77 -v}
3865 yields version information on the library.
3868 The @code{SNGL} and @code{FLOAT} intrinsics now are
3869 specific intrinsics, instead of synonyms for the
3870 generic intrinsic @code{REAL}.
3873 New intrinsics have been added.
3874 These are @code{REALPART}, @code{IMAGPART},
3876 @code{LONG}, and @code{SHORT}.
3879 A new group of intrinsics, @samp{gnu}, has been added
3880 to contain the new @code{REALPART}, @code{IMAGPART},
3881 and @code{COMPLEX} intrinsics.
3882 An old group, @samp{dcp}, has been removed.
3885 Complain about industry-wide ambiguous references
3886 @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
3887 where @var{expr} is @code{DOUBLE COMPLEX} (or any
3888 complex type other than @code{COMPLEX}), unless
3889 @samp{-ff90} option specifies Fortran 90 interpretation
3890 or new @samp{-fugly-complex} option, in conjunction with
3891 @samp{-fnot-f90}, specifies @code{f2c} interpretation.
3898 A temporary kludge option provides bare-bones information on
3899 @code{COMMON} and @code{EQUIVALENCE} members at debug time.
3900 @xref{Code Gen Options,,Options for Code Generation Conventions},
3901 for information on the @samp{-fdebug-kludge} option.
3904 New @samp{-fonetrip} option specifies FORTRAN-66-style
3905 one-trip @code{DO} loops.
3908 New @samp{-fno-silent} option causes names of program units
3909 to be printed as they are compiled, in a fashion similar to
3910 UNIX @code{f77} and @code{f2c}.
3913 New @samp{-fugly-assumed} option specifies that arrays
3914 dimensioned via @samp{DIMENSION X(1)}, for example, are to be
3915 treated as assumed-size.
3918 New @samp{-fno-typeless-boz} option specifies that non-decimal-radix
3919 constants using the prefixed-radix form (such as @samp{Z'1234'})
3920 are to be interpreted as @code{INTEGER(KIND=1)} constants.
3923 New @samp{-ff66} option is a ``shorthand'' option that specifies
3924 behaviors considered appropriate for FORTRAN 66 programs.
3927 New @samp{-ff77} option is a ``shorthand'' option that specifies
3928 behaviors considered appropriate for UNIX @code{f77} programs.
3931 New @samp{-fugly-comma} and @samp{-fugly-logint} options provided
3932 to perform some of what @samp{-fugly} used to do.
3933 @samp{-fugly} and @samp{-fno-ugly} are now ``shorthand'' options,
3934 in that they do nothing more than enable (or disable) other
3935 @samp{-fugly-*} options.
3938 Change code generation for list-directed I/O so it allows
3939 for new versions of @code{libf2c} that might return non-zero
3940 status codes for some operations previously assumed to always
3943 This change not only affects how @code{IOSTAT=} variables
3944 are set by list-directed I/O, it also affects whether
3945 @code{END=} and @code{ERR=} labels are reached by these
3949 Add intrinsic support for new @code{FTELL} and @code{FSEEK}
3950 procedures in @code{libf2c}.
3953 Add options @samp{--help} and @samp{--version} to the
3954 @code{g77} command, to conform to GNU coding guidelines.
3955 Also add printing of @code{g77} version number when
3956 the @samp{--verbose} (@samp{-v}) option is used.
3963 The @code{BYTE} and @code{WORD} statements now are supported,
3964 to a limited extent.
3967 @code{INTEGER*1}, @code{INTEGER*2}, @code{INTEGER*8},
3968 and their @code{LOGICAL}
3969 equivalents, now are supported to a limited extent.
3970 Among the missing elements are complete intrinsic and constant
3974 Support automatic arrays in procedures.
3975 For example, @samp{REAL A(N)}, where @samp{A} is
3976 not a dummy argument, specifies that @samp{A} is
3978 The size of @samp{A} is calculated from the value
3979 of @samp{N} each time the procedure is called,
3980 that amount of space is allocated, and that space
3981 is freed when the procedure returns to its caller.
3984 Add @samp{-fno-zeros} option, enabled by default,
3985 to reduce compile-time CPU and memory usage for
3986 code that provides initial zero values for variables
3990 Introduce three new options that apply to all compilations
3991 by @code{g77}-aware GNU compilers---@samp{-fmove-all-movables},
3992 @samp{-freduce-all-givs}, and @samp{-frerun-loop-opt}---which
3993 can improve the run-time performance of some programs.
3996 Replace much of the existing documentation with a single
4000 New option @samp{-fno-second-underscore}.
4007 The @code{ERF()} and @code{ERFC()} intrinsics now are generic
4008 intrinsics, mapping to @code{ERF}/@code{DERF} and
4009 @code{ERFC}/@code{DERFC}, respectively.
4010 @emph{Note:} Use @samp{INTRINSIC ERF,ERFC} in any code that
4011 might reference these as generic intrinsics, to
4012 improve the likelihood of diagnostics (instead of subtle run-time
4013 bugs) when using compilers that don't support these as intrinsics.
4016 New option @samp{-Wsurprising}.
4019 DO loops with non-@code{INTEGER} variables now diagnosed only when
4020 @samp{-Wsurprising} specified.
4021 Previously, this was diagnosed @emph{unless} @samp{-fpedantic} or
4022 @samp{-fugly} was specified.
4029 @code{libf2c} changed to output a leading zero (0) digit for floating-point
4030 values output via list-directed and formatted output (to bring @code{g77}
4031 more into line with many existing Fortran implementations---the
4032 ANSI FORTRAN 77 standard leaves this choice to the implementation).
4035 @code{libf2c} no longer built with debugging information
4036 intact, making it much smaller.
4039 Automatic installation of the @code{g77} command now works.
4042 Diagnostic messages now more informative, a la @code{gcc},
4043 including messages like @samp{In function `foo':} and @samp{In file
4047 New group of intrinsics called @samp{unix}, including @code{ABORT},
4048 @code{DERF}, @code{DERFC}, @code{ERF}, @code{ERFC}, @code{EXIT},
4049 @code{FLUSH}, @code{GETARG}, @code{GETENV}, @code{SIGNAL}, and
4053 @samp{-funix-intrinsics-@{delete,hide,disable,enable@}}
4057 @samp{-fno-underscoring} option added.
4060 @samp{--driver} option added to the @code{g77} command.
4063 Support for the @code{gcc} options @samp{-fident} and @samp{-fno-ident}
4067 @samp{g77 -v} returns much more version info, making the submission
4068 of better bug reports easily.
4071 Many improvements to the @code{g77} command to better fulfill its role as
4072 a front-end to the @code{gcc} driver.
4073 For example, @code{g77} now
4074 recognizes @samp{--verbose} as a verbose way of specifying @samp{-v}.
4077 Compiling preprocessed (@file{*.F} and @file{*.fpp}) files now
4078 results in better diagnostics and debugging information, as the
4079 source-location info now is passed all the
4080 way through the compilation process instead of being lost.
4084 @chapter The GNU Fortran Language
4086 @cindex standard, ANSI FORTRAN 77
4087 @cindex ANSI FORTRAN 77 standard
4088 @cindex reference works
4089 GNU Fortran supports a variety of extensions to, and dialects
4090 of, the Fortran language.
4091 Its primary base is the ANSI FORTRAN 77 standard, currently available on
4093 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
4094 or as monolithic text at
4095 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
4096 It offers some extensions that are popular among users
4097 of UNIX @code{f77} and @code{f2c} compilers, some that
4098 are popular among users of other compilers (such as Digital
4099 products), some that are popular among users of the
4100 newer Fortran 90 standard, and some that are introduced
4104 (If you need a text on Fortran,
4105 a few freely available electronic references have pointers from
4106 @uref{http://www.fortran.com/fortran/Books/}.)
4108 Part of what defines a particular implementation of a Fortran
4109 system, such as @code{g77}, is the particular characteristics
4110 of how it supports types, constants, and so on.
4111 Much of this is left up to the implementation by the various
4112 Fortran standards and accepted practice in the industry.
4114 The GNU Fortran @emph{language} is described below.
4115 Much of the material is organized along the same lines
4116 as the ANSI FORTRAN 77 standard itself.
4118 @xref{Other Dialects}, for information on features @code{g77} supports
4119 that are not part of the GNU Fortran language.
4121 @emph{Note}: This portion of the documentation definitely needs a lot
4125 Relationship to the ANSI FORTRAN 77 standard:
4126 * Direction of Language Development:: Where GNU Fortran is headed.
4127 * Standard Support:: Degree of support for the standard.
4129 Extensions to the ANSI FORTRAN 77 standard:
4132 * Terms and Concepts::
4133 * Characters Lines Sequence::
4134 * Data Types and Constants::
4136 * Specification Statements::
4137 * Control Statements::
4138 * Functions and Subroutines::
4139 * Scope and Classes of Names::
4142 @node Direction of Language Development
4143 @section Direction of Language Development
4144 @cindex direction of language development
4145 @cindex features, language
4146 @cindex language features
4148 The purpose of the following description of the GNU Fortran
4149 language is to promote wide portability of GNU Fortran programs.
4151 GNU Fortran is an evolving language, due to the
4152 fact that @code{g77} itself is in beta test.
4153 Some current features of the language might later
4154 be redefined as dialects of Fortran supported by @code{g77}
4155 when better ways to express these features are added to @code{g77},
4157 Such features would still be supported by
4158 @code{g77}, but would be available only when
4159 one or more command-line options were used.
4161 The GNU Fortran @emph{language} is distinct from the
4162 GNU Fortran @emph{compilation system} (@code{g77}).
4164 For example, @code{g77} supports various dialects of
4165 Fortran---in a sense, these are languages other than
4166 GNU Fortran---though its primary
4167 purpose is to support the GNU Fortran language, which also is
4168 described in its documentation and by its implementation.
4170 On the other hand, non-GNU compilers might offer
4171 support for the GNU Fortran language, and are encouraged
4174 Currently, the GNU Fortran language is a fairly fuzzy object.
4175 It represents something of a cross between what @code{g77} accepts
4176 when compiling using the prevailing defaults and what this
4177 document describes as being part of the language.
4179 Future versions of @code{g77} are expected to clarify the
4180 definition of the language in the documentation.
4181 Often, this will mean adding new features to the language, in the form
4182 of both new documentation and new support in @code{g77}.
4183 However, it might occasionally mean removing a feature
4184 from the language itself to ``dialect'' status.
4185 In such a case, the documentation would be adjusted
4186 to reflect the change, and @code{g77} itself would likely be changed
4187 to require one or more command-line options to continue supporting
4190 The development of the GNU Fortran language is intended to strike
4195 Serving as a mostly-upwards-compatible language from the
4196 de facto UNIX Fortran dialect as supported by @code{f77}.
4199 Offering new, well-designed language features.
4200 Attributes of such features include
4201 not making existing code any harder to read
4202 (for those who might be unaware that the new
4203 features are not in use) and
4204 not making state-of-the-art
4205 compilers take longer to issue diagnostics,
4209 Supporting existing, well-written code without gratuitously
4210 rejecting non-standard constructs, regardless of the origin
4211 of the code (its dialect).
4214 Offering default behavior and command-line options to reduce
4215 and, where reasonable, eliminate the need for programmers to make
4216 any modifications to code that already works in existing
4217 production environments.
4220 Diagnosing constructs that have different meanings in different
4221 systems, languages, and dialects, while offering clear,
4222 less ambiguous ways to express each of the different meanings
4223 so programmers can change their code appropriately.
4226 One of the biggest practical challenges for the developers of the
4227 GNU Fortran language is meeting the sometimes contradictory demands
4230 For example, a feature might be widely used in one popular environment,
4231 but the exact same code that utilizes that feature might not work
4232 as expected---perhaps it might mean something entirely different---in
4233 another popular environment.
4235 Traditionally, Fortran compilers---even portable ones---have solved this
4236 problem by simply offering the appropriate feature to users of
4237 the respective systems.
4238 This approach treats users of various Fortran systems and dialects
4239 as remote ``islands'', or camps, of programmers, and assume that these
4240 camps rarely come into contact with each other (or,
4241 especially, with each other's code).
4243 Project GNU takes a radically different approach to software and language
4244 design, in that it assumes that users of GNU software do not necessarily
4245 care what kind of underlying system they are using, regardless
4246 of whether they are using software (at the user-interface
4247 level) or writing it (for example, writing Fortran or C code).
4249 As such, GNU users rarely need consider just what kind of underlying
4250 hardware (or, in many cases, operating system) they are using at any
4252 They can use and write software designed for a general-purpose,
4253 widely portable, heterogenous environment---the GNU environment.
4255 In line with this philosophy, GNU Fortran must evolve into a product
4256 that is widely ported and portable not only in the sense that it can
4257 be successfully built, installed, and run by users, but in the larger
4258 sense that its users can use it in the same way, and expect largely the
4259 same behaviors from it, regardless of the kind of system they are using
4260 at any particular time.
4262 This approach constrains the solutions @code{g77} can use to resolve
4263 conflicts between various camps of Fortran users.
4264 If these two camps disagree about what a particular construct should
4265 mean, @code{g77} cannot simply be changed to treat that particular construct as
4266 having one meaning without comment (such as a warning), lest the users
4267 expecting it to have the other meaning are unpleasantly surprised that
4268 their code misbehaves when executed.
4270 The use of the ASCII backslash character in character constants is
4271 an excellent (and still somewhat unresolved) example of this kind of
4273 @xref{Backslash in Constants}.
4274 Other examples are likely to arise in the future, as @code{g77} developers
4275 strive to improve its ability to accept an ever-wider variety of existing
4276 Fortran code without requiring significant modifications to said code.
4278 Development of GNU Fortran is further constrained by the desire
4279 to avoid requiring programmers to change their code.
4280 This is important because it allows programmers, administrators,
4281 and others to more faithfully evaluate and validate @code{g77}
4282 (as an overall product and as new versions are distributed)
4283 without having to support multiple versions of their programs
4284 so that they continue to work the same way on their existing
4285 systems (non-GNU perhaps, but possibly also earlier versions
4288 @node Standard Support
4289 @section ANSI FORTRAN 77 Standard Support
4290 @cindex ANSI FORTRAN 77 support
4291 @cindex standard support
4292 @cindex support for ANSI FORTRAN 77
4293 @cindex compatibility, FORTRAN 77
4294 @cindex FORTRAN 77 compatibility
4296 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
4297 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
4298 support are those that are probably rarely used in actual code,
4299 some of which are explicitly disallowed by the Fortran 90 standard.
4302 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
4303 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
4304 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
4305 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
4308 @node No Passing External Assumed-length
4309 @subsection No Passing External Assumed-length
4311 @code{g77} disallows passing of an external procedure
4312 as an actual argument if the procedure's
4313 type is declared @code{CHARACTER*(*)}. For example:
4323 It isn't clear whether the standard considers this conforming.
4325 @node No Passing Dummy Assumed-length
4326 @subsection No Passing Dummy Assumed-length
4328 @code{g77} disallows passing of a dummy procedure
4329 as an actual argument if the procedure's
4330 type is declared @code{CHARACTER*(*)}.
4333 SUBROUTINE BAR(CFUNC)
4341 It isn't clear whether the standard considers this conforming.
4343 @node No Pathological Implied-DO
4344 @subsection No Pathological Implied-DO
4346 The @code{DO} variable for an implied-@code{DO} construct in a
4347 @code{DATA} statement may not be used as the @code{DO} variable
4348 for an outer implied-@code{DO} construct. For example, this
4349 fragment is disallowed by @code{g77}:
4352 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
4356 This also is disallowed by Fortran 90, as it offers no additional
4357 capabilities and would have a variety of possible meanings.
4359 Note that it is @emph{very} unlikely that any production Fortran code
4360 tries to use this unsupported construct.
4362 @node No Useless Implied-DO
4363 @subsection No Useless Implied-DO
4365 An array element initializer in an implied-@code{DO} construct in a
4366 @code{DATA} statement must contain at least one reference to the @code{DO}
4367 variables of each outer implied-@code{DO} construct. For example,
4368 this fragment is disallowed by @code{g77}:
4371 DATA (A, I= 1, 1) /1./
4375 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
4376 requirements offer no additional capabilities.
4377 However, @code{g77} doesn't necessarily diagnose all cases
4378 where this requirement is not met.
4380 Note that it is @emph{very} unlikely that any production Fortran code
4381 tries to use this unsupported construct.
4384 @section Conformance
4386 (The following information augments or overrides the information in
4387 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4389 Chapter 1 of that document otherwise serves as the basis
4390 for the relevant aspects of GNU Fortran.)
4392 The definition of the GNU Fortran language is akin to that of
4393 the ANSI FORTRAN 77 language in that it does not generally require
4394 conforming implementations to diagnose cases where programs do
4395 not conform to the language.
4397 However, @code{g77} as a compiler is being developed in a way that
4398 is intended to enable it to diagnose such cases in an easy-to-understand
4401 A program that conforms to the GNU Fortran language should, when
4402 compiled, linked, and executed using a properly installed @code{g77}
4403 system, perform as described by the GNU Fortran language definition.
4404 Reasons for different behavior include, among others:
4408 Use of resources (memory---heap, stack, and so on; disk space; CPU
4409 time; etc.) exceeds those of the system.
4412 Range and/or precision of calculations required by the program
4413 exceeds that of the system.
4416 Excessive reliance on behaviors that are system-dependent
4417 (non-portable Fortran code).
4420 Bugs in the program.
4429 Despite these ``loopholes'', the availability of a clear specification
4430 of the language of programs submitted to @code{g77}, as this document
4431 is intended to provide, is considered an important aspect of providing
4432 a robust, clean, predictable Fortran implementation.
4434 The definition of the GNU Fortran language, while having no special
4435 legal status, can therefore be viewed as a sort of contract, or agreement.
4436 This agreement says, in essence, ``if you write a program in this language,
4437 and run it in an environment (such as a @code{g77} system) that supports
4438 this language, the program should behave in a largely predictable way''.
4441 @section Notation Used in This Chapter
4443 (The following information augments or overrides the information in
4444 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4446 Chapter 1 of that document otherwise serves as the basis
4447 for the relevant aspects of GNU Fortran.)
4449 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
4450 and ``must not'' and ``may not'' denote prohibition.
4451 Terms such as ``might'', ``should'', and ``can'' generally add little or
4452 nothing in the way of weight to the GNU Fortran language itself,
4453 but are used to explain or illustrate the language.
4458 ``The @code{FROBNITZ} statement must precede all executable
4459 statements in a program unit, and may not specify any dummy
4460 arguments. It may specify local or common variables and arrays.
4461 Its use should be limited to portions of the program designed to
4462 be non-portable and system-specific, because it might cause the
4463 containing program unit to behave quite differently on different
4467 Insofar as the GNU Fortran language is specified,
4468 the requirements and permissions denoted by the above sample statement
4469 are limited to the placement of the statement and the kinds of
4470 things it may specify.
4471 The rest of the statement---the content regarding non-portable portions
4472 of the program and the differing behavior of program units containing
4473 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
4475 That content offers advice and warnings about the @code{FROBNITZ}
4478 @emph{Remember:} The GNU Fortran language definition specifies
4479 both what constitutes a valid GNU Fortran program and how,
4480 given such a program, a valid GNU Fortran implementation is
4481 to interpret that program.
4483 It is @emph{not} incumbent upon a valid GNU Fortran implementation
4484 to behave in any particular way, any consistent way, or any
4485 predictable way when it is asked to interpret input that is
4486 @emph{not} a valid GNU Fortran program.
4488 Such input is said to have @dfn{undefined} behavior when
4489 interpreted by a valid GNU Fortran implementation, though
4490 an implementation may choose to specify behaviors for some
4491 cases of inputs that are not valid GNU Fortran programs.
4493 Other notation used herein is that of the GNU texinfo format,
4494 which is used to generate printed hardcopy, on-line hypertext
4495 (Info), and on-line HTML versions, all from a single source
4497 This notation is used as follows:
4501 Keywords defined by the GNU Fortran language are shown
4502 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
4505 Note that, in practice, many Fortran programs are written
4506 in lowercase---uppercase is used in this manual as a
4507 means to readily distinguish keywords and sample Fortran-related
4508 text from the prose in this document.
4511 Portions of actual sample program, input, or output text
4512 look like this: @samp{Actual program text}.
4514 Generally, uppercase is used for all Fortran-specific and
4515 Fortran-related text, though this does not always include
4516 literal text within Fortran code.
4518 For example: @samp{PRINT *, 'My name is Bob'}.
4521 A metasyntactic variable---that is, a name used in this document
4522 to serve as a placeholder for whatever text is used by the
4523 user or programmer--appears as shown in the following example:
4525 ``The @code{INTEGER @var{ivar}} statement specifies that
4526 @var{ivar} is a variable or array of type @code{INTEGER}.''
4528 In the above example, any valid text may be substituted for
4529 the metasyntactic variable @var{ivar} to make the statement
4530 apply to a specific instance, as long as the same text is
4531 substituted for @emph{both} occurrences of @var{ivar}.
4534 Ellipses (``@dots{}'') are used to indicate further text that
4535 is either unimportant or expanded upon further, elsewhere.
4538 Names of data types are in the style of Fortran 90, in most
4541 @xref{Kind Notation}, for information on the relationship
4542 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
4543 and the more traditional, less portably concise nomenclature
4544 (such as @code{INTEGER*4}).
4547 @node Terms and Concepts
4548 @section Fortran Terms and Concepts
4550 (The following information augments or overrides the information in
4551 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4553 Chapter 2 of that document otherwise serves as the basis
4554 for the relevant aspects of GNU Fortran.)
4558 * Statements Comments Lines::
4559 * Scope of Names and Labels::
4562 @node Syntactic Items
4563 @subsection Syntactic Items
4565 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
4567 In GNU Fortran, a symbolic name is at least one character long,
4568 and has no arbitrary upper limit on length.
4569 However, names of entities requiring external linkage (such as
4570 external functions, external subroutines, and @code{COMMON} areas)
4571 might be restricted to some arbitrary length by the system.
4572 Such a restriction is no more constrained than that of one
4573 through six characters.
4575 Underscores (@samp{_}) are accepted in symbol names after the first
4576 character (which must be a letter).
4578 @node Statements Comments Lines
4579 @subsection Statements, Comments, and Lines
4581 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
4583 @cindex comments, trailing
4584 @cindex trailing comments
4585 Use of an exclamation point (@samp{!}) to begin a
4586 trailing comment (a comment that extends to the end of the same
4587 source line) is permitted under the following conditions:
4591 The exclamation point does not appear in column 6.
4592 Otherwise, it is treated as an indicator of a continuation
4596 The exclamation point appears outside a character or hollerith
4598 Otherwise, the exclamation point is considered part of the
4602 The exclamation point appears to the left of any other possible
4604 That is, a trailing comment may contain exclamation points
4605 in their commentary text.
4609 @cindex statements, separated by semicolon
4610 Use of a semicolon (@samp{;}) as a statement separator
4611 is permitted under the following conditions:
4615 The semicolon appears outside a character or hollerith
4617 Otherwise, the semicolon is considered part of the
4621 The semicolon appears to the left of a trailing comment.
4622 Otherwise, the semicolon is considered part of that
4626 Neither a logical @code{IF} statement nor a non-construct
4627 @code{WHERE} statement (a Fortran 90 feature) may be
4628 followed (in the same, possibly continued, line) by
4629 a semicolon used as a statement separator.
4631 This restriction avoids the confusion
4632 that can result when reading a line such as:
4635 IF (VALIDP) CALL FOO; CALL BAR
4639 Some readers might think the @samp{CALL BAR} is executed
4640 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4641 assume its execution is unconditional.
4643 (At present, @code{g77} does not diagnose code that
4644 violates this restriction.)
4647 @node Scope of Names and Labels
4648 @subsection Scope of Symbolic Names and Statement Labels
4651 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4653 Included in the list of entities that have a scope of a
4654 program unit are construct names (a Fortran 90 feature).
4655 @xref{Construct Names}, for more information.
4657 @node Characters Lines Sequence
4658 @section Characters, Lines, and Execution Sequence
4660 (The following information augments or overrides the information in
4661 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4663 Chapter 3 of that document otherwise serves as the basis
4664 for the relevant aspects of GNU Fortran.)
4669 * Continuation Line::
4671 * Statement Labels::
4677 @subsection GNU Fortran Character Set
4680 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4682 Letters include uppercase letters (the twenty-six characters
4683 of the English alphabet) and lowercase letters (their lowercase
4685 Generally, lowercase letters may be used in place of uppercase
4686 letters, though in character and hollerith constants, they
4689 Special characters include:
4693 Semicolon (@samp{;})
4696 Exclamation point (@samp{!})
4699 Double quote (@samp{"})
4702 Backslash (@samp{\})
4705 Question mark (@samp{?})
4708 Hash mark (@samp{#})
4711 Ampersand (@samp{&})
4714 Percent sign (@samp{%})
4717 Underscore (@samp{_})
4720 Open angle (@samp{<})
4723 Close angle (@samp{>})
4726 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4727 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4728 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4732 @cindex blanks (spaces)
4733 Note that this document refers to @key{SPC} as @dfn{space},
4734 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4739 @cindex source file format
4741 @cindex files, source
4743 @cindex code, source
4747 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4749 The way a Fortran compiler views source files depends entirely on the
4750 implementation choices made for the compiler, since those choices
4751 are explicitly left to the implementation by the published Fortran
4754 The GNU Fortran language mandates a view applicable to UNIX-like
4755 text files---files that are made up of an arbitrary number of lines,
4756 each with an arbitrary number of characters (sometimes called stream-based
4759 This view does not apply to types of files that are specified as
4760 having a particular number of characters on every single line (sometimes
4761 referred to as record-based files).
4763 Because a ``line in a program unit is a sequence of 72 characters'',
4764 to quote X3.9-1978, the GNU Fortran language specifies that a
4765 stream-based text file is translated to GNU Fortran lines as follows:
4769 A newline in the file is the character that represents the end of
4770 a line of text to the underlying system.
4771 For example, on ASCII-based systems, a newline is the @key{NL}
4772 character, which has ASCII value 12 (decimal).
4775 Each newline in the file serves to end the line of text that precedes
4776 it (and that does not contain a newline).
4779 The end-of-file marker (@code{EOF}) also serves to end the line
4780 of text that precedes it (and that does not contain a newline).
4783 @cindex blanks (spaces)
4784 Any line of text that is shorter than 72 characters is padded to that length
4785 with spaces (called ``blanks'' in the standard).
4788 Any line of text that is longer than 72 characters is truncated to that
4789 length, but the truncated remainder must consist entirely of spaces.
4792 Characters other than newline and the GNU Fortran character set
4796 For the purposes of the remainder of this description of the GNU
4797 Fortran language, the translation described above has already
4798 taken place, unless otherwise specified.
4800 The result of the above translation is that the source file appears,
4801 in terms of the remainder of this description of the GNU Fortran language,
4802 as if it had an arbitrary
4803 number of 72-character lines, each character being among the GNU Fortran
4806 For example, if the source file itself has two newlines in a row,
4807 the second newline becomes, after the above translation, a single
4808 line containing 72 spaces.
4810 @node Continuation Line
4811 @subsection Continuation Line
4812 @cindex continuation lines, number of
4813 @cindex lines, continuation
4814 @cindex number of continuation lines
4815 @cindex limits on continuation lines
4817 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4819 A continuation line is any line that both
4823 Contains a continuation character, and
4826 Contains only spaces in columns 1 through 5
4829 A continuation character is any character of the GNU Fortran character set
4830 other than space (@key{SPC}) or zero (@samp{0})
4831 in column 6, or a digit (@samp{0} through @samp{9}) in column
4832 7 through 72 of a line that has only spaces to the left of that
4835 The continuation character is ignored as far as the content of
4836 the statement is concerned.
4838 The GNU Fortran language places no limit on the number of
4839 continuation lines in a statement.
4840 In practice, the limit depends on a variety of factors, such as
4841 available memory, statement content, and so on, but no
4842 GNU Fortran system may impose an arbitrary limit.
4845 @subsection Statements
4847 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4849 Statements may be written using an arbitrary number of continuation
4852 Statements may be separated using the semicolon (@samp{;}), except
4853 that the logical @code{IF} and non-construct @code{WHERE} statements
4854 may not be separated from subsequent statements using only a semicolon
4855 as statement separator.
4857 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4858 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4860 These alternatives may be written as normal statements---they are not
4861 subject to the restrictions of the @code{END} statement.
4863 However, no statement other than @code{END} may have an initial line
4864 that appears to be an @code{END} statement---even @code{END PROGRAM},
4865 for example, must not be written as:
4872 @node Statement Labels
4873 @subsection Statement Labels
4875 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4877 A statement separated from its predecessor via a semicolon may be
4882 The semicolon is followed by the label for the statement,
4883 which in turn follows the label.
4886 The label must be no more than five digits in length.
4889 The first digit of the label for the statement is not
4890 the first non-space character on a line.
4891 Otherwise, that character is treated as a continuation
4895 A statement may have only one label defined for it.
4898 @subsection Order of Statements and Lines
4900 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4902 Generally, @code{DATA} statements may precede executable statements.
4903 However, specification statements pertaining to any entities
4904 initialized by a @code{DATA} statement must precede that @code{DATA}
4907 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4908 @samp{INTEGER J} is permitted.
4910 The last line of a program unit may be an @code{END} statement,
4915 An @code{END PROGRAM} statement, if the program unit is a main program.
4918 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4921 An @code{END FUNCTION} statement, if the program unit is a function.
4924 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4928 @subsection Including Source Text
4931 Additional source text may be included in the processing of
4932 the source file via the @code{INCLUDE} directive:
4935 INCLUDE @var{filename}
4939 The source text to be included is identified by @var{filename},
4940 which is a literal GNU Fortran character constant.
4941 The meaning and interpretation of @var{filename} depends on the
4942 implementation, but typically is a filename.
4944 (@code{g77} treats it as a filename that it searches for
4945 in the current directory and/or directories specified
4946 via the @samp{-I} command-line option.)
4948 The effect of the @code{INCLUDE} directive is as if the
4949 included text directly replaced the directive in the source
4950 file prior to interpretation of the program.
4951 Included text may itself use @code{INCLUDE}.
4952 The depth of nested @code{INCLUDE} references depends on
4953 the implementation, but typically is a positive integer.
4955 This virtual replacement treats the statements and @code{INCLUDE}
4956 directives in the included text as syntactically distinct from
4957 those in the including text.
4959 Therefore, the first non-comment line of the included text
4960 must not be a continuation line.
4961 The included text must therefore have, after the non-comment
4962 lines, either an initial line (statement), an @code{INCLUDE}
4963 directive, or nothing (the end of the included text).
4965 Similarly, the including text may end the @code{INCLUDE}
4966 directive with a semicolon or the end of the line, but it
4967 cannot follow an @code{INCLUDE} directive at the end of its
4968 line with a continuation line.
4969 Thus, the last statement in an included text may not be
4972 Any statements between two @code{INCLUDE} directives on the
4973 same line are treated as if they appeared in between the
4974 respective included texts.
4978 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4982 If the text included by @samp{INCLUDE 'A'} constitutes
4983 a @samp{PRINT *, 'A'} statement and the text included by
4984 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4985 then the output of the above sample program would be
4994 (with suitable allowances for how an implementation defines
4995 its handling of output).
4997 Included text must not include itself directly or indirectly,
4998 regardless of whether the @var{filename} used to reference
4999 the text is the same.
5001 Note that @code{INCLUDE} is @emph{not} a statement.
5002 As such, it is neither a non-executable or executable
5004 However, if the text it includes constitutes one or more
5005 executable statements, then the placement of @code{INCLUDE}
5006 is subject to effectively the same restrictions as those
5007 on executable statements.
5009 An @code{INCLUDE} directive may be continued across multiple
5010 lines as if it were a statement.
5011 This permits long names to be used for @var{filename}.
5013 @node Data Types and Constants
5014 @section Data Types and Constants
5016 (The following information augments or overrides the information in
5017 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5019 Chapter 4 of that document otherwise serves as the basis
5020 for the relevant aspects of GNU Fortran.)
5022 To more concisely express the appropriate types for
5023 entities, this document uses the more concise
5024 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
5025 instead of the more traditional, but less portably concise,
5026 byte-size-based nomenclature such as @code{INTEGER*4},
5027 wherever reasonable.
5029 When referring to generic types---in contexts where the
5030 specific precision and range of a type are not important---this
5031 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
5032 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
5034 In some cases, the context requires specification of a
5036 This document uses the @samp{KIND=} notation to accomplish
5037 this throughout, sometimes supplying the more traditional
5038 notation for clarification, though the traditional notation
5039 might not work the same way on all GNU Fortran implementations.
5041 Use of @samp{KIND=} makes this document more concise because
5042 @code{g77} is able to define values for @samp{KIND=} that
5043 have the same meanings on all systems, due to the way the
5044 Fortran 90 standard specifies these values are to be used.
5046 (In particular, that standard permits an implementation to
5047 arbitrarily assign nonnegative values.
5048 There are four distinct sets of assignments: one to the @code{CHARACTER}
5049 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
5050 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
5051 Implementations are free to assign these values in any order,
5052 leave gaps in the ordering of assignments, and assign more than
5053 one value to a representation.)
5055 This makes @samp{KIND=} values superior to the values used
5056 in non-standard statements such as @samp{INTEGER*4}, because
5057 the meanings of the values in those statements vary from machine
5058 to machine, compiler to compiler, even operating system to
5061 However, use of @samp{KIND=} is @emph{not} generally recommended
5062 when writing portable code (unless, for example, the code is
5063 going to be compiled only via @code{g77}, which is a widely
5065 GNU Fortran does not yet have adequate language constructs to
5066 permit use of @samp{KIND=} in a fashion that would make the
5067 code portable to Fortran 90 implementations; and, this construct
5068 is known to @emph{not} be accepted by many popular FORTRAN 77
5069 implementations, so it cannot be used in code that is to be ported
5072 The distinction here is that this document is able to use
5073 specific values for @samp{KIND=} to concisely document the
5074 types of various operations and operands.
5076 A Fortran program should use the FORTRAN 77 designations for the
5077 appropriate GNU Fortran types---such as @code{INTEGER} for
5078 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
5079 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
5080 where no such designations exist, make use of appropriate
5081 techniques (preprocessor macros, parameters, and so on)
5082 to specify the types in a fashion that may be easily adjusted
5083 to suit each particular implementation to which the program
5085 (These types generally won't need to be adjusted for ports of
5088 Further details regarding GNU Fortran data types and constants
5099 @subsection Data Types
5101 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
5103 GNU Fortran supports these types:
5107 Integer (generic type @code{INTEGER})
5110 Real (generic type @code{REAL})
5116 Complex (generic type @code{COMPLEX})
5119 Logical (generic type @code{LOGICAL})
5122 Character (generic type @code{CHARACTER})
5128 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
5130 The generic types shown above are referred to in this document
5131 using only their generic type names.
5132 Such references usually indicate that any specific type (kind)
5133 of that generic type is valid.
5135 For example, a context described in this document as accepting
5136 the @code{COMPLEX} type also is likely to accept the
5137 @code{DOUBLE COMPLEX} type.
5139 The GNU Fortran language supports three ways to specify
5140 a specific kind of a generic type.
5143 * Double Notation:: As in @code{DOUBLE COMPLEX}.
5144 * Star Notation:: As in @code{INTEGER*4}.
5145 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
5148 @node Double Notation
5149 @subsubsection Double Notation
5151 The GNU Fortran language supports two uses of the keyword
5152 @code{DOUBLE} to specify a specific kind of type:
5156 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
5159 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
5162 Use one of the above forms where a type name is valid.
5164 While use of this notation is popular, it doesn't scale
5165 well in a language or dialect rich in intrinsic types,
5166 as is the case for the GNU Fortran language (especially
5167 planned future versions of it).
5169 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
5170 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
5171 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
5172 often are substituted for these, respectively, even though they
5173 do not always have the same meanings on all systems.
5174 (And, the fact that @samp{DOUBLE REAL} does not exist as such
5175 is an inconsistency.)
5177 Therefore, this document uses ``double notation'' only on occasion
5178 for the benefit of those readers who are accustomed to it.
5181 @subsubsection Star Notation
5182 @cindex *@var{n} notation
5184 The following notation specifies the storage size for a type:
5187 @var{generic-type}*@var{n}
5191 @var{generic-type} must be a generic type---one of
5192 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
5193 or @code{CHARACTER}.
5194 @var{n} must be one or more digits comprising a decimal
5195 integer number greater than zero.
5197 Use the above form where a type name is valid.
5199 The @samp{*@var{n}} notation specifies that the amount of storage
5200 occupied by variables and array elements of that type is @var{n}
5201 times the storage occupied by a @code{CHARACTER*1} variable.
5203 This notation might indicate a different degree of precision and/or
5204 range for such variables and array elements, and the functions that
5205 return values of types using this notation.
5206 It does not limit the precision or range of values of that type
5207 in any particular way---use explicit code to do that.
5209 Further, the GNU Fortran language requires no particular values
5210 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
5212 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
5213 on all systems, for example,
5214 but not all implementations are required to do so, and @code{g77}
5215 is known to not support @code{REAL*1} on most (or all) systems.
5217 As a result, except for @var{generic-type} of @code{CHARACTER},
5218 uses of this notation should be limited to isolated
5219 portions of a program that are intended to handle system-specific
5220 tasks and are expected to be non-portable.
5222 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
5223 only @code{CHARACTER}, where it signifies not only the amount
5224 of storage occupied, but the number of characters in entities
5226 However, almost all Fortran compilers have supported this
5227 notation for generic types, though with a variety of meanings
5230 Specifications of types using the @samp{*@var{n}} notation
5231 always are interpreted as specifications of the appropriate
5232 types described in this document using the @samp{KIND=@var{n}}
5233 notation, described below.
5235 While use of this notation is popular, it doesn't serve well
5236 in the context of a widely portable dialect of Fortran, such as
5237 the GNU Fortran language.
5239 For example, even on one particular machine, two or more popular
5240 Fortran compilers might well disagree on the size of a type
5241 declared @code{INTEGER*2} or @code{REAL*16}.
5243 is known to be disagreement over such things among Fortran
5244 compilers on @emph{different} systems.
5246 Further, this notation offers no elegant way to specify sizes
5247 that are not even multiples of the ``byte size'' typically
5248 designated by @code{INTEGER*1}.
5249 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
5250 certainly be possible, but would perhaps be stretching the original
5251 intent of this notation beyond the breaking point in terms
5252 of widespread readability of documentation and code making use
5255 Therefore, this document uses ``star notation'' only on occasion
5256 for the benefit of those readers who are accustomed to it.
5259 @subsubsection Kind Notation
5260 @cindex KIND= notation
5262 The following notation specifies the kind-type selector of a type:
5265 @var{generic-type}(KIND=@var{n})
5269 Use the above form where a type name is valid.
5271 @var{generic-type} must be a generic type---one of
5272 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
5273 or @code{CHARACTER}.
5274 @var{n} must be an integer initialization expression that
5275 is a positive, nonzero value.
5277 Programmers are discouraged from writing these values directly
5279 Future versions of the GNU Fortran language will offer
5280 facilities that will make the writing of code portable
5281 to @code{g77} @emph{and} Fortran 90 implementations simpler.
5283 However, writing code that ports to existing FORTRAN 77
5284 implementations depends on avoiding the @samp{KIND=} construct.
5286 The @samp{KIND=} construct is thus useful in the context
5287 of GNU Fortran for two reasons:
5291 It provides a means to specify a type in a fashion that
5292 is portable across all GNU Fortran implementations (though
5293 not other FORTRAN 77 and Fortran 90 implementations).
5296 It provides a sort of Rosetta stone for this document to use
5297 to concisely describe the types of various operations and
5301 The values of @var{n} in the GNU Fortran language are
5302 assigned using a scheme that:
5306 Attempts to maximize the ability of readers
5307 of this document to quickly familiarize themselves
5308 with assignments for popular types
5311 Provides a unique value for each specific desired
5315 Provides a means to automatically assign new values so
5316 they have a ``natural'' relationship to existing values,
5317 if appropriate, or, if no such relationship exists, will
5318 not interfere with future values assigned on the basis
5319 of such relationships
5322 Avoids using values that are similar to values used
5323 in the existing, popular @samp{*@var{n}} notation,
5324 to prevent readers from expecting that these implied
5325 correspondences work on all GNU Fortran implementations
5328 The assignment system accomplishes this by assigning
5329 to each ``fundamental meaning'' of a specific type a
5330 unique prime number.
5331 Combinations of fundamental meanings---for example, a type
5332 that is two times the size of some other type---are assigned
5333 values of @var{n} that are the products of the values for
5334 those fundamental meanings.
5336 A prime value of @var{n} is never given more than one fundamental
5337 meaning, to avoid situations where some code or system
5338 cannot reasonably provide those meanings in the form of a
5341 The values of @var{n} assigned so far are:
5345 This value is reserved for future use.
5347 The planned future use is for this value to designate,
5348 explicitly, context-sensitive kind-type selection.
5349 For example, the expression @samp{1D0 * 0.1_0} would
5350 be equivalent to @samp{1D0 * 0.1D0}.
5353 This corresponds to the default types for
5354 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
5355 and @code{CHARACTER}, as appropriate.
5357 These are the ``default'' types described in the Fortran 90 standard,
5358 though that standard does not assign any particular @samp{KIND=}
5359 value to these types.
5361 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
5362 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
5365 This corresponds to types that occupy twice as much
5366 storage as the default types.
5367 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
5368 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
5370 These are the ``double precision'' types described in the Fortran 90
5372 though that standard does not assign any particular @samp{KIND=}
5373 value to these types.
5375 @var{n} of 4 thus corresponds to types that occupy four times
5376 as much storage as the default types, @var{n} of 8 to types that
5377 occupy eight times as much storage, and so on.
5379 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
5380 are not necessarily supported by every GNU Fortran implementation.
5383 This corresponds to types that occupy as much
5384 storage as the default @code{CHARACTER} type,
5385 which is the same effective type as @code{CHARACTER(KIND=1)}
5386 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
5388 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
5390 @var{n} of 6 thus corresponds to types that occupy twice as
5391 much storage as the @var{n}=3 types, @var{n} of 12 to types
5392 that occupy four times as much storage, and so on.
5394 These are not necessarily supported by every GNU Fortran
5398 This corresponds to types that occupy half the
5399 storage as the default (@var{n}=1) types.
5401 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
5403 @var{n} of 25 thus corresponds to types that occupy one-quarter
5404 as much storage as the default types.
5406 These are not necessarily supported by every GNU Fortran
5411 This is valid only as @code{INTEGER(KIND=7)} and
5412 denotes the @code{INTEGER} type that has the smallest
5413 storage size that holds a pointer on the system.
5415 A pointer representable by this type is capable of uniquely
5416 addressing a @code{CHARACTER*1} variable, array, array element,
5419 (Typically this is equivalent to @code{INTEGER*4} or,
5420 on 64-bit systems, @code{INTEGER*8}.
5421 In a compatible C implementation, it typically would
5422 be the same size and semantics of the C type @code{void *}.)
5425 Note that these are @emph{proposed} correspondences and might change
5426 in future versions of @code{g77}---avoid writing code depending
5427 on them while @code{g77}, and therefore the GNU Fortran language
5428 it defines, is in beta testing.
5430 Values not specified in the above list are reserved to
5431 future versions of the GNU Fortran language.
5433 Implementation-dependent meanings will be assigned new,
5434 unique prime numbers so as to not interfere with other
5435 implementation-dependent meanings, and offer the possibility
5436 of increasing the portability of code depending on such
5437 types by offering support for them in other GNU Fortran
5440 Other meanings that might be given unique values are:
5444 Types that make use of only half their storage size for
5445 representing precision and range.
5447 For example, some compilers offer options that cause
5448 @code{INTEGER} types to occupy the amount of storage
5449 that would be needed for @code{INTEGER(KIND=2)} types, but the
5450 range remains that of @code{INTEGER(KIND=1)}.
5453 The IEEE single floating-point type.
5456 Types with a specific bit pattern (endianness), such as the
5457 little-endian form of @code{INTEGER(KIND=1)}.
5458 These could permit, conceptually, use of portable code and
5459 implementations on data files written by existing systems.
5462 Future @emph{prime} numbers should be given meanings in as incremental
5463 a fashion as possible, to allow for flexibility and
5464 expressiveness in combining types.
5466 For example, instead of defining a prime number for little-endian
5467 IEEE doubles, one prime number might be assigned the meaning
5468 ``little-endian'', another the meaning ``IEEE double'', and the
5469 value of @var{n} for a little-endian IEEE double would thus
5470 naturally be the product of those two respective assigned values.
5471 (It could even be reasonable to have IEEE values result from the
5472 products of prime values denoting exponent and fraction sizes
5473 and meanings, hidden bit usage, availability and representations
5474 of special values such as subnormals, infinities, and Not-A-Numbers
5477 This assignment mechanism, while not inherently required for
5478 future versions of the GNU Fortran language, is worth using
5479 because it could ease management of the ``space'' of supported
5480 types much easier in the long run.
5482 The above approach suggests a mechanism for specifying inheritance
5483 of intrinsic (built-in) types for an entire, widely portable
5485 It is certainly reasonable that, unlike programmers of other languages
5486 offering inheritance mechanisms that employ verbose names for classes
5487 and subclasses, along with graphical browsers to elucidate the
5488 relationships, Fortran programmers would employ
5489 a mechanism that works by multiplying prime numbers together
5490 and finding the prime factors of such products.
5492 Most of the advantages for the above scheme have been explained
5494 One disadvantage is that it could lead to the defining,
5495 by the GNU Fortran language, of some fairly large prime numbers.
5496 This could lead to the GNU Fortran language being declared
5497 ``munitions'' by the United States Department of Defense.
5500 @subsection Constants
5502 @cindex types, constants
5504 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
5506 A @dfn{typeless constant} has one of the following forms:
5509 '@var{binary-digits}'B
5510 '@var{octal-digits}'O
5511 '@var{hexadecimal-digits}'Z
5512 '@var{hexadecimal-digits}'X
5516 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5517 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5518 and @samp{0123456789ABCDEFabcdef}, respectively.
5519 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5522 Typeless constants have values that depend on the context in which
5525 All other constants, called @dfn{typed constants}, are interpreted---converted
5526 to internal form---according to their inherent type.
5527 Thus, context is @emph{never} a determining factor for the type, and hence
5528 the interpretation, of a typed constant.
5529 (All constants in the ANSI FORTRAN 77 language are typed constants.)
5531 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
5532 Fortran (called default INTEGER in Fortran 90),
5533 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
5534 additional precision specified is lost, and even when used in a
5535 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
5536 and @samp{1D0} is always type @code{REAL(KIND=2)}.
5539 @subsection Integer Type
5541 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
5543 An integer constant also may have one of the following forms:
5546 B'@var{binary-digits}'
5547 O'@var{octal-digits}'
5548 Z'@var{hexadecimal-digits}'
5549 X'@var{hexadecimal-digits}'
5553 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
5554 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
5555 and @samp{0123456789ABCDEFabcdef}, respectively.
5556 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
5559 @node Character Type
5560 @subsection Character Type
5562 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
5564 A character constant may be delimited by a pair of double quotes
5565 (@samp{"}) instead of apostrophes.
5566 In this case, an apostrophe within the constant represents
5567 a single apostrophe, while a double quote is represented in
5568 the source text of the constant by two consecutive double
5569 quotes with no intervening spaces.
5571 @cindex zero-length CHARACTER
5572 @cindex null CHARACTER strings
5573 @cindex empty CHARACTER strings
5574 @cindex strings, empty
5575 @cindex CHARACTER, null
5576 A character constant may be empty (have a length of zero).
5578 A character constant may include a substring specification,
5579 The value of such a constant is the value of the substring---for
5580 example, the value of @samp{'hello'(3:5)} is the same
5581 as the value of @samp{'llo'}.
5584 @section Expressions
5586 (The following information augments or overrides the information in
5587 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5589 Chapter 6 of that document otherwise serves as the basis
5590 for the relevant aspects of GNU Fortran.)
5597 @subsection The @code{%LOC()} Construct
5598 @cindex %LOC() construct
5604 The @code{%LOC()} construct is an expression
5605 that yields the value of the location of its argument,
5606 @var{arg}, in memory.
5607 The size of the type of the expression depends on the system---typically,
5608 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5609 though it is actually type @code{INTEGER(KIND=7)}.
5611 The argument to @code{%LOC()} must be suitable as the
5612 left-hand side of an assignment statement.
5613 That is, it may not be a general expression involving
5614 operators such as addition, subtraction, and so on,
5615 nor may it be a constant.
5617 Use of @code{%LOC()} is recommended only for code that
5618 is accessing facilities outside of GNU Fortran, such as
5619 operating system or windowing facilities.
5620 It is best to constrain such uses to isolated portions of
5621 a program---portions that deal specifically and exclusively
5622 with low-level, system-dependent facilities.
5623 Such portions might well provide a portable interface for
5624 use by the program as a whole, but are themselves not
5625 portable, and should be thoroughly tested each time they
5626 are rebuilt using a new compiler or version of a compiler.
5628 Do not depend on @code{%LOC()} returning a pointer that
5629 can be safely used to @emph{define} (change) the argument.
5630 While this might work in some circumstances, it is hard
5631 to predict whether it will continue to work when a program
5632 (that works using this unsafe behavior)
5633 is recompiled using different command-line options or
5634 a different version of @code{g77}.
5636 Generally, @code{%LOC()} is safe when used as an argument
5637 to a procedure that makes use of the value of the corresponding
5638 dummy argument only during its activation, and only when
5639 such use is restricted to referencing (reading) the value
5640 of the argument to @code{%LOC()}.
5642 @emph{Implementation Note:} Currently, @code{g77} passes
5643 arguments (those not passed using a construct such as @code{%VAL()})
5644 by reference or descriptor, depending on the type of
5645 the actual argument.
5646 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5647 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5648 in fact might compile to identical code.
5650 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5651 ``pass, by value, the address of @samp{I} in memory''.
5652 While @samp{CALL FOO(I)} might use that same approach in a
5653 particular version of @code{g77}, another version or compiler
5654 might choose a different implementation, such as copy-in/copy-out,
5655 to effect the desired behavior---and which will therefore not
5656 necessarily compile to the same code as would
5657 @samp{CALL FOO(%VAL(%LOC(I)))}
5658 using the same version or compiler.
5660 @xref{Debugging and Interfacing}, for detailed information on
5661 how this particular version of @code{g77} implements various
5664 @node Specification Statements
5665 @section Specification Statements
5667 (The following information augments or overrides the information in
5668 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5670 Chapter 8 of that document otherwise serves as the basis
5671 for the relevant aspects of GNU Fortran.)
5679 @subsection @code{NAMELIST} Statement
5680 @cindex NAMELIST statement
5681 @cindex statements, NAMELIST
5683 The @code{NAMELIST} statement, and related I/O constructs, are
5684 supported by the GNU Fortran language in essentially the same
5685 way as they are by @code{f2c}.
5687 @node DOUBLE COMPLEX
5688 @subsection @code{DOUBLE COMPLEX} Statement
5689 @cindex DOUBLE COMPLEX
5691 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5692 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5694 @node Control Statements
5695 @section Control Statements
5697 (The following information augments or overrides the information in
5698 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5700 Chapter 11 of that document otherwise serves as the basis
5701 for the relevant aspects of GNU Fortran.)
5711 @subsection DO WHILE
5713 @cindex MIL-STD 1753
5715 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5716 Fortran 90 standards, is provided by the GNU Fortran language.
5721 @cindex MIL-STD 1753
5723 The @code{END DO} statement is provided by the GNU Fortran language.
5725 This statement is used in one of two ways:
5729 The Fortran 90 meaning, in which it specifies the termination
5730 point of a single @code{DO} loop started with a @code{DO} statement
5731 that specifies no termination label.
5734 The MIL-STD 1753 meaning, in which it specifies the termination
5735 point of one or more @code{DO} loops, all of which start with a
5736 @code{DO} statement that specify the label defined for the
5737 @code{END DO} statement.
5739 This kind of @code{END DO} statement is merely a synonym for
5740 @code{CONTINUE}, except it is permitted only when the statement
5741 is labeled and a target of one or more labeled @code{DO} loops.
5743 It is expected that this use of @code{END DO} will be removed from
5744 the GNU Fortran language in the future, though it is likely that
5745 it will long be supported by @code{g77} as a dialect form.
5748 @node Construct Names
5749 @subsection Construct Names
5750 @cindex construct names
5752 The GNU Fortran language supports construct names as defined
5753 by the Fortran 90 standard.
5754 These names are local to the program unit and are defined
5758 @var{construct-name}: @var{block-statement}
5762 Here, @var{construct-name} is the construct name itself;
5763 its definition is connoted by the single colon (@samp{:}); and
5764 @var{block-statement} is an @code{IF}, @code{DO},
5765 or @code{SELECT CASE} statement that begins a block.
5767 A block that is given a construct name must also specify the
5768 same construct name in its termination statement:
5771 END @var{block} @var{construct-name}
5775 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5778 @node CYCLE and EXIT
5779 @subsection The @code{CYCLE} and @code{EXIT} Statements
5781 The @code{CYCLE} and @code{EXIT} statements specify that
5782 the remaining statements in the current iteration of a
5783 particular active (enclosing) @code{DO} loop are to be skipped.
5785 @code{CYCLE} specifies that these statements are skipped,
5786 but the @code{END DO} statement that marks the end of the
5787 @code{DO} loop be executed---that is, the next iteration,
5788 if any, is to be started.
5789 If the statement marking the end of the @code{DO} loop is
5790 not @code{END DO}---in other words, if the loop is not
5791 a block @code{DO}---the @code{CYCLE} statement does not
5792 execute that statement, but does start the next iteration (if any).
5794 @code{EXIT} specifies that the loop specified by the
5795 @code{DO} construct is terminated.
5797 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5798 is the innermost enclosing @code{DO} loop when the following
5806 Otherwise, the following forms specify the construct name
5807 of the pertinent @code{DO} loop:
5810 CYCLE @var{construct-name}
5811 EXIT @var{construct-name}
5814 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5816 However, they cannot be easily thought of as @code{GO TO} statements
5817 in obscure cases involving FORTRAN 77 loops.
5826 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5831 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5832 above are equivalent to a @code{GO TO} statement to either label
5833 @samp{10} or @samp{20}.
5835 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5836 above fragment, it is helpful to first translate it to its equivalent
5837 using only block @code{DO} loops:
5845 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5852 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5853 to @code{GO TO} so they may be more easily understood by programmers
5854 accustomed to FORTRAN coding:
5859 IF (J .EQ. 5) GOTO 18
5861 IF (K .EQ. 3) GO TO 12
5862 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5870 Thus, the @code{CYCLE} statement in the innermost loop skips over
5871 the @code{PRINT} statement as it begins the next iteration of the
5872 loop, while the @code{EXIT} statement in the middle loop ends that
5873 loop but @emph{not} the outermost loop.
5875 @node Functions and Subroutines
5876 @section Functions and Subroutines
5878 (The following information augments or overrides the information in
5879 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5881 Chapter 15 of that document otherwise serves as the basis
5882 for the relevant aspects of GNU Fortran.)
5888 * Generics and Specifics::
5889 * REAL() and AIMAG() of Complex::
5890 * CMPLX() of DOUBLE PRECISION::
5892 * f77/f2c Intrinsics::
5893 * Table of Intrinsic Functions::
5897 @subsection The @code{%VAL()} Construct
5898 @cindex %VAL() construct
5904 The @code{%VAL()} construct specifies that an argument,
5905 @var{arg}, is to be passed by value, instead of by reference
5908 @code{%VAL()} is restricted to actual arguments in
5909 invocations of external procedures.
5911 Use of @code{%VAL()} is recommended only for code that
5912 is accessing facilities outside of GNU Fortran, such as
5913 operating system or windowing facilities.
5914 It is best to constrain such uses to isolated portions of
5915 a program---portions the deal specifically and exclusively
5916 with low-level, system-dependent facilities.
5917 Such portions might well provide a portable interface for
5918 use by the program as a whole, but are themselves not
5919 portable, and should be thoroughly tested each time they
5920 are rebuilt using a new compiler or version of a compiler.
5922 @emph{Implementation Note:} Currently, @code{g77} passes
5923 all arguments either by reference or by descriptor.
5925 Thus, use of @code{%VAL()} tends to be restricted to cases
5926 where the called procedure is written in a language other
5927 than Fortran that supports call-by-value semantics.
5928 (C is an example of such a language.)
5930 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5931 for detailed information on
5932 how this particular version of @code{g77} passes arguments
5936 @subsection The @code{%REF()} Construct
5937 @cindex %REF() construct
5943 The @code{%REF()} construct specifies that an argument,
5944 @var{arg}, is to be passed by reference, instead of by
5945 value or descriptor.
5947 @code{%REF()} is restricted to actual arguments in
5948 invocations of external procedures.
5950 Use of @code{%REF()} is recommended only for code that
5951 is accessing facilities outside of GNU Fortran, such as
5952 operating system or windowing facilities.
5953 It is best to constrain such uses to isolated portions of
5954 a program---portions the deal specifically and exclusively
5955 with low-level, system-dependent facilities.
5956 Such portions might well provide a portable interface for
5957 use by the program as a whole, but are themselves not
5958 portable, and should be thoroughly tested each time they
5959 are rebuilt using a new compiler or version of a compiler.
5961 Do not depend on @code{%REF()} supplying a pointer to the
5962 procedure being invoked.
5963 While that is a likely implementation choice, other
5964 implementation choices are available that preserve Fortran
5965 pass-by-reference semantics without passing a pointer to
5966 the argument, @var{arg}.
5967 (For example, a copy-in/copy-out implementation.)
5969 @emph{Implementation Note:} Currently, @code{g77} passes
5971 (other than variables and arrays of type @code{CHARACTER})
5973 Future versions of, or dialects supported by, @code{g77} might
5974 not pass @code{CHARACTER} functions by reference.
5976 Thus, use of @code{%REF()} tends to be restricted to cases
5977 where @var{arg} is type @code{CHARACTER} but the called
5978 procedure accesses it via a means other than the method
5979 used for Fortran @code{CHARACTER} arguments.
5981 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5982 how this particular version of @code{g77} passes arguments
5986 @subsection The @code{%DESCR()} Construct
5987 @cindex %DESCR() construct
5993 The @code{%DESCR()} construct specifies that an argument,
5994 @var{arg}, is to be passed by descriptor, instead of by
5997 @code{%DESCR()} is restricted to actual arguments in
5998 invocations of external procedures.
6000 Use of @code{%DESCR()} is recommended only for code that
6001 is accessing facilities outside of GNU Fortran, such as
6002 operating system or windowing facilities.
6003 It is best to constrain such uses to isolated portions of
6004 a program---portions the deal specifically and exclusively
6005 with low-level, system-dependent facilities.
6006 Such portions might well provide a portable interface for
6007 use by the program as a whole, but are themselves not
6008 portable, and should be thoroughly tested each time they
6009 are rebuilt using a new compiler or version of a compiler.
6011 Do not depend on @code{%DESCR()} supplying a pointer
6012 and/or a length passed by value
6013 to the procedure being invoked.
6014 While that is a likely implementation choice, other
6015 implementation choices are available that preserve the
6016 pass-by-reference semantics without passing a pointer to
6017 the argument, @var{arg}.
6018 (For example, a copy-in/copy-out implementation.)
6019 And, future versions of @code{g77} might change the
6020 way descriptors are implemented, such as passing a
6021 single argument pointing to a record containing the
6022 pointer/length information instead of passing that same
6023 information via two arguments as it currently does.
6025 @emph{Implementation Note:} Currently, @code{g77} passes
6026 all variables and arrays of type @code{CHARACTER}
6028 Future versions of, or dialects supported by, @code{g77} might
6029 pass @code{CHARACTER} functions by descriptor as well.
6031 Thus, use of @code{%DESCR()} tends to be restricted to cases
6032 where @var{arg} is not type @code{CHARACTER} but the called
6033 procedure accesses it via a means similar to the method
6034 used for Fortran @code{CHARACTER} arguments.
6036 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
6037 how this particular version of @code{g77} passes arguments
6040 @node Generics and Specifics
6041 @subsection Generics and Specifics
6042 @cindex generic intrinsics
6043 @cindex intrinsics, generic
6045 The ANSI FORTRAN 77 language defines generic and specific
6047 In short, the distinctions are:
6051 @emph{Specific} intrinsics have
6052 specific types for their arguments and a specific return
6056 @emph{Generic} intrinsics are treated,
6057 on a case-by-case basis in the program's source code,
6058 as one of several possible specific intrinsics.
6060 Typically, a generic intrinsic has a return type that
6061 is determined by the type of one or more of its arguments.
6064 The GNU Fortran language generalizes these concepts somewhat,
6065 especially by providing intrinsic subroutines and generic
6066 intrinsics that are treated as either a specific intrinsic subroutine
6067 or a specific intrinsic function (e.g. @code{SECOND}).
6069 However, GNU Fortran avoids generalizing this concept to
6070 the point where existing code would be accepted as meaning
6071 something possibly different than what was intended.
6073 For example, @code{ABS} is a generic intrinsic, so all working
6074 code written using @code{ABS} of an @code{INTEGER} argument
6075 expects an @code{INTEGER} return value.
6076 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
6077 argument returns an @code{INTEGER*2} return value.
6079 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
6080 an @code{INTEGER(KIND=1)} argument.
6081 Code that passes something other than an @code{INTEGER(KIND=1)}
6082 argument to @code{IABS} is not valid GNU Fortran code, because
6083 it is not clear what the author intended.
6085 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
6086 is not defined by the GNU Fortran language, because the programmer
6087 might have used that construct to mean any of the following, subtly
6092 Convert @samp{J} to @code{INTEGER(KIND=1)} first
6093 (as if @samp{IABS(INT(J))} had been written).
6096 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
6097 (as if @samp{INT(ABS(J))} had been written).
6100 No conversion (as if @samp{ABS(J)} had been written).
6103 The distinctions matter especially when types and values wider than
6104 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
6105 operations performing more ``arithmetic'' than absolute-value, are involved.
6107 The following sample program is not a valid GNU Fortran program, but
6108 might be accepted by other compilers.
6109 If so, the output is likely to be revealing in terms of how a given
6110 compiler treats intrinsics (that normally are specific) when they
6111 are given arguments that do not conform to their stated requirements:
6113 @cindex JCB002 program
6117 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
6118 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
6121 C Written by James Craig Burley 1997-02-20.
6122 C Contact via Internet email: burley@@gnu.org
6125 C Determine how compilers handle non-standard IDIM
6126 C on INTEGER*2 operands, which presumably can be
6127 C extrapolated into understanding how the compiler
6128 C generally treats specific intrinsics that are passed
6129 C arguments not of the correct types.
6131 C If your compiler implements INTEGER*2 and INTEGER
6132 C as the same type, change all INTEGER*2 below to
6137 INTEGER*2 ISMALL, ILARGE
6138 INTEGER*2 ITOOLG, ITWO
6142 C Find smallest INTEGER*2 number.
6146 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
6151 C Find largest INTEGER*2 number.
6155 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
6160 C Multiplying by two adds stress to the situation.
6164 C Need a number that, added to -2, is too wide to fit in I*2.
6168 C Use IDIM the straightforward way.
6170 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
6172 C Calculate result for first interpretation.
6174 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
6176 C Calculate result for second interpretation.
6178 ITMP = ILARGE - ISMALL
6179 I3 = (INT (ITMP)) * ITWO + ITOOLG
6181 C Calculate result for third interpretation.
6183 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
6187 PRINT *, 'ILARGE=', ILARGE
6188 PRINT *, 'ITWO=', ITWO
6189 PRINT *, 'ITOOLG=', ITOOLG
6190 PRINT *, 'ISMALL=', ISMALL
6199 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
6200 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
6203 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
6204 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
6207 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
6208 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
6211 PRINT *, 'Results need careful analysis.'
6215 No future version of the GNU Fortran language
6216 will likely permit specific intrinsic invocations with wrong-typed
6217 arguments (such as @code{IDIM} in the above example), since
6218 it has been determined that disagreements exist among
6219 many production compilers on the interpretation of
6221 These disagreements strongly suggest that Fortran programmers,
6222 and certainly existing Fortran programs, disagree about the
6223 meaning of such invocations.
6225 The first version of @samp{JCB002} didn't accommodate some compilers'
6226 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
6228 In such a case, these compilers apparently convert both
6229 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
6230 instead of doing an @code{INTEGER*2} subtraction on the
6231 original values in @samp{I1} and @samp{I2}.
6233 However, the results of the careful analyses done on the outputs
6234 of programs compiled by these various compilers show that they
6235 all implement either @samp{Interp 1} or @samp{Interp 2} above.
6237 Specifically, it is believed that the new version of @samp{JCB002}
6238 above will confirm that:
6242 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
6243 @code{f77} compilers all implement @samp{Interp 1}.
6246 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
6249 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
6250 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
6253 If you get different results than the above for the stated
6254 compilers, or have results for other compilers that might be
6255 worth adding to the above list, please let us know the details
6256 (compiler product, version, machine, results, and so on).
6258 @node REAL() and AIMAG() of Complex
6259 @subsection @code{REAL()} and @code{AIMAG()} of Complex
6260 @cindex REAL intrinsic
6261 @cindex intrinsics, REAL
6262 @cindex AIMAG intrinsic
6263 @cindex intrinsics, AIMAG
6265 The GNU Fortran language disallows @code{REAL(@var{expr})}
6266 and @code{AIMAG(@var{expr})},
6267 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
6268 except when they are used in the following way:
6271 REAL(REAL(@var{expr}))
6272 REAL(AIMAG(@var{expr}))
6276 The above forms explicitly specify that the desired effect
6277 is to convert the real or imaginary part of @var{expr}, which might
6278 be some @code{REAL} type other than @code{REAL(KIND=1)},
6279 to type @code{REAL(KIND=1)},
6280 and have that serve as the value of the expression.
6282 The GNU Fortran language offers clearly named intrinsics to extract the
6283 real and imaginary parts of a complex entity without any
6287 REALPART(@var{expr})
6288 IMAGPART(@var{expr})
6291 To express the above using typical extended FORTRAN 77,
6292 use the following constructs
6293 (when @var{expr} is @code{COMPLEX(KIND=2)}):
6300 The FORTRAN 77 language offers no way
6301 to explicitly specify the real and imaginary parts of a complex expression of
6302 arbitrary type, apparently as a result of requiring support for
6303 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
6304 The concepts of converting an expression to type @code{REAL(KIND=1)} and
6305 of extracting the real part of a complex expression were
6306 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
6307 they happened to have the exact same effect in that language
6308 (due to having only one @code{COMPLEX} type).
6310 @emph{Note:} When @samp{-ff90} is in effect,
6311 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
6312 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
6313 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
6314 treated as @samp{REAL(REALPART(@var{expr}))}.
6316 @xref{Ugly Complex Part Extraction}, for more information.
6318 @node CMPLX() of DOUBLE PRECISION
6319 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
6320 @cindex CMPLX intrinsic
6321 @cindex intrinsics, CMPLX
6323 In accordance with Fortran 90 and at least some (perhaps all)
6324 other compilers, the GNU Fortran language defines @code{CMPLX()}
6325 as always returning a result that is type @code{COMPLEX(KIND=1)}.
6327 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
6328 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
6331 CMPLX(SNGL(D1), SNGL(D2))
6334 (It was necessary for Fortran 90 to specify this behavior
6335 for @code{DOUBLE PRECISION} arguments, since that is
6336 the behavior mandated by FORTRAN 77.)
6338 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
6339 which is provided by some FORTRAN 77 compilers to construct
6340 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
6342 However, this solution does not scale well when more @code{COMPLEX} types
6343 (having various precisions and ranges) are offered by Fortran implementations.
6345 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
6346 an extra argument used to specify the desired kind of complex
6348 However, this solution is somewhat awkward to use, and
6349 @code{g77} currently does not support it.
6351 The GNU Fortran language provides a simple way to build a complex
6352 value out of two numbers, with the precise type of the value
6353 determined by the types of the two numbers (via the usual
6354 type-promotion mechanism):
6357 COMPLEX(@var{real}, @var{imag})
6360 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
6361 performs no conversion other than to put them together to form a
6362 complex result of the same (complex version of real) type.
6364 @xref{Complex Intrinsic}, for more information.
6367 @subsection MIL-STD 1753 Support
6368 @cindex MIL-STD 1753
6370 The GNU Fortran language includes the MIL-STD 1753 intrinsics
6371 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
6372 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
6373 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
6375 @node f77/f2c Intrinsics
6376 @subsection @code{f77}/@code{f2c} Intrinsics
6378 The bit-manipulation intrinsics supported by traditional
6379 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
6380 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
6383 Also supported are the intrinsics @code{CDABS},
6384 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
6385 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
6386 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
6387 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
6390 @node Table of Intrinsic Functions
6391 @subsection Table of Intrinsic Functions
6392 @cindex intrinsics, table of
6393 @cindex table of intrinsics
6395 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
6397 The GNU Fortran language adds various functions, subroutines, types,
6398 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
6399 The complete set of intrinsics supported by the GNU Fortran language
6402 Note that a name is not treated as that of an intrinsic if it is
6403 specified in an @code{EXTERNAL} statement in the same program unit;
6404 if a command-line option is used to disable the groups to which
6405 the intrinsic belongs; or if the intrinsic is not named in an
6406 @code{INTRINSIC} statement and a command-line option is used to
6407 hide the groups to which the intrinsic belongs.
6409 So, it is recommended that any reference in a program unit to
6410 an intrinsic procedure that is not a standard FORTRAN 77
6411 intrinsic be accompanied by an appropriate @code{INTRINSIC}
6412 statement in that program unit.
6413 This sort of defensive programming makes it more
6414 likely that an implementation will issue a diagnostic rather
6415 than generate incorrect code for such a reference.
6417 The terminology used below is based on that of the Fortran 90
6418 standard, so that the text may be more concise and accurate:
6422 @code{OPTIONAL} means the argument may be omitted.
6425 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
6426 (generally named @samp{A}) may be specified.
6429 @samp{scalar} means the argument must not be an array (must
6430 be a variable or array element, or perhaps a constant if expressions
6434 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
6437 @code{INTENT(IN)} means the argument must be an expression
6438 (such as a constant or a variable that is defined upon invocation
6442 @code{INTENT(OUT)} means the argument must be definable by the
6443 invocation of the intrinsic (that is, must not be a constant nor
6444 an expression involving operators other than array reference and
6445 substring reference).
6448 @code{INTENT(INOUT)} means the argument must be defined prior to,
6449 and definable by, invocation of the intrinsic (a combination of
6450 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
6453 @xref{Kind Notation} for explanation of @code{KIND}.
6457 (Note that the empty lines appearing in the menu below
6458 are not intentional---they result from a bug in the
6459 GNU @code{makeinfo} program@dots{}a program that, if it
6460 did not exist, would leave this document in far worse shape!)
6463 @c The actual documentation for intrinsics comes from
6464 @c intdoc.texi, which in turn is automatically generated
6465 @c from the internal g77 tables in intrin.def _and_ the
6466 @c largely hand-written text in intdoc.h. So, if you want
6467 @c to change or add to existing documentation on intrinsics,
6468 @c you probably want to edit intdoc.h.
6480 @include intdoc.texi
6482 @node Scope and Classes of Names
6483 @section Scope and Classes of Symbolic Names
6484 @cindex symbolic names
6487 (The following information augments or overrides the information in
6488 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
6490 Chapter 18 of that document otherwise serves as the basis
6491 for the relevant aspects of GNU Fortran.)
6494 * Underscores in Symbol Names::
6497 @node Underscores in Symbol Names
6498 @subsection Underscores in Symbol Names
6501 Underscores (@samp{_}) are accepted in symbol names after the first
6502 character (which must be a letter).
6504 @node Other Dialects
6505 @chapter Other Dialects
6507 GNU Fortran supports a variety of features that are not
6508 considered part of the GNU Fortran language itself, but
6509 are representative of various dialects of Fortran that
6510 @code{g77} supports in whole or in part.
6512 Any of the features listed below might be disallowed by
6513 @code{g77} unless some command-line option is specified.
6514 Currently, some of the features are accepted using the
6515 default invocation of @code{g77}, but that might change
6518 @emph{Note: This portion of the documentation definitely needs a lot
6522 * Source Form:: Details of fixed-form and free-form source.
6523 * Trailing Comment:: Use of @samp{/*} to start a comment.
6524 * Debug Line:: Use of @samp{D} in column 1.
6525 * Dollar Signs:: Use of @samp{$} in symbolic names.
6526 * Case Sensitivity:: Uppercase and lowercase in source files.
6527 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6528 * Fortran 90:: @dots{}versus the GNU Fortran language.
6529 * Pedantic Compilation:: Enforcing the standard.
6530 * Distensions:: Misfeatures supported by GNU Fortran.
6534 @section Source Form
6535 @cindex source file format
6537 @cindex files, source
6539 @cindex code, source
6543 GNU Fortran accepts programs written in either fixed form or
6547 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6548 allowing tabs) and Fortran 90's fixed form.
6550 Free form corresponds to
6551 Fortran 90's free form (though possibly not entirely up-to-date, and
6552 without complaining about some things that for which Fortran 90 requires
6553 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6555 The way a Fortran compiler views source files depends entirely on the
6556 implementation choices made for the compiler, since those choices
6557 are explicitly left to the implementation by the published Fortran
6559 GNU Fortran currently tries to be somewhat like a few popular compilers
6560 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6561 definition along with more
6562 flexibility offered by command-line options is likely to be offered
6565 This section describes how @code{g77} interprets source lines.
6568 * Carriage Returns:: Carriage returns ignored.
6569 * Tabs:: Tabs converted to spaces.
6570 * Short Lines:: Short lines padded with spaces (fixed-form only).
6571 * Long Lines:: Long lines truncated.
6572 * Ampersands:: Special Continuation Lines.
6575 @node Carriage Returns
6576 @subsection Carriage Returns
6577 @cindex carriage returns
6579 Carriage returns (@samp{\r}) in source lines are ignored.
6580 This is somewhat different from @code{f2c}, which seems to treat them as
6581 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6582 inside such constants.
6586 @cindex tab characters
6588 A source line with a @key{TAB} character anywhere in it is treated as
6589 entirely significant---however long it is---instead of ending in
6590 column 72 (for fixed-form source) or 132 (for free-form source).
6591 This also is different from @code{f2c}, which encodes tabs as
6592 @samp{\t} (the ASCII @key{TAB} character) inside character
6593 and Hollerith constants, but nevertheless seems to treat the column
6594 position as if it had been affected by the canonical tab positioning.
6596 @code{g77} effectively
6597 translates tabs to the appropriate number of spaces (a la the default
6598 for the UNIX @code{expand} command) before doing any other processing, other
6599 than (currently) noting whether a tab was found on a line and using this
6600 information to decide how to interpret the length of the line and continued
6603 Note that this default behavior probably will change for version 0.6,
6604 when it will presumably be available via a command-line option.
6605 The default as of version 0.6 is planned to be a ``pure visual''
6606 model, where tabs are immediately
6607 converted to spaces and otherwise have no effect, so the way a typical
6608 user sees source lines produces a consistent result no matter how the
6609 spacing in those source lines is actually implemented via tabs, spaces,
6610 and trailing tabs/spaces before newline.
6611 Command-line options are likely to be added to specify whether all or
6612 just-tabbed lines are to be extended to 132 or full input-line length,
6613 and perhaps even an option will be added to specify the truncated-line
6614 behavior to which some Digital compilers default (and which affects
6615 the way continued character/Hollerith constants are interpreted).
6618 @subsection Short Lines
6619 @cindex short source lines
6620 @cindex space-padding
6622 @cindex source lines, short
6623 @cindex lines, short
6625 Source lines shorter than the applicable fixed-form length are treated as
6626 if they were padded with spaces to that length.
6627 (None of this is relevant to source files written in free form.)
6630 continued character and Hollerith constants, and is a different
6631 interpretation than provided by some other popular compilers
6632 (although a bit more consistent with the traditional punched-card
6633 basis of Fortran and the way the Fortran standard expressed fixed
6636 @code{g77} might someday offer an option to warn about cases where differences
6637 might be seen as a result of this treatment, and perhaps an option to
6638 specify the alternate behavior as well.
6640 Note that this padding cannot apply to lines that are effectively of
6641 infinite length---such lines are specified using command-line options
6642 like @samp{-ffixed-line-length-none}, for example.
6645 @subsection Long Lines
6646 @cindex long source lines
6649 @cindex source lines, long
6651 Source lines longer than the applicable length are truncated to that
6653 Currently, @code{g77} does not warn if the truncated characters are
6654 not spaces, to accommodate existing code written for systems that
6655 treated truncated text as commentary (especially in columns 73 through 80).
6657 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6658 for information on the @samp{-ffixed-line-length-@var{n}} option,
6659 which can be used to set the line length applicable to fixed-form
6663 @subsection Ampersand Continuation Line
6664 @cindex ampersand continuation line
6665 @cindex continuation line, ampersand
6667 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6668 continuation line, imitating the behavior of @code{f2c}.
6670 @node Trailing Comment
6671 @section Trailing Comment
6673 @code{g77} supports use of @samp{/*} to start a trailing
6675 In the GNU Fortran language, @samp{!} is used for this purpose.
6677 @samp{/*} is not in the GNU Fortran language
6678 because the use of @samp{/*} in a program might
6679 suggest to some readers that a block, not trailing, comment is
6680 started (and thus ended by @samp{*/}, not end of line),
6681 since that is the meaning of @samp{/*} in C.
6683 Also, such readers might think they can use @samp{//} to start
6684 a trailing comment as an alternative to @samp{/*}, but
6685 @samp{//} already denotes concatenation, and such a ``comment''
6686 might actually result in a program that compiles without
6687 error (though it would likely behave incorrectly).
6693 Use of @samp{D} or @samp{d} as the first character (column 1) of
6694 a source line denotes a debug line.
6696 In turn, a debug line is treated as either a comment line
6697 or a normal line, depending on whether debug lines are enabled.
6699 When treated as a comment line, a line beginning with @samp{D} or
6700 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6701 When treated as a normal line, such a line is treated as if
6702 the first character was @key{SPC} (space).
6704 (Currently, @code{g77} provides no means for treating debug
6705 lines as normal lines.)
6708 @section Dollar Signs in Symbol Names
6712 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6713 when the @samp{-fdollar-ok} option is specified.
6715 @node Case Sensitivity
6716 @section Case Sensitivity
6717 @cindex case sensitivity
6718 @cindex source file format
6719 @cindex code, source
6721 @cindex uppercase letters
6722 @cindex lowercase letters
6723 @cindex letters, uppercase
6724 @cindex letters, lowercase
6726 GNU Fortran offers the programmer way too much flexibility in deciding
6727 how source files are to be treated vis-a-vis uppercase and lowercase
6729 There are 66 useful settings that affect case sensitivity, plus 10
6730 settings that are nearly useless, with the remaining 116 settings
6731 being either redundant or useless.
6733 None of these settings have any effect on the contents of comments
6734 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6735 or of character or Hollerith constants.
6736 Note that things like the @samp{E} in the statement
6737 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6738 are considered built-in keywords, and so are affected by
6741 Low-level switches are identified in this section as follows:
6745 Source Case Conversion:
6749 Preserve (see Note 1)
6751 Convert to Upper Case
6753 Convert to Lower Case
6757 Built-in Keyword Matching:
6761 Match Any Case (per-character basis)
6763 Match Upper Case Only
6765 Match Lower Case Only
6767 Match InitialCaps Only (see tables for spellings)
6771 Built-in Intrinsic Matching:
6775 Match Any Case (per-character basis)
6777 Match Upper Case Only
6779 Match Lower Case Only
6781 Match InitialCaps Only (see tables for spellings)
6785 User-defined Symbol Possibilities (warnings only):
6789 Allow Any Case (per-character basis)
6791 Allow Upper Case Only
6793 Allow Lower Case Only
6795 Allow InitialCaps Only (see Note 2)
6799 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6800 consistent with these source switches---in the sense that input will be
6801 expected to meet the same requirements as source code in terms
6802 of matching symbol names and keywords (for the exponent letters).
6804 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6805 which uppercases @code{NAMELIST} input and symbol names for matching.
6806 This means not only that @code{NAMELIST} output currently shows symbol
6807 (and keyword) names in uppercase even if lower-case source
6808 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6809 adequately supported when source case preservation (option A0)
6812 If A0 is selected, a warning message will be
6813 output for each @code{NAMELIST} statement to this effect.
6815 of the program is undefined at run time if two or more symbol names
6816 appear in a given @code{NAMELIST} such that the names are identical
6817 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6818 For complete and total elegance, perhaps there should be a warning
6819 when option A2 is selected, since the output of NAMELIST is currently
6820 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6821 but that seems to be overkill for a product in beta test.
6823 Note 2: Rules for InitialCaps names are:
6827 Must be a single uppercase letter, @strong{or}
6829 Must start with an uppercase letter and contain at least one
6833 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6834 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6836 Note that most, but not all, built-in names meet these
6837 requirements---the exceptions are some of the two-letter format
6838 specifiers, such as @samp{BN} and @samp{BZ}.
6840 Here are the names of the corresponding command-line options:
6843 A0: -fsource-case-preserve
6844 A1: -fsource-case-upper
6845 A2: -fsource-case-lower
6847 B0: -fmatch-case-any
6848 B1: -fmatch-case-upper
6849 B2: -fmatch-case-lower
6850 B3: -fmatch-case-initcap
6852 C0: -fintrin-case-any
6853 C1: -fintrin-case-upper
6854 C2: -fintrin-case-lower
6855 C3: -fintrin-case-initcap
6857 D0: -fsymbol-case-any
6858 D1: -fsymbol-case-upper
6859 D2: -fsymbol-case-lower
6860 D3: -fsymbol-case-initcap
6863 Useful combinations of the above settings, along with abbreviated
6864 option names that set some of these combinations all at once:
6867 1: A0-- B0--- C0--- D0--- -fcase-preserve
6868 2: A0-- B0--- C0--- D-1--
6869 3: A0-- B0--- C0--- D--2-
6870 4: A0-- B0--- C0--- D---3
6871 5: A0-- B0--- C-1-- D0---
6872 6: A0-- B0--- C-1-- D-1--
6873 7: A0-- B0--- C-1-- D--2-
6874 8: A0-- B0--- C-1-- D---3
6875 9: A0-- B0--- C--2- D0---
6876 10: A0-- B0--- C--2- D-1--
6877 11: A0-- B0--- C--2- D--2-
6878 12: A0-- B0--- C--2- D---3
6879 13: A0-- B0--- C---3 D0---
6880 14: A0-- B0--- C---3 D-1--
6881 15: A0-- B0--- C---3 D--2-
6882 16: A0-- B0--- C---3 D---3
6883 17: A0-- B-1-- C0--- D0---
6884 18: A0-- B-1-- C0--- D-1--
6885 19: A0-- B-1-- C0--- D--2-
6886 20: A0-- B-1-- C0--- D---3
6887 21: A0-- B-1-- C-1-- D0---
6888 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6889 23: A0-- B-1-- C-1-- D--2-
6890 24: A0-- B-1-- C-1-- D---3
6891 25: A0-- B-1-- C--2- D0---
6892 26: A0-- B-1-- C--2- D-1--
6893 27: A0-- B-1-- C--2- D--2-
6894 28: A0-- B-1-- C--2- D---3
6895 29: A0-- B-1-- C---3 D0---
6896 30: A0-- B-1-- C---3 D-1--
6897 31: A0-- B-1-- C---3 D--2-
6898 32: A0-- B-1-- C---3 D---3
6899 33: A0-- B--2- C0--- D0---
6900 34: A0-- B--2- C0--- D-1--
6901 35: A0-- B--2- C0--- D--2-
6902 36: A0-- B--2- C0--- D---3
6903 37: A0-- B--2- C-1-- D0---
6904 38: A0-- B--2- C-1-- D-1--
6905 39: A0-- B--2- C-1-- D--2-
6906 40: A0-- B--2- C-1-- D---3
6907 41: A0-- B--2- C--2- D0---
6908 42: A0-- B--2- C--2- D-1--
6909 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6910 44: A0-- B--2- C--2- D---3
6911 45: A0-- B--2- C---3 D0---
6912 46: A0-- B--2- C---3 D-1--
6913 47: A0-- B--2- C---3 D--2-
6914 48: A0-- B--2- C---3 D---3
6915 49: A0-- B---3 C0--- D0---
6916 50: A0-- B---3 C0--- D-1--
6917 51: A0-- B---3 C0--- D--2-
6918 52: A0-- B---3 C0--- D---3
6919 53: A0-- B---3 C-1-- D0---
6920 54: A0-- B---3 C-1-- D-1--
6921 55: A0-- B---3 C-1-- D--2-
6922 56: A0-- B---3 C-1-- D---3
6923 57: A0-- B---3 C--2- D0---
6924 58: A0-- B---3 C--2- D-1--
6925 59: A0-- B---3 C--2- D--2-
6926 60: A0-- B---3 C--2- D---3
6927 61: A0-- B---3 C---3 D0---
6928 62: A0-- B---3 C---3 D-1--
6929 63: A0-- B---3 C---3 D--2-
6930 64: A0-- B---3 C---3 D---3 -fcase-initcap
6931 65: A-1- B01-- C01-- D01-- -fcase-upper
6932 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6935 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6936 (except comments, character constants, and Hollerith strings) must
6937 be entered in uppercase.
6938 Use @samp{-fcase-strict-upper} to specify this
6941 Number 43 is like Number 22 except all input must be lowercase. Use
6942 @samp{-fcase-strict-lower} to specify this combination.
6944 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6945 non-UNIX machines whereby all the source is translated to uppercase.
6946 Use @samp{-fcase-upper} to specify this combination.
6948 Number 66 is the ``canonical'' UNIX model whereby all the source is
6949 translated to lowercase.
6950 Use @samp{-fcase-lower} to specify this combination.
6952 There are a few nearly useless combinations:
6955 67: A-1- B01-- C01-- D--2-
6956 68: A-1- B01-- C01-- D---3
6957 69: A-1- B01-- C--23 D01--
6958 70: A-1- B01-- C--23 D--2-
6959 71: A-1- B01-- C--23 D---3
6960 72: A--2 B01-- C0-2- D-1--
6961 73: A--2 B01-- C0-2- D---3
6962 74: A--2 B01-- C-1-3 D0-2-
6963 75: A--2 B01-- C-1-3 D-1--
6964 76: A--2 B01-- C-1-3 D---3
6967 The above allow some programs to be compiled but with restrictions that
6968 make most useful programs impossible: Numbers 67 and 72 warn about
6969 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6971 68 and 73 warn about any user-defined symbol names longer than one
6972 character that don't have at least one non-alphabetic character after
6974 Numbers 69 and 74 disallow any references to intrinsics;
6975 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6976 67+69, 68+69, 72+74, and 73+74, respectively.
6978 All redundant combinations are shown in the above tables anyplace
6979 where more than one setting is shown for a low-level switch.
6980 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6981 The ``proper'' setting in such a case is the one that copies the setting
6982 of switch A---any other setting might slightly reduce the speed of
6983 the compiler, though possibly to an unmeasurable extent.
6985 All remaining combinations are useless in that they prevent successful
6986 compilation of non-null source files (source files with something other
6990 @section VXT Fortran
6992 @cindex VXT extensions
6993 @cindex extensions, VXT
6994 @code{g77} supports certain constructs that
6995 have different meanings in VXT Fortran than they
6996 do in the GNU Fortran language.
6998 Generally, this manual uses the invented term VXT Fortran to refer
6999 VAX FORTRAN (circa v4).
7000 That compiler offered many popular features, though not necessarily
7001 those that are specific to the VAX processor architecture,
7002 the VMS operating system,
7003 or Digital Equipment Corporation's Fortran product line.
7004 (VAX and VMS probably are trademarks of Digital Equipment
7007 An extension offered by a Digital Fortran product that also is
7008 offered by several other Fortran products for different kinds of
7009 systems is probably going to be considered for inclusion in @code{g77}
7010 someday, and is considered a VXT Fortran feature.
7012 The @samp{-fvxt} option generally specifies that, where
7013 the meaning of a construct is ambiguous (means one thing
7014 in GNU Fortran and another in VXT Fortran), the VXT Fortran
7015 meaning is to be assumed.
7018 * Double Quote Meaning:: @samp{"2000} as octal constant.
7019 * Exclamation Point:: @samp{!} in column 6.
7022 @node Double Quote Meaning
7023 @subsection Meaning of Double Quote
7024 @cindex double quotes
7025 @cindex character constants
7026 @cindex constants, character
7027 @cindex octal constants
7028 @cindex constants, octal
7030 @code{g77} treats double-quote (@samp{"})
7031 as beginning an octal constant of @code{INTEGER(KIND=1)} type
7032 when the @code{-fvxt} option is specified.
7033 The form of this octal constant is
7040 where @var{octal-digits} is a nonempty string of characters in
7041 the set @samp{01234567}.
7043 For example, the @code{-fvxt} option permits this:
7051 The above program would print the value @samp{16}.
7053 @xref{Integer Type}, for information on the preferred construct
7054 for integer constants specified using GNU Fortran's octal notation.
7056 (In the GNU Fortran language, the double-quote character (@samp{"})
7057 delimits a character constant just as does apostrophe (@samp{'}).
7058 There is no way to allow
7059 both constructs in the general case, since statements like
7060 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
7062 @node Exclamation Point
7063 @subsection Meaning of Exclamation Point in Column 6
7064 @cindex exclamation points
7065 @cindex continuation character
7066 @cindex characters, continuation
7067 @cindex comment character
7068 @cindex characters, comment
7070 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
7071 a fixed-form source file
7072 as a continuation character rather than
7073 as the beginning of a comment
7074 (as it does in any other column)
7075 when the @code{-fvxt} option is specified.
7077 The following program, when run, prints a message indicating
7078 whether it is interpreted according to GNU Fortran (and Fortran 90)
7079 rules or VXT Fortran rules:
7082 C234567 (This line begins in column 1.)
7085 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
7086 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
7087 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
7091 (In the GNU Fortran and Fortran 90 languages, exclamation point is
7092 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
7093 marks a line as a continuation line when it appears in column 6.)
7097 @cindex compatibility, Fortran 90
7098 @cindex Fortran 90 compatibility
7100 The GNU Fortran language includes a number of features that are
7101 part of Fortran 90, even when the @samp{-ff90} option is not specified.
7102 The features enabled by @samp{-ff90} are intended to be those that,
7103 when @samp{-ff90} is not specified, would have another
7104 meaning to @code{g77}---usually meaning something invalid in the
7105 GNU Fortran language.
7107 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
7108 to gratuitously reject Fortran 90 constructs.
7109 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
7110 to do that, although its implementation is certainly incomplete at
7113 When @samp{-ff90} is specified:
7117 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
7118 where @var{expr} is @code{COMPLEX} type,
7119 is the same type as the real part of @var{expr}.
7121 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
7122 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
7123 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
7126 @node Pedantic Compilation
7127 @section Pedantic Compilation
7128 @cindex pedantic compilation
7129 @cindex compilation, pedantic
7131 The @samp{-fpedantic} command-line option specifies that @code{g77}
7132 is to warn about code that is not standard-conforming.
7133 This is useful for finding
7134 some extensions @code{g77} accepts that other compilers might not accept.
7135 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
7136 always imply @samp{-fpedantic}.)
7138 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
7139 for conforming code.
7140 With @samp{-ff90} in force, Fortran 90 is used.
7142 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
7143 and @samp{-fno-f90} are in force are:
7147 Automatic arrays, as in
7156 where @samp{A} is not listed in any @code{ENTRY} statement,
7157 and thus is not a dummy argument.
7160 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
7162 These commas are disallowed by FORTRAN 77, but, while strictly
7163 superfluous, are syntactically elegant,
7164 especially given that commas are required in statements such
7165 as @samp{READ 99, I} and @samp{PRINT *, J}.
7166 Many compilers permit the superfluous commas for this reason.
7169 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
7171 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
7172 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
7174 An example of an implicit use is the expression @samp{C*D},
7175 where @samp{C} is @code{COMPLEX(KIND=1)}
7176 and @samp{D} is @code{DOUBLE PRECISION}.
7177 This expression is prohibited by ANSI FORTRAN 77
7178 because the rules of promotion would suggest that it
7179 produce a @code{DOUBLE COMPLEX} result---a type not
7180 provided for by that standard.
7183 Automatic conversion of numeric
7184 expressions to @code{INTEGER(KIND=1)} in contexts such as:
7188 Array-reference indexes.
7190 Alternate-return values.
7192 Computed @code{GOTO}.
7194 @code{FORMAT} run-time expressions (not yet supported).
7196 Dimension lists in specification statements.
7198 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
7200 Sizes of @code{CHARACTER} entities in specification statements.
7202 Kind types in specification entities (a Fortran 90 feature).
7204 Initial, terminal, and incrementation parameters for implied-@code{DO}
7205 constructs in @code{DATA} statements.
7209 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
7210 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
7211 expressions are disallowed anyway).
7214 Zero-size array dimensions, as in:
7217 INTEGER I(10,20,4:2)
7221 Zero-length @code{CHARACTER} entities, as in:
7228 Substring operators applied to character constants and named
7232 PRINT *, 'hello'(3:5)
7236 Null arguments passed to statement function, as in:
7243 Disagreement among program units regarding whether a given @code{COMMON}
7244 area is @code{SAVE}d (for targets where program units in a single source
7245 file are ``glued'' together as they typically are for UNIX development
7249 Disagreement among program units regarding the size of a
7250 named @code{COMMON} block.
7253 Specification statements following first @code{DATA} statement.
7255 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
7256 but not @samp{INTEGER I}.
7257 The @samp{-fpedantic} option disallows both of these.)
7260 Semicolon as statement separator, as in:
7267 @c Comma before list of I/O items in @code{WRITE}
7268 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
7269 @c statements, as with @code{READ} (as explained above).
7272 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
7275 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
7279 Expressions having two arithmetic operators in a row, such
7283 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
7284 following constructs result in diagnostics:
7288 Use of semicolon as a statement separator on a line
7289 that has an @code{INCLUDE} directive.
7293 @section Distensions
7295 @cindex ugly features
7296 @cindex features, ugly
7298 The @samp{-fugly-*} command-line options determine whether certain
7299 features supported by VAX FORTRAN and other such compilers, but considered
7300 too ugly to be in code that can be changed to use safer and/or more
7301 portable constructs, are accepted.
7302 These are humorously referred to as ``distensions'',
7303 extensions that just plain look ugly in the harsh light of day.
7305 @emph{Note:} The @samp{-fugly} option, which currently serves
7306 as shorthand to enable all of the distensions below, is likely to
7307 be removed in a future version of @code{g77}.
7308 That's because it's likely new distensions will be added that
7309 conflict with existing ones in terms of assigning meaning to
7310 a given chunk of code.
7311 (Also, it's pretty clear that users should not use @samp{-fugly}
7312 as shorthand when the next release of @code{g77} might add a
7313 distension to that that causes their existing code, when recompiled,
7314 to behave differently---perhaps even fail to compile or run
7318 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
7319 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
7320 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
7321 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
7322 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
7323 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
7324 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
7327 @node Ugly Implicit Argument Conversion
7328 @subsection Implicit Argument Conversion
7329 @cindex Hollerith constants
7330 @cindex constants, Hollerith
7332 The @samp{-fno-ugly-args} option disables
7333 passing typeless and Hollerith constants as actual arguments
7334 in procedure invocations.
7343 These constructs can be too easily used to create non-portable
7344 code, but are not considered as ``ugly'' as others.
7345 Further, they are widely used in existing Fortran source code
7346 in ways that often are quite portable.
7347 Therefore, they are enabled by default.
7349 @node Ugly Assumed-Size Arrays
7350 @subsection Ugly Assumed-Size Arrays
7351 @cindex arrays, assumed-size
7352 @cindex assumed-size arrays
7353 @cindex DIMENSION X(1)
7355 The @samp{-fugly-assumed} option enables
7356 the treatment of any array with a final dimension specified as @samp{1}
7357 as an assumed-size array, as if @samp{*} had been specified
7360 For example, @samp{DIMENSION X(1)} is treated as if it
7361 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
7362 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
7363 or @code{ENTRY} statement in the same program unit.
7365 Use an explicit lower bound to avoid this interpretation.
7366 For example, @samp{DIMENSION X(1:1)} is never treated as if
7367 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
7368 Nor is @samp{DIMENSION X(2-1)} affected by this option,
7369 since that kind of expression is unlikely to have been
7370 intended to designate an assumed-size array.
7372 This option is used to prevent warnings being issued about apparent
7373 out-of-bounds reference such as @samp{X(2) = 99}.
7375 It also prevents the array from being used in contexts that
7376 disallow assumed-size arrays, such as @samp{PRINT *,X}.
7377 In such cases, a diagnostic is generated and the source file is
7380 The construct affected by this option is used only in old code
7381 that pre-exists the widespread acceptance of adjustable and assumed-size
7382 arrays in the Fortran community.
7384 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
7385 treated if @samp{X} is listed as a dummy argument only
7386 @emph{after} the @code{DIMENSION} statement (presumably in
7387 an @code{ENTRY} statement).
7388 For example, @samp{-fugly-assumed} has no effect on the
7389 following program unit:
7400 @node Ugly Complex Part Extraction
7401 @subsection Ugly Complex Part Extraction
7402 @cindex complex values
7404 @cindex imaginary part
7406 The @samp{-fugly-complex} option enables
7407 use of the @code{REAL()} and @code{AIMAG()}
7408 intrinsics with arguments that are
7409 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
7411 With @samp{-ff90} in effect, these intrinsics return
7412 the unconverted real and imaginary parts (respectively)
7415 With @samp{-fno-f90} in effect, these intrinsics convert
7416 the real and imaginary parts to @code{REAL(KIND=1)}, and return
7417 the result of that conversion.
7419 Due to this ambiguity, the GNU Fortran language defines
7420 these constructs as invalid, except in the specific
7421 case where they are entirely and solely passed as an
7422 argument to an invocation of the @code{REAL()} intrinsic.
7430 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7431 and @samp{-fno-ugly-complex} is in effect, because the
7434 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7435 is specified, in which case the appropriate interpretation is
7436 chosen and no diagnostic is issued.
7438 @xref{CMPAMBIG}, for information on how to cope with existing
7439 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7440 with @code{COMPLEX(KIND=2)} arguments.
7442 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7443 intrinsic, used to extract the real part of a complex expression
7445 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7446 intrinsic, used to extract the imaginary part of a complex expression
7449 @node Ugly Null Arguments
7450 @subsection Ugly Null Arguments
7451 @cindex trailing commas
7452 @cindex commas, trailing
7453 @cindex null arguments
7454 @cindex arguments, null
7456 The @samp{-fugly-comma} option enables use of a single trailing comma
7457 to mean ``pass an extra trailing null argument''
7458 in a list of actual arguments to an external procedure,
7459 and use of an empty list of arguments to such a procedure
7460 to mean ``pass a single null argument''.
7462 @cindex omitting arguments
7463 @cindex arguments, omitting
7464 (Null arguments often are used in some procedure-calling
7465 schemes to indicate omitted arguments.)
7467 For example, @samp{CALL FOO(,)} means ``pass
7468 two null arguments'', rather than ``pass one null argument''.
7469 Also, @samp{CALL BAR()} means ``pass one null argument''.
7471 This construct is considered ``ugly'' because it does not
7472 provide an elegant way to pass a single null argument
7473 that is syntactically distinct from passing no arguments.
7474 That is, this construct changes the meaning of code that
7475 makes no use of the construct.
7477 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7478 and @samp{I = JFUNC()} pass a single null argument, instead
7479 of passing no arguments as required by the Fortran 77 and
7482 @emph{Note:} Many systems gracefully allow the case
7483 where a procedure call passes one extra argument that the
7484 called procedure does not expect.
7486 So, in practice, there might be no difference in
7487 the behavior of a program that does @samp{CALL FOO()}
7488 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7489 in force as compared to its behavior when compiled
7490 with the default, @samp{-fno-ugly-comma}, in force,
7491 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7492 arguments to be passed.
7494 @node Ugly Conversion of Initializers
7495 @subsection Ugly Conversion of Initializers
7497 The constructs disabled by @samp{-fno-ugly-init} are:
7500 @cindex Hollerith constants
7501 @cindex constants, Hollerith
7503 Use of Hollerith and typeless constants in contexts where they set
7504 initial (compile-time) values for variables, arrays, and named
7505 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7506 type-declaration statements specifying initial values.
7508 Here are some sample initializations that are disabled by the
7509 @samp{-fno-ugly-init} option:
7512 PARAMETER (VAL='9A304FFE'X)
7513 REAL*8 STRING/8HOUTPUT00/
7517 @cindex character constants
7518 @cindex constants, character
7520 In the same contexts as above, use of character constants to initialize
7521 numeric items and vice versa (one constant per item).
7523 Here are more sample initializations that are disabled by the
7524 @samp{-fno-ugly-init} option:
7529 PARAMETER (IA = 'A')
7530 PARAMETER (BELL = 7)
7534 Use of Hollerith and typeless constants on the right-hand side
7535 of assignment statements to numeric types, and in other
7536 contexts (such as passing arguments in invocations of
7537 intrinsic procedures and statement functions) that
7538 are treated as assignments to known types (the dummy
7539 arguments, in these cases).
7541 Here are sample statements that are disabled by the
7542 @samp{-fno-ugly-init} option:
7546 PRINT *, IMAX0(2HAB, 2HBA)
7550 The above constructs, when used,
7551 can tend to result in non-portable code.
7552 But, they are widely used in existing Fortran code in ways
7553 that often are quite portable.
7554 Therefore, they are enabled by default.
7556 @node Ugly Integer Conversions
7557 @subsection Ugly Integer Conversions
7559 The constructs enabled via @samp{-fugly-logint} are:
7563 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7565 context (typically implies nonportable dependencies on how a
7566 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7569 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7573 The above constructs are disabled by default because use
7574 of them tends to lead to non-portable code.
7575 Even existing Fortran code that uses that often turns out
7576 to be non-portable, if not outright buggy.
7578 Some of this is due to differences among implementations as
7579 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7580 @code{INTEGER} values---Fortran code that assumes a particular
7581 coding is likely to use one of the above constructs, and is
7582 also likely to not work correctly on implementations using
7583 different encodings.
7585 @xref{Equivalence Versus Equality}, for more information.
7587 @node Ugly Assigned Labels
7588 @subsection Ugly Assigned Labels
7589 @cindex ASSIGN statement
7590 @cindex statements, ASSIGN
7591 @cindex assigned labels
7594 The @samp{-fugly-assign} option forces @code{g77} to use the
7595 same storage for assigned labels as it would for a normal
7596 assignment to the same variable.
7598 For example, consider the following code fragment:
7606 Normally, for portability and improved diagnostics, @code{g77}
7607 reserves distinct storage for a ``sibling'' of @samp{I}, used
7608 only for @code{ASSIGN} statements to that variable (along with
7609 the corresponding assigned-@code{GOTO} and assigned-@samp{FORMAT}-I/O
7610 statements that reference the variable).
7612 However, some code (that violates the ANSI FORTRAN 77 standard)
7613 attempts to copy assigned labels among variables involved with
7614 @code{ASSIGN} statements, as in:
7625 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7626 is specified on the command-line, ensuring that the value of @code{I}
7627 referenced in the second line is whatever value @code{g77} uses
7628 to designate statement label @samp{10}, so the value may be
7629 copied into the @samp{ISTATE} array, later retrieved into a
7630 variable of the appropriate type (@samp{J}), and used as the target of
7631 an assigned-@code{GOTO} statement.
7633 @emph{Note:} To avoid subtle program bugs,
7634 when @samp{-fugly-assign} is specified,
7635 @code{g77} requires the type of variables
7636 specified in assigned-label contexts
7637 @emph{must} be the same type returned by @code{%LOC()}.
7638 On many systems, this type is effectively the same
7639 as @code{INTEGER(KIND=1)}, while, on others, it is
7640 effectively the same as @code{INTEGER(KIND=2)}.
7642 Do @emph{not} depend on @code{g77} actually writing valid pointers
7643 to these variables, however.
7644 While @code{g77} currently chooses that implementation, it might
7645 be changed in the future.
7647 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7648 for implementation details on assigned-statement labels.
7651 @chapter The GNU Fortran Compiler
7653 The GNU Fortran compiler, @code{g77}, supports programs written
7654 in the GNU Fortran language and in some other dialects of Fortran.
7656 Some aspects of how @code{g77} works are universal regardless
7657 of dialect, and yet are not properly part of the GNU Fortran
7659 These are described below.
7661 @emph{Note: This portion of the documentation definitely needs a lot
7667 * Compiler Constants::
7668 * Compiler Intrinsics::
7671 @node Compiler Limits
7672 @section Compiler Limits
7673 @cindex limits, compiler
7674 @cindex compiler limits
7676 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7677 on lengths of identifiers, number of continuation lines, number of external
7678 symbols in a program, and so on.
7680 @cindex options, -Nl
7682 @cindex options, -Nx
7684 For example, some other Fortran compiler have an option
7685 (such as @samp{-Nl@var{x}}) to increase the limit on the
7686 number of continuation lines.
7687 Also, some Fortran compilation systems have an option
7688 (such as @samp{-Nx@var{x}}) to increase the limit on the
7689 number of external symbols.
7691 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7692 no equivalent options, since they do not impose arbitrary
7693 limits in these areas.
7695 @cindex rank, maximum
7696 @cindex maximum rank
7697 @cindex number of dimensions, maximum
7698 @cindex maximum number of dimensions
7699 @code{g77} does currently limit the number of dimensions in an array
7700 to the same degree as do the Fortran standards---seven (7).
7701 This restriction might well be lifted in a future version.
7703 @node Compiler Types
7704 @section Compiler Types
7705 @cindex types, of data
7708 Fortran implementations have a fair amount of freedom given them by the
7709 standard as far as how much storage space is used and how much precision
7710 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7711 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7712 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7713 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7714 the interpretation of @var{n} varies across compilers and target architectures.
7716 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7717 and @code{REAL(KIND=1)}
7718 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7719 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7720 Further, it requires that @code{COMPLEX(KIND=1)}
7721 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7722 storage-associated (such as via @code{EQUIVALENCE})
7723 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7724 corresponds to the real element and @samp{R(2)} to the imaginary
7725 element of the @code{COMPLEX(KIND=1)} variable.
7727 (Few requirements as to precision or ranges of any of these are
7728 placed on the implementation, nor is the relationship of storage sizes of
7729 these types to the @code{CHARACTER} type specified, by the standard.)
7731 @code{g77} follows the above requirements, warning when compiling
7732 a program requires placement of items in memory that contradict the
7733 requirements of the target architecture.
7734 (For example, a program can require placement of a @code{REAL(KIND=2)}
7735 on a boundary that is not an even multiple of its size, but still an
7736 even multiple of the size of a @code{REAL(KIND=1)} variable.
7737 On some target architectures, using the canonical
7738 mapping of Fortran types to underlying architectural types, such
7739 placement is prohibited by the machine definition or
7740 the Application Binary Interface (ABI) in force for
7741 the configuration defined for building @code{gcc} and @code{g77}.
7742 @code{g77} warns about such
7743 situations when it encounters them.)
7745 @code{g77} follows consistent rules for configuring the mapping between Fortran
7746 types, including the @samp{*@var{n}} notation, and the underlying architectural
7747 types as accessed by a similarly-configured applicable version of the
7748 @code{gcc} compiler.
7749 These rules offer a widely portable, consistent Fortran/C
7750 environment, although they might well conflict with the expectations of
7751 users of Fortran compilers designed and written for particular
7754 These rules are based on the configuration that is in force for the
7755 version of @code{gcc} built in the same release as @code{g77} (and
7756 which was therefore used to build both the @code{g77} compiler
7757 components and the @code{libg2c} run-time library):
7760 @cindex REAL(KIND=1) type
7761 @cindex types, REAL(KIND=1)
7763 Same as @code{float} type.
7765 @cindex REAL(KIND=2) type
7766 @cindex types, REAL(KIND=2)
7768 Same as whatever floating-point type that is twice the size
7769 of a @code{float}---usually, this is a @code{double}.
7771 @cindex INTEGER(KIND=1) type
7772 @cindex types, INTEGER(KIND=1)
7773 @item INTEGER(KIND=1)
7774 Same as an integral type that is occupies the same amount
7775 of memory storage as @code{float}---usually, this is either
7776 an @code{int} or a @code{long int}.
7778 @cindex LOGICAL(KIND=1) type
7779 @cindex types, LOGICAL(KIND=1)
7780 @item LOGICAL(KIND=1)
7781 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7783 @cindex INTEGER(KIND=2) type
7784 @cindex types, INTEGER(KIND=2)
7785 @item INTEGER(KIND=2)
7786 Twice the size, and usually nearly twice the range,
7787 as @code{INTEGER(KIND=1)}---usually, this is either
7788 a @code{long int} or a @code{long long int}.
7790 @cindex LOGICAL(KIND=2) type
7791 @cindex types, LOGICAL(KIND=2)
7792 @item LOGICAL(KIND=2)
7793 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7795 @cindex INTEGER(KIND=3) type
7796 @cindex types, INTEGER(KIND=3)
7797 @item INTEGER(KIND=3)
7798 Same @code{gcc} type as signed @code{char}.
7800 @cindex LOGICAL(KIND=3) type
7801 @cindex types, LOGICAL(KIND=3)
7802 @item LOGICAL(KIND=3)
7803 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7805 @cindex INTEGER(KIND=6) type
7806 @cindex types, INTEGER(KIND=6)
7807 @item INTEGER(KIND=6)
7808 Twice the size, and usually nearly twice the range,
7809 as @code{INTEGER(KIND=3)}---usually, this is
7812 @cindex LOGICAL(KIND=6) type
7813 @cindex types, LOGICAL(KIND=6)
7814 @item LOGICAL(KIND=6)
7815 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7817 @cindex COMPLEX(KIND=1) type
7818 @cindex types, COMPLEX(KIND=1)
7819 @item COMPLEX(KIND=1)
7820 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7821 one for the imaginary part).
7823 @cindex COMPLEX(KIND=2) type
7824 @cindex types, COMPLEX(KIND=2)
7825 @item COMPLEX(KIND=2)
7826 Two @code{REAL(KIND=2)} scalars.
7828 @cindex *@var{n} notation
7829 @item @var{numeric-type}*@var{n}
7830 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7831 Same as whatever @code{gcc} type occupies @var{n} times the storage
7832 space of a @code{gcc} @code{char} item.
7834 @cindex DOUBLE PRECISION type
7835 @cindex types, DOUBLE PRECISION
7836 @item DOUBLE PRECISION
7837 Same as @code{REAL(KIND=2)}.
7839 @cindex DOUBLE COMPLEX type
7840 @cindex types, DOUBLE COMPLEX
7841 @item DOUBLE COMPLEX
7842 Same as @code{COMPLEX(KIND=2)}.
7845 Note that the above are proposed correspondences and might change
7846 in future versions of @code{g77}---avoid writing code depending
7849 Other types supported by @code{g77}
7850 are derived from gcc types such as @code{char}, @code{short},
7851 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7853 That is, whatever types @code{gcc} already supports, @code{g77} supports
7854 now or probably will support in a future version.
7855 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7856 apply to these types,
7857 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7858 assigned in a way that encourages clarity, consistency, and portability.
7860 @node Compiler Constants
7861 @section Compiler Constants
7863 @cindex types, constants
7865 @code{g77} strictly assigns types to @emph{all} constants not
7866 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7868 Many other Fortran compilers attempt to assign types to typed constants
7869 based on their context.
7870 This results in hard-to-find bugs, nonportable
7871 code, and is not in the spirit (though it strictly follows the letter)
7872 of the 77 and 90 standards.
7874 @code{g77} might offer, in a future release, explicit constructs by
7875 which a wider variety of typeless constants may be specified, and/or
7876 user-requested warnings indicating places where @code{g77} might differ
7877 from how other compilers assign types to constants.
7879 @xref{Context-Sensitive Constants}, for more information on this issue.
7881 @node Compiler Intrinsics
7882 @section Compiler Intrinsics
7884 @code{g77} offers an ever-widening set of intrinsics.
7885 Currently these all are procedures (functions and subroutines).
7887 Some of these intrinsics are unimplemented, but their names reserved
7888 to reduce future problems with existing code as they are implemented.
7889 Others are implemented as part of the GNU Fortran language, while
7890 yet others are provided for compatibility with other dialects of
7891 Fortran but are not part of the GNU Fortran language.
7893 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7894 a facility that is simply an extension of the intrinsic groups provided
7895 by the GNU Fortran language.
7898 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7899 * Other Intrinsics:: Intrinsics other than those in the GNU
7903 @node Intrinsic Groups
7904 @subsection Intrinsic Groups
7905 @cindex groups of intrinsics
7906 @cindex intrinsics, groups
7908 A given specific intrinsic belongs in one or more groups.
7909 Each group is deleted, disabled, hidden, or enabled
7910 by default or a command-line option.
7911 The meaning of each term follows.
7914 @cindex deleted intrinsics
7915 @cindex intrinsics, deleted
7917 No intrinsics are recognized as belonging to that group.
7919 @cindex disabled intrinsics
7920 @cindex intrinsics, disabled
7922 Intrinsics are recognized as belonging to the group, but
7923 references to them (other than via the @code{INTRINSIC} statement)
7924 are disallowed through that group.
7926 @cindex hidden intrinsics
7927 @cindex intrinsics, hidden
7929 Intrinsics in that group are recognized and enabled (if implemented)
7930 @emph{only} if the first mention of the actual name of an intrinsic
7931 in a program unit is in an @code{INTRINSIC} statement.
7933 @cindex enabled intrinsics
7934 @cindex intrinsics, enabled
7936 Intrinsics in that group are recognized and enabled (if implemented).
7939 The distinction between deleting and disabling a group is illustrated
7940 by the following example.
7941 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7942 If group @samp{FGR} is deleted, the following program unit will
7943 successfully compile, because @samp{FOO()} will be seen as a
7944 reference to an external function named @samp{FOO}:
7952 If group @samp{FGR} is disabled, compiling the above program will produce
7953 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7954 or, if properly invoked, it is not enabled.
7955 To change the above program so it references an external function @samp{FOO}
7956 instead of the disabled @samp{FOO} intrinsic,
7957 add the following line to the top:
7964 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7965 that group do not exist at all, whereas disabling it tells @code{g77} to
7966 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7968 Hiding a group is like enabling it, but the intrinsic must be first
7969 named in an @code{INTRINSIC} statement to be considered a reference to the
7970 intrinsic rather than to an external procedure.
7971 This might be the ``safest'' way to treat a new group of intrinsics
7973 code, because it allows the old code to be generally written as if
7974 those new intrinsics never existed, but to be changed to use them
7975 by inserting @code{INTRINSIC} statements in the appropriate places.
7976 However, it should be the goal of development to use @code{EXTERNAL}
7977 for all names of external procedures that might be intrinsic names.
7979 If an intrinsic is in more than one group, it is enabled if any of its
7980 containing groups are enabled; if not so enabled, it is hidden if
7981 any of its containing groups are hidden; if not so hidden, it is disabled
7982 if any of its containing groups are disabled; if not so disabled, it is
7984 This extra complication is necessary because some intrinsics,
7985 such as @code{IBITS}, belong to more than one group, and hence should be
7986 enabled if any of the groups to which they belong are enabled, and so
7991 @cindex intrinsics, groups of
7992 @cindex groups of intrinsics
7994 @cindex @code{badu77} intrinsics group
7996 UNIX intrinsics having inappropriate forms (usually functions that
7997 have intended side effects).
7999 @cindex @code{gnu} intrinsics group
8001 Intrinsics the GNU Fortran language supports that are extensions to
8002 the Fortran standards (77 and 90).
8004 @cindex @code{f2c} intrinsics group
8006 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
8008 @cindex @code{f90} intrinsics group
8010 Fortran 90 intrinsics.
8012 @cindex @code{mil} intrinsics group
8014 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
8016 @cindex @code{mil} intrinsics group
8018 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
8020 @cindex @code{mil} intrinsics group
8022 VAX/VMS FORTRAN (current as of v4) intrinsics.
8025 @node Other Intrinsics
8026 @subsection Other Intrinsics
8027 @cindex intrinsics, others
8028 @cindex other intrinsics
8030 @code{g77} supports intrinsics other than those in the GNU Fortran
8032 This set of intrinsics is described below.
8035 (Note that the empty lines appearing in the menu below
8036 are not intentional---they result from a bug in the
8037 @code{makeinfo} program.)
8040 @c The actual documentation for intrinsics comes from
8041 @c intdoc.texi, which in turn is automatically generated
8042 @c from the internal g77 tables in intrin.def _and_ the
8043 @c largely hand-written text in intdoc.h. So, if you want
8044 @c to change or add to existing documentation on intrinsics,
8045 @c you probably want to edit intdoc.h.
8057 @include intdoc.texi
8059 @node Other Compilers
8060 @chapter Other Compilers
8062 An individual Fortran source file can be compiled to
8063 an object (@file{*.o}) file instead of to the final
8065 This allows several portions of a program to be compiled
8066 at different times and linked together whenever a new
8067 version of the program is needed.
8068 However, it introduces the issue of @dfn{object compatibility}
8069 across the various object files (and libraries, or @file{*.a}
8070 files) that are linked together to produce any particular
8073 Object compatibility is an issue when combining, in one
8074 program, Fortran code compiled by more than one compiler
8075 (or more than one configuration of a compiler).
8077 disagree on how to transform the names of procedures, there
8078 will normally be errors when linking such programs.
8079 Worse, if the compilers agree on naming, but disagree on issues
8080 like how to pass parameters, return arguments, and lay out
8081 @code{COMMON} areas, the earliest detected errors might be the
8082 incorrect results produced by the program (and that assumes
8083 these errors are detected, which is not always the case).
8085 Normally, @code{g77} generates code that is
8086 object-compatible with code generated by a version of
8087 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
8088 to be generally compatible with @code{g77} as built by @code{gcc}.
8089 (Normally, @code{f2c} will, by default, conform to the appropriate
8090 configuration, but it is possible that older or perhaps even newer
8091 versions of @code{f2c}, or versions having certain configuration changes
8092 to @code{f2c} internals, will produce object files that are
8093 incompatible with @code{g77}.)
8095 For example, a Fortran string subroutine
8096 argument will become two arguments on the C side: a @code{char *}
8097 and an @code{int} length.
8099 Much of this compatibility results from the fact that
8100 @code{g77} uses the same run-time library,
8101 @code{libf2c}, used by @code{f2c},
8102 though @code{g77} gives its version the name @code{libg2c}
8103 so as to avoid conflicts when linking,
8104 installing them in the same directories,
8107 Other compilers might or might not generate code that
8108 is object-compatible with @code{libg2c} and current @code{g77},
8109 and some might offer such compatibility only when explicitly
8110 selected via a command-line option to the compiler.
8112 @emph{Note: This portion of the documentation definitely needs a lot
8116 * Dropping f2c Compatibility:: When speed is more important.
8117 * Compilers Other Than f2c:: Interoperation with code from other compilers.
8120 @node Dropping f2c Compatibility
8121 @section Dropping @code{f2c} Compatibility
8123 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
8124 some cases, faster code, by not needing to allow to the possibility
8125 of linking with code compiled by @code{f2c}.
8127 For example, this affects how @code{REAL(KIND=1)},
8128 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
8129 With @samp{-fno-f2c}, they are
8130 compiled as returning the appropriate @code{gcc} type
8131 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
8132 in many configurations).
8134 With @samp{-ff2c} in force, they
8135 are compiled differently (with perhaps slower run-time performance)
8136 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
8137 C as an intermediate language---@code{REAL(KIND=1)} functions
8138 return C's @code{double} type, while @code{COMPLEX} functions return
8139 @code{void} and use an extra argument pointing to a place for the functions to
8140 return their values.
8142 It is possible that, in some cases, leaving @samp{-ff2c} in force
8143 might produce faster code than using @samp{-fno-f2c}.
8144 Feel free to experiment, but remember to experiment with changing the way
8145 @emph{entire programs and their Fortran libraries are compiled} at
8146 a time, since this sort of experimentation affects the interface
8147 of code generated for a Fortran source file---that is, it affects
8148 object compatibility.
8150 Note that @code{f2c} compatibility is a fairly static target to achieve,
8151 though not necessarily perfectly so, since, like @code{g77}, it is
8152 still being improved.
8153 However, specifying @samp{-fno-f2c} causes @code{g77}
8154 to generate code that will probably be incompatible with code
8155 generated by future versions of @code{g77} when the same option
8157 You should make sure you are always able to recompile complete
8158 programs from source code when upgrading to new versions of @code{g77}
8159 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8161 Therefore, if you are using @code{g77} to compile libraries and other
8162 object files for possible future use and you don't want to require
8163 recompilation for future use with subsequent versions of @code{g77},
8164 you might want to stick with @code{f2c} compatibility for now, and
8165 carefully watch for any announcements about changes to the
8166 @code{f2c}/@code{libf2c} interface that might affect existing programs
8167 (thus requiring recompilation).
8169 It is probable that a future version of @code{g77} will not,
8170 by default, generate object files compatible with @code{f2c},
8171 and that version probably would no longer use @code{libf2c}.
8172 If you expect to depend on this compatibility in the
8173 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8174 all of the applicable code.
8175 This should cause future versions of @code{g77} either to produce
8176 compatible code (at the expense of the availability of some features and
8177 performance), or at the very least, to produce diagnostics.
8179 (The library @code{g77} produces will no longer be named @file{libg2c}
8180 when it is no longer generally compatible with @file{libf2c}.
8181 It will likely be referred to, and, if installed as a distinct
8182 library, named @code{libg77}, or some other as-yet-unused name.)
8184 @node Compilers Other Than f2c
8185 @section Compilers Other Than @code{f2c}
8187 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8188 code compiled by @code{g77} is not expected to work
8189 well with code compiled by the native compiler.
8190 (This is true for @code{f2c}-compiled objects as well.)
8191 Libraries compiled with the native compiler probably will have
8192 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8194 Reasons for such incompatibilities include:
8198 There might be differences in the way names of Fortran procedures
8199 are translated for use in the system's object-file format.
8200 For example, the statement @samp{CALL FOO} might be compiled
8201 by @code{g77} to call a procedure the linker @code{ld} sees
8202 given the name @samp{_foo_}, while the apparently corresponding
8203 statement @samp{SUBROUTINE FOO} might be compiled by the
8204 native compiler to define the linker-visible name @samp{_foo},
8205 or @samp{_FOO_}, and so on.
8208 There might be subtle type mismatches which cause subroutine arguments
8209 and function return values to get corrupted.
8211 This is why simply getting @code{g77} to
8212 transform procedure names the same way a native
8213 compiler does is not usually a good idea---unless
8214 some effort has been made to ensure that, aside
8215 from the way the two compilers transform procedure
8216 names, everything else about the way they generate
8217 code for procedure interfaces is identical.
8221 use libraries of private I/O routines which will not be available
8222 at link time unless you have the native compiler---and you would
8223 have to explicitly ask for them.
8225 For example, on the Sun you
8226 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8230 @node Other Languages
8231 @chapter Other Languages
8233 @emph{Note: This portion of the documentation definitely needs a lot
8237 * Interoperating with C and C++::
8240 @node Interoperating with C and C++
8241 @section Tools and advice for interoperating with C and C++
8243 @cindex C, linking with
8244 @cindex C++, linking with
8245 @cindex linking with C
8246 The following discussion assumes that you are running @code{g77} in @code{f2c}
8247 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8249 advice about quick and simple techniques for linking Fortran and C (or
8250 C++), the most common requirement.
8251 For the full story consult the
8252 description of code generation.
8253 @xref{Debugging and Interfacing}.
8255 When linking Fortran and C, it's usually best to use @code{g77} to do
8256 the linking so that the correct libraries are included (including the
8258 If you're linking with C++ you will want to add
8259 @samp{-lstdc++}, @samp{-lg++} or whatever.
8260 If you need to use another
8261 driver program (or @code{ld} directly),
8262 you can find out what linkage
8263 options @code{g77} passes by running @samp{g77 -v}.
8266 * C Interfacing Tools::
8267 * C Access to Type Information::
8268 * f2c Skeletons and Prototypes::
8269 * C++ Considerations::
8273 @node C Interfacing Tools
8274 @subsection C Interfacing Tools
8278 Even if you don't actually use it as a compiler, @samp{f2c} from
8279 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8280 interfacing (linking) Fortran and C@.
8281 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8283 To use @code{f2c} for this purpose you only need retrieve and
8284 build the @file{src} directory from the distribution, consult the
8285 @file{README} instructions there for machine-specifics, and install the
8286 @code{f2c} program on your path.
8288 Something else that might be useful is @samp{cfortran.h} from
8289 @uref{ftp://zebra/desy.de/cfortran}.
8290 This is a fairly general tool which
8291 can be used to generate interfaces for calling in both directions
8292 between Fortran and C@.
8293 It can be used in @code{f2c} mode with
8294 @code{g77}---consult its documentation for details.
8296 @node C Access to Type Information
8297 @subsection Accessing Type Information in C
8299 @cindex types, Fortran/C
8300 Generally, C code written to link with
8301 @code{g77} code---calling and/or being
8302 called from Fortran---should @samp{#include <g2c.h>} to define the C
8303 versions of the Fortran types.
8304 Don't assume Fortran @code{INTEGER} types
8305 correspond to C @samp{int}s, for instance; instead, declare them as
8306 @code{integer}, a type defined by @file{g2c.h}.
8307 @file{g2c.h} is installed where @code{gcc} will find it by
8308 default, assuming you use a copy of @code{gcc} compatible with
8309 @code{g77}, probably built at the same time as @code{g77}.
8311 @node f2c Skeletons and Prototypes
8312 @subsection Generating Skeletons and Prototypes with @code{f2c}
8315 @cindex -fno-second-underscore
8316 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8317 interface with an existing library---is to write a file (named, for
8318 example, @file{fred.f}) of dummy Fortran
8319 skeletons comprising just the declaration of the routine(s) and dummy
8320 arguments plus @samp{END} statements.
8321 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8322 into which you can edit
8323 useful code, confident the calling sequence is correct, at least.
8324 (There are some errors otherwise commonly made in generating C
8325 interfaces with @code{f2c} conventions,
8326 such as not using @code{doublereal}
8327 as the return type of a @code{REAL} @code{FUNCTION}.)
8330 @code{f2c} also can help with calling Fortran from C, using its
8331 @samp{-P} option to generate C prototypes appropriate for calling the
8332 Fortran.@footnote{The files generated like this can also be used for
8333 inter-unit consistency checking of dummy and actual arguments, although
8334 the @samp{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8335 or @uref{ftp://ftp.dsm.fordham.edu} is
8336 probably better for this purpose.}
8337 If the Fortran code containing any
8338 routines to be called from C is in file @file{joe.f}, use the command
8339 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8340 prototype information.
8341 @code{#include} this in the C which has to call
8342 the Fortran routines to make sure you get it right.
8344 @xref{Arrays,,Arrays (DIMENSION}, for information on the differences
8345 between the way Fortran (including compilers like @code{g77}) and
8348 @node C++ Considerations
8349 @subsection C++ Considerations
8352 @code{f2c} can be used to generate suitable code for compilation with a
8353 C++ system using the @samp{-C++} option.
8354 The important thing about linking @code{g77}-compiled
8355 code with C++ is that the prototypes for the @code{g77}
8356 routines must specify C linkage to avoid name mangling.
8357 So, use an @samp{extern "C"} declaration.
8358 @code{f2c}'s @samp{-C++} option will take care
8359 of this when generating skeletons or prototype files as above, and also
8360 avoid clashes with C++ reserved words in addition to those in C@.
8363 @subsection Startup Code
8365 @cindex startup code
8366 @cindex runtime initialization
8367 @cindex initialization, runtime
8368 Unlike with some runtime systems,
8369 it shouldn't be necessary
8370 (unless there are bugs)
8371 to use a Fortran main program unit to ensure the
8372 runtime---specifically the I/O system---is initialized.
8374 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8375 either the @code{main} routine from the @file{libg2c} library must be used,
8376 or the @code{f_setarg} routine
8377 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8378 must be called with the appropriate @code{argc} and @code{argv} arguments
8379 prior to the program calling @code{GETARG} or @code{IARGC}.
8381 To provide more flexibility for mixed-language programming
8382 involving @code{g77} while allowing for shared libraries,
8383 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8384 @code{g77}'s @code{main} routine in @code{libg2c}
8385 does the following, in order:
8389 Calls @code{f_setarg}
8390 with the incoming @code{argc} and @code{argv} arguments,
8391 in the same order as for @code{main} itself.
8393 This sets up the command-line environment
8394 for @code{GETARG} and @code{IARGC}.
8397 Calls @code{f_setsig} (with no arguments).
8399 This sets up the signaling and exception environment.
8402 Calls @code{f_init} (with no arguments).
8404 This initializes the I/O environment,
8405 though that should not be necessary,
8406 as all I/O functions in @code{libf2c}
8407 are believed to call @code{f_init} automatically,
8410 (A future version of @code{g77} might skip this explicit step,
8411 to speed up normal exit of a program.)
8414 Arranges for @code{f_exit} to be called (with no arguments)
8415 when the program exits.
8417 This ensures that the I/O environment is properly shut down
8418 before the program exits normally.
8419 Otherwise, output buffers might not be fully flushed,
8420 scratch files might not be deleted, and so on.
8422 The simple way @code{main} does this is
8423 to call @code{f_exit} itself after calling
8424 @code{MAIN__} (in the next step).
8426 However, this does not catch the cases where the program
8427 might call @code{exit} directly,
8428 instead of using the @code{EXIT} intrinsic
8429 (implemented as @code{exit_} in @code{libf2c}).
8431 So, @code{main} attempts to use
8432 the operating environment's @code{onexit} or @code{atexit}
8433 facility, if available,
8434 to cause @code{f_exit} to be called automatically
8435 upon any invocation of @code{exit}.
8438 Calls @code{MAIN__} (with no arguments).
8440 This starts executing the Fortran main program unit for
8442 (Both @code{g77} and @code{f2c} currently compile a main
8443 program unit so that its global name is @code{MAIN__}.)
8446 If no @code{onexit} or @code{atexit} is provided by the system,
8447 calls @code{f_exit}.
8450 Calls @code{exit} with a zero argument,
8451 to signal a successful program termination.
8454 Returns a zero value to the caller,
8455 to signal a successful program termination,
8456 in case @code{exit} doesn't exit on the system.
8459 All of the above names are C @code{extern} names,
8462 When using the @code{main} procedure provided by @code{g77}
8463 without a Fortran main program unit,
8464 you need to provide @code{MAIN__}
8465 as the entry point for your C code.
8466 (Make sure you link the object file that defines that
8467 entry point with the rest of your program.)
8469 To provide your own @code{main} procedure
8470 in place of @code{g77}'s,
8471 make sure you specify the object file defining that procedure
8472 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8473 Since the @samp{-lg2c} option is implicitly provided,
8474 this is usually straightforward.
8475 (Use the @samp{--verbose} option to see how and where
8476 @code{g77} implicitly adds @samp{-lg2c} in a command line
8477 that will link the program.
8478 Feel free to specify @samp{-lg2c} explicitly,
8481 However, when providing your own @code{main},
8482 make sure you perform the appropriate tasks in the
8484 For example, if your @code{main} does not call @code{f_setarg},
8485 make sure the rest of your application does not call
8486 @code{GETARG} or @code{IARGC}.
8488 And, if your @code{main} fails to ensure that @code{f_exit}
8489 is called upon program exit,
8490 some files might end up incompletely written,
8491 some scratch files might be left lying around,
8492 and some existing files being written might be left
8493 with old data not properly truncated at the end.
8495 Note that, generally, the @code{g77} operating environment
8496 does not depend on a procedure named @code{MAIN__} actually
8497 being called prior to any other @code{g77}-compiled code.
8498 That is, @code{MAIN__} does not, itself,
8499 set up any important operating-environment characteristics
8500 upon which other code might depend.
8501 This might change in future versions of @code{g77},
8502 with appropriate notification in the release notes.
8504 For more information, consult the source code for the above routines.
8505 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8506 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8508 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8509 uses to open-code (inline) references to @code{IARGC}.
8511 @include g77install.texi
8513 @node Debugging and Interfacing
8514 @chapter Debugging and Interfacing
8517 @cindex calling C routines
8518 @cindex C routines calling Fortran
8519 @cindex f2c compatibility
8521 GNU Fortran currently generates code that is object-compatible with
8522 the @code{f2c} converter.
8523 Also, it avoids limitations in the current GBE, such as the
8524 inability to generate a procedure with
8525 multiple entry points, by generating code that is structured
8526 differently (in terms of procedure names, scopes, arguments, and
8527 so on) than might be expected.
8529 As a result, writing code in other languages that calls on, is
8530 called by, or shares in-memory data with @code{g77}-compiled code generally
8531 requires some understanding of the way @code{g77} compiles code for
8534 Similarly, using a debugger to debug @code{g77}-compiled
8535 code, even if that debugger supports native Fortran debugging, generally
8536 requires this sort of information.
8538 This section describes some of the basic information on how
8539 @code{g77} compiles code for constructs involving interfaces to other
8540 languages and to debuggers.
8542 @emph{Caution:} Much or all of this information pertains to only the current
8543 release of @code{g77}, sometimes even to using certain compiler options
8544 with @code{g77} (such as @samp{-fno-f2c}).
8545 Do not write code that depends on this
8546 information without clearly marking said code as nonportable and
8547 subject to review for every new release of @code{g77}.
8549 is provided primarily to make debugging of code generated by this
8550 particular release of @code{g77} easier for the user, and partly to make
8551 writing (generally nonportable) interface code easier.
8553 activities require tracking changes in new version of @code{g77} as they
8554 are installed, because new versions can change the behaviors
8555 described in this section.
8558 * Main Program Unit:: How @code{g77} compiles a main program unit.
8559 * Procedures:: How @code{g77} constructs parameter lists
8561 * Functions:: Functions returning floating-point or character data.
8562 * Names:: Naming of user-defined variables, procedures, etc.
8563 * Common Blocks:: Accessing common variables while debugging.
8564 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8565 * Complex Variables:: How @code{g77} performs complex arithmetic.
8566 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8567 * Adjustable Arrays:: Special consideration for adjustable arrays.
8568 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8569 * Alternate Returns:: How @code{g77} handles alternate returns.
8570 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8571 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8574 @node Main Program Unit
8575 @section Main Program Unit (PROGRAM)
8576 @cindex PROGRAM statement
8577 @cindex statements, PROGRAM
8579 When @code{g77} compiles a main program unit, it gives it the public
8580 procedure name @samp{MAIN__}.
8581 The @code{libg2c} library has the actual @code{main()} procedure
8582 as is typical of C-based environments, and
8583 it is this procedure that performs some initial start-up
8584 activity and then calls @samp{MAIN__}.
8586 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8587 include a main program unit written in Fortran in your program---it
8588 can be written in C or some other language.
8589 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8590 includes a bug fix for @code{libg2c} that solved a problem with using the
8591 @code{OPEN} statement as the first Fortran I/O activity in a program
8592 without a Fortran main program unit.
8594 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8595 your main program unit---that is, if you intend to compile a @code{main()}
8596 procedure using some other language---you should carefully
8597 examine the code for @code{main()} in @code{libg2c}, found in the source
8598 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8599 might need to be done by your @code{main()} in order to provide the
8600 Fortran environment your Fortran code is expecting.
8602 @cindex IARGC() intrinsic
8603 @cindex intrinsics, IARGC()
8604 @cindex GETARG() intrinsic
8605 @cindex intrinsics, GETARG()
8606 For example, @code{libg2c}'s @code{main()} sets up the information used by
8607 the @code{IARGC} and @code{GETARG} intrinsics.
8608 Bypassing @code{libg2c}'s @code{main()}
8609 without providing a substitute for this activity would mean
8610 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8614 @cindex main program unit, debugging
8618 When debugging, one implication of the fact that @code{main()}, which
8619 is the place where the debugged program ``starts'' from the
8620 debugger's point of view, is in @code{libg2c} is that you won't be
8621 starting your Fortran program at a point you recognize as your
8624 The standard way to get around this problem is to set a break
8625 point (a one-time, or temporary, break point will do) at
8626 the entrance to @samp{MAIN__}, and then run the program.
8627 A convenient way to do so is to add the @code{gdb} command
8634 to the file @file{.gdbinit} in the directory in which you're debugging
8637 After doing this, the debugger will see the current execution
8638 point of the program as at the beginning of the main program
8639 unit of your program.
8641 Of course, if you really want to set a break point at some
8642 other place in your program and just start the program
8643 running, without first breaking at @samp{MAIN__},
8644 that should work fine.
8647 @section Procedures (SUBROUTINE and FUNCTION)
8649 @cindex SUBROUTINE statement
8650 @cindex statements, SUBROUTINE
8651 @cindex FUNCTION statement
8652 @cindex statements, FUNCTION
8653 @cindex signature of procedures
8655 Currently, @code{g77} passes arguments via reference---specifically,
8656 by passing a pointer to the location in memory of a variable, array,
8657 array element, a temporary location that holds the result of evaluating an
8658 expression, or a temporary or permanent location that holds the value
8661 Procedures that accept @code{CHARACTER} arguments are implemented by
8662 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8664 The first argument occupies the expected position in the
8665 argument list and has the user-specified name.
8667 is a pointer to an array of characters, passed by the caller.
8669 The second argument is appended to the end of the user-specified
8670 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8671 is the user-specified name.
8672 This argument is of the C type @code{ftnlen}
8673 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8674 is the number of characters the caller has allocated in the
8675 array pointed to by the first argument.
8677 A procedure will ignore the length argument if @samp{X} is not declared
8678 @code{CHARACTER*(*)}, because for other declarations, it knows the
8680 Not all callers necessarily ``know'' this, however, which
8681 is why they all pass the extra argument.
8683 The contents of the @code{CHARACTER} argument are specified by the
8684 address passed in the first argument (named after it).
8685 The procedure can read or write these contents as appropriate.
8687 When more than one @code{CHARACTER} argument is present in the argument
8688 list, the length arguments are appended in the order
8689 the original arguments appear.
8690 So @samp{CALL FOO('HI','THERE')} is implemented in
8691 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8692 does not provide the trailing null bytes on the constant
8693 strings (@code{f2c} does provide them, but they are unnecessary in
8694 a Fortran environment, and you should not expect them to be
8697 Note that the above information applies to @code{CHARACTER} variables and
8698 arrays @strong{only}.
8699 It does @strong{not} apply to external @code{CHARACTER}
8700 functions or to intrinsic @code{CHARACTER} functions.
8701 That is, no second length argument is passed to @samp{FOO} in this case:
8710 Nor does @samp{FOO} expect such an argument in this case:
8718 Because of this implementation detail, if a program has a bug
8719 such that there is disagreement as to whether an argument is
8720 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8721 symptoms might appear.
8724 @section Functions (FUNCTION and RETURN)
8726 @cindex FUNCTION statement
8727 @cindex statements, FUNCTION
8728 @cindex RETURN statement
8729 @cindex statements, RETURN
8730 @cindex return type of functions
8732 @code{g77} handles in a special way functions that return the following
8744 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8745 returning @code{void})
8746 with two arguments prepended: @samp{__g77_result}, which the caller passes
8747 as a pointer to a @code{char} array expected to hold the return value,
8748 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8749 specifying the length of the return value as declared in the calling
8751 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8752 to determine the size of the array that @samp{__g77_result} points to;
8753 otherwise, it ignores that argument.
8755 For @code{COMPLEX}, when @samp{-ff2c} is in
8756 force, @code{g77} implements
8757 a subroutine with one argument prepended: @samp{__g77_result}, which the
8758 caller passes as a pointer to a variable of the type of the function.
8759 The called function writes the return value into this variable instead
8760 of returning it as a function value.
8761 When @samp{-fno-f2c} is in force,
8762 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8763 @samp{__complex__ float} or @samp{__complex__ double} function
8764 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8765 returning the result of the function in the same way as @code{gcc} would.
8767 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8768 a function that actually returns @code{REAL(KIND=2)} (typically
8769 C's @code{double} type).
8770 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8771 functions return @code{float}.
8775 @cindex symbol names
8776 @cindex transformation of symbol names
8778 Fortran permits each implementation to decide how to represent
8779 names as far as how they're seen in other contexts, such as debuggers
8780 and when interfacing to other languages, and especially as far
8781 as how casing is handled.
8783 External names---names of entities that are public, or ``accessible'',
8784 to all modules in a program---normally have an underscore (@samp{_})
8785 appended by @code{g77},
8786 to generate code that is compatible with @code{f2c}.
8787 External names include names of Fortran things like common blocks,
8788 external procedures (subroutines and functions, but not including
8789 statement functions, which are internal procedures), and entry point
8792 However, use of the @samp{-fno-underscoring} option
8793 disables this kind of transformation of external names (though inhibiting
8794 the transformation certainly improves the chances of colliding with
8795 incompatible externals written in other languages---but that
8796 might be intentional.
8798 @cindex -fno-underscoring option
8799 @cindex options, -fno-underscoring
8800 @cindex -fno-second-underscore option
8801 @cindex options, -fno-underscoring
8802 When @samp{-funderscoring} is in force, any name (external or local)
8803 that already has at least one underscore in it is
8804 implemented by @code{g77} by appending two underscores.
8805 (This second underscore can be disabled via the
8806 @samp{-fno-second-underscore} option.)
8807 External names are changed this way for @code{f2c} compatibility.
8808 Local names are changed this way to avoid collisions with external names
8809 that are different in the source code---@code{f2c} does the same thing, but
8810 there's no compatibility issue there except for user expectations while
8821 Here, a user would, in the debugger, refer to this variable using the
8822 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8823 as described below).
8824 (We hope to improve @code{g77} in this regard in the future---don't
8825 write scripts depending on this behavior!
8826 Also, consider experimenting with the @samp{-fno-underscoring}
8827 option to try out debugging without having to massage names by
8830 @code{g77} provides a number of command-line options that allow the user
8831 to control how case mapping is handled for source files.
8832 The default is the traditional UNIX model for Fortran compilers---names
8833 are mapped to lower case.
8834 Other command-line options can be specified to map names to upper
8835 case, or to leave them exactly as written in the source file.
8844 Here, it is normally the case that the variable assigned will be named
8846 This would be the name to enter when using a debugger to
8847 access the variable.
8849 However, depending on the command-line options specified, the
8850 name implemented by @code{g77} might instead be @samp{FOO} or even
8851 @samp{Foo}, thus affecting how debugging is done.
8860 This would normally call a procedure that, if it were in a separate C program,
8861 be defined starting with the line:
8868 However, @code{g77} command-line options could be used to change the casing
8869 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8870 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8871 could be used to inhibit the appending of the underscore to the name.
8874 @section Common Blocks (COMMON)
8875 @cindex common blocks
8876 @cindex COMMON statement
8877 @cindex statements, COMMON
8879 @code{g77} names and lays out @code{COMMON} areas
8880 the same way @code{f2c} does,
8881 for compatibility with @code{f2c}.
8883 Currently, @code{g77} does not emit ``true'' debugging information for
8884 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8886 (As of Version 0.5.19, @code{g77} emits debugging information for such
8887 members in the form of a constant string specifying the base name of
8888 the aggregate area and the offset of the member in bytes from the start
8890 Use the @samp{-fdebug-kludge} option to enable this behavior.
8891 In @code{gdb}, use @samp{set language c} before printing the value
8892 of the member, then @samp{set language fortran} to restore the default
8893 language, since @code{gdb} doesn't provide a way to print a readable
8894 version of a character string in Fortran language mode.
8896 This kludge will be removed in a future version of @code{g77} that,
8897 in conjunction with a contemporary version of @code{gdb},
8898 properly supports Fortran-language debugging, including access
8899 to members of @code{COMMON} areas.)
8901 @xref{Code Gen Options,,Options for Code Generation Conventions},
8902 for information on the @samp{-fdebug-kludge} option.
8904 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8905 type is an array of the C @code{char} data type.
8907 So, when debugging, you must know the offset into a @code{COMMON} area
8908 for a particular item in that area, and you have to take into
8909 account the appropriate multiplier for the respective sizes
8910 of the types (as declared in your code) for the items preceding
8911 the item in question as compared to the size of the @code{char} type.
8913 For example, using default implicit typing, the statement
8916 COMMON I(15), R(20), T
8920 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8921 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8922 and @samp{T} at @samp{_BLNK__[140]}.
8923 (This is assuming that the target machine for
8924 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8927 @node Local Equivalence Areas
8928 @section Local Equivalence Areas (EQUIVALENCE)
8929 @cindex equivalence areas
8930 @cindex local equivalence areas
8931 @cindex EQUIVALENCE statement
8932 @cindex statements, EQUIVALENCE
8934 @code{g77} treats storage-associated areas involving a @code{COMMON}
8935 block as explained in the section on common blocks.
8937 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8938 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8939 listed in a @code{COMMON} statement.
8941 Currently, @code{g77} does not emit ``true'' debugging information for
8942 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8944 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8945 members in the form of a constant string specifying the base name of
8946 the aggregate area and the offset of the member in bytes from the start
8948 Use the @samp{-fdebug-kludge} option to enable this behavior.
8949 In @code{gdb}, use @samp{set language c} before printing the value
8950 of the member, then @samp{set language fortran} to restore the default
8951 language, since @code{gdb} doesn't provide a way to print a readable
8952 version of a character string in Fortran language mode.
8954 This kludge will be removed in a future version of @code{g77} that,
8955 in conjunction with a contemporary version of @code{gdb},
8956 properly supports Fortran-language debugging, including access
8957 to members of @code{EQUIVALENCE} areas.)
8959 @xref{Code Gen Options,,Options for Code Generation Conventions},
8960 for information on the @samp{-fdebug-kludge} option.
8962 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8963 type is an array of the C @code{char} data type.
8965 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8966 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8968 If more than one such item is placed at the beginning, @var{x} is
8969 the name that sorts to the top in an alphabetical sort of the list of
8972 When debugging, you must therefore access members of @code{EQUIVALENCE}
8973 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8974 array section with the appropriate offset.
8975 See the explanation of debugging @code{COMMON} blocks
8976 for info applicable to debugging local @code{EQUIVALENCE} areas.
8978 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8979 for @var{x} using a different method when more than one name was
8980 in the list of names of entities placed at the beginning of the
8982 Though the documentation specified that the first name listed in
8983 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8984 in fact chose the name using a method that was so complicated,
8985 it seemed easier to change it to an alphabetical sort than to describe the
8986 previous method in the documentation.)
8988 @node Complex Variables
8989 @section Complex Variables (COMPLEX)
8990 @cindex complex variables
8991 @cindex imaginary part of complex
8992 @cindex COMPLEX statement
8993 @cindex statements, COMPLEX
8995 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8996 (and related intrinsics, constants, functions, and so on)
8998 makes direct debugging involving these types in Fortran
8999 language mode difficult.
9001 Essentially, @code{g77} implements these types using an
9002 internal construct similar to C's @code{struct}, at least
9003 as seen by the @code{gcc} back end.
9005 Currently, the back end, when outputting debugging info with
9006 the compiled code for the assembler to digest, does not detect
9007 these @code{struct} types as being substitutes for Fortran
9009 As a result, the Fortran language modes of debuggers such as
9010 @code{gdb} see these types as C @code{struct} types, which
9011 they might or might not support.
9013 Until this is fixed, switch to C language mode to work with
9014 entities of @code{COMPLEX} type and then switch back to Fortran language
9016 (In @code{gdb}, this is accomplished via @samp{set lang c} and
9017 either @samp{set lang fortran} or @samp{set lang auto}.)
9019 @emph{Note:} Compiling with the @samp{-fno-emulate-complex} option
9020 avoids the debugging problem, but is known to cause other problems
9021 like compiler crashes and generation of incorrect code, so it is
9025 @section Arrays (DIMENSION)
9026 @cindex DIMENSION statement
9027 @cindex statements, DIMENSION
9028 @cindex array ordering
9029 @cindex ordering, array
9030 @cindex column-major ordering
9031 @cindex row-major ordering
9034 Fortran uses ``column-major ordering'' in its arrays.
9035 This differs from other languages, such as C, which use ``row-major ordering''.
9036 The difference is that, with Fortran, array elements adjacent to
9037 each other in memory differ in the @emph{first} subscript instead of
9038 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
9039 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
9042 affects not only interfacing with and debugging Fortran code,
9043 it can greatly affect how code is designed and written, especially
9044 when code speed and size is a concern.
9046 Fortran also differs from C, a popular language for interfacing and
9047 to support directly in debuggers, in the way arrays are treated.
9048 In C, arrays are single-dimensional and have interesting relationships
9049 to pointers, neither of which is true for Fortran.
9050 As a result, dealing with Fortran arrays from within
9051 an environment limited to C concepts can be challenging.
9053 For example, accessing the array element @samp{A(5,10,20)} is easy enough
9054 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
9056 First, C would treat the A array as a single-dimension array.
9057 Second, C does not understand low bounds for arrays as does Fortran.
9058 Third, C assumes a low bound of zero (0), while Fortran defaults to a
9059 low bound of one (1) and can supports an arbitrary low bound.
9060 Therefore, calculations must be done
9061 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
9062 calculations require knowing the dimensions of @samp{A}.
9064 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
9065 @samp{A(5,10,20)} would be:
9070 + (20-0)*(11-2+1)*(21-1+1)
9075 So the C equivalent in this case would be @samp{a[4293]}.
9077 When using a debugger directly on Fortran code, the C equivalent
9078 might not work, because some debuggers cannot understand the notion
9079 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
9080 does inform the GBE that a multi-dimensional array (like @samp{A}
9081 in the above example) is really multi-dimensional, rather than a
9082 single-dimensional array, so at least the dimensionality of the array
9085 Debuggers that understand Fortran should have no trouble with
9086 non-zero low bounds, but for non-Fortran debuggers, especially
9087 C debuggers, the above example might have a C equivalent of
9089 This calculation is arrived at by eliminating the subtraction
9090 of the lower bound in the first parenthesized expression on each
9091 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
9092 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
9093 Actually, the implication of
9094 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
9095 but that @samp{a[20][10][5]} produces the equivalent of
9096 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
9098 Come to think of it, perhaps
9099 the behavior is due to the debugger internally compensating for
9100 the lower bounds by offsetting the base address of @samp{a}, leaving
9101 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
9102 its first element as identified by subscripts equal to the
9103 corresponding lower bounds).
9105 You know, maybe nobody really needs to use arrays.
9107 @node Adjustable Arrays
9108 @section Adjustable Arrays (DIMENSION)
9109 @cindex arrays, adjustable
9110 @cindex adjustable arrays
9111 @cindex arrays, automatic
9112 @cindex automatic arrays
9113 @cindex DIMENSION statement
9114 @cindex statements, DIMENSION
9115 @cindex dimensioning arrays
9116 @cindex arrays, dimensioning
9118 Adjustable and automatic arrays in Fortran require the implementation
9120 case, the @code{g77} compiler) to ``memorize'' the expressions that
9121 dimension the arrays each time the procedure is invoked.
9122 This is so that subsequent changes to variables used in those
9123 expressions, made during execution of the procedure, do not
9124 have any effect on the dimensions of those arrays.
9141 Here, the implementation should, when running the program, print something
9149 Note that this shows that while the value of @samp{N} was successfully
9150 changed, the size of the @samp{A} array remained at 5 elements.
9152 To support this, @code{g77} generates code that executes before any user
9153 code (and before the internally generated computed @code{GOTO} to handle
9154 alternate entry points, as described below) that evaluates each
9155 (nonconstant) expression in the list of subscripts for an
9156 array, and saves the result of each such evaluation to be used when
9157 determining the size of the array (instead of re-evaluating the
9160 So, in the above example, when @samp{X} is first invoked, code is
9161 executed that copies the value of @samp{N} to a temporary.
9162 And that same temporary serves as the actual high bound for the single
9163 dimension of the @samp{A} array (the low bound being the constant 1).
9164 Since the user program cannot (legitimately) change the value
9165 of the temporary during execution of the procedure, the size
9166 of the array remains constant during each invocation.
9168 For alternate entry points, the code @code{g77} generates takes into
9169 account the possibility that a dummy adjustable array is not actually
9170 passed to the actual entry point being invoked at that time.
9171 In that case, the public procedure implementing the entry point
9172 passes to the master private procedure implementing all the
9173 code for the entry points a @code{NULL} pointer where a pointer to that
9174 adjustable array would be expected.
9175 The @code{g77}-generated code
9176 doesn't attempt to evaluate any of the expressions in the subscripts
9177 for an array if the pointer to that array is @code{NULL} at run time in
9179 (Don't depend on this particular implementation
9180 by writing code that purposely passes @code{NULL} pointers where the
9181 callee expects adjustable arrays, even if you know the callee
9182 won't reference the arrays---nor should you pass @code{NULL} pointers
9183 for any dummy arguments used in calculating the bounds of such
9184 arrays or leave undefined any values used for that purpose in
9185 COMMON---because the way @code{g77} implements these things might
9186 change in the future!)
9188 @node Alternate Entry Points
9189 @section Alternate Entry Points (ENTRY)
9190 @cindex alternate entry points
9191 @cindex entry points
9192 @cindex ENTRY statement
9193 @cindex statements, ENTRY
9195 The GBE does not understand the general concept of
9196 alternate entry points as Fortran provides via the ENTRY statement.
9197 @code{g77} gets around this by using an approach to compiling procedures
9198 having at least one @code{ENTRY} statement that is almost identical to the
9199 approach used by @code{f2c}.
9200 (An alternate approach could be used that
9201 would probably generate faster, but larger, code that would also
9202 be a bit easier to debug.)
9204 Information on how @code{g77} implements @code{ENTRY} is provided for those
9205 trying to debug such code.
9206 The choice of implementation seems
9207 unlikely to affect code (compiled in other languages) that interfaces
9210 @code{g77} compiles exactly one public procedure for the primary entry
9211 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9212 That is, in terms of the public interface, there is no difference
9231 The difference between the above two cases lies in the code compiled
9232 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9233 for the second case, an extra internal procedure is compiled.
9235 For every Fortran procedure with at least one @code{ENTRY}
9236 statement, @code{g77} compiles an extra procedure
9237 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9238 the name of the primary entry point (which, in the above case,
9239 using the standard compiler options, would be @samp{x_} in C).
9241 This extra procedure is compiled as a private procedure---that is,
9242 a procedure not accessible by name to separately compiled modules.
9243 It contains all the code in the program unit, including the code
9244 for the primary entry point plus for every entry point.
9245 (The code for each public procedure is quite short, and explained later.)
9247 The extra procedure has some other interesting characteristics.
9249 The argument list for this procedure is invented by @code{g77}.
9251 a single integer argument named @samp{__g77_which_entrypoint},
9252 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9253 entry point index---0 for the primary entry point, 1 for the
9254 first entry point (the first @code{ENTRY} statement encountered), 2 for
9255 the second entry point, and so on.
9257 It also contains, for functions returning @code{CHARACTER} and
9258 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9259 and for functions returning different types among the
9260 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9261 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9262 is expected at run time to contain a pointer to where to store
9263 the result of the entry point.
9264 For @code{CHARACTER} functions, this
9265 storage area is an array of the appropriate number of characters;
9266 for @code{COMPLEX} functions, it is the appropriate area for the return
9267 type; for multiple-return-type functions, it is a union of all the supported return
9268 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9269 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9270 is not supported by @code{g77}).
9272 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9273 by yet another argument named @samp{__g77_length} that, at run time,
9274 specifies the caller's expected length of the returned value.
9275 Note that only @code{CHARACTER*(*)} functions and entry points actually
9276 make use of this argument, even though it is always passed by
9277 all callers of public @code{CHARACTER} functions (since the caller does not
9278 generally know whether such a function is @code{CHARACTER*(*)} or whether
9279 there are any other callers that don't have that information).
9281 The rest of the argument list is the union of all the arguments
9282 specified for all the entry points (in their usual forms, e.g.
9283 @code{CHARACTER} arguments have extra length arguments, all appended at
9284 the end of this list).
9285 This is considered the ``master list'' of
9288 The code for this procedure has, before the code for the first
9289 executable statement, code much like that for the following Fortran
9293 GOTO (100000,100001,100002), __g77_which_entrypoint
9294 100000 @dots{}code for primary entry point@dots{}
9295 100001 @dots{}code immediately following first ENTRY statement@dots{}
9296 100002 @dots{}code immediately following second ENTRY statement@dots{}
9300 (Note that invalid Fortran statement labels and variable names
9301 are used in the above example to highlight the fact that it
9302 represents code generated by the @code{g77} internals, not code to be
9303 written by the user.)
9305 It is this code that, when the procedure is called, picks which
9306 entry point to start executing.
9308 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9309 example), those procedures are fairly simple.
9311 are just like they would be if they were self-contained procedures
9312 (without @code{ENTRY}), of course, since that is what the callers
9314 Their code consists of simply calling the private
9315 procedure, described above, with the appropriate extra arguments
9316 (the entry point index, and perhaps a pointer to a multiple-type-
9317 return variable, local to the public procedure, that contains
9318 all the supported returnable non-character types).
9320 that are not listed for a given entry point that are listed for
9321 other entry points, and therefore that are in the ``master list''
9322 for the private procedure, null pointers (in C, the @code{NULL} macro)
9324 Also, for entry points that are part of a multiple-type-
9325 returning function, code is compiled after the call of the private
9326 procedure to extract from the multi-type union the appropriate result,
9327 depending on the type of the entry point in question, returning
9328 that result to the original caller.
9330 When debugging a procedure containing alternate entry points, you
9331 can either set a break point on the public procedure itself (e.g.
9332 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9333 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9334 If you do the former, you should use the debugger's command to
9335 ``step into'' the called procedure to get to the actual code; with
9336 the latter approach, the break point leaves you right at the
9337 actual code, skipping over the public entry point and its call
9338 to the private procedure (unless you have set a break point there
9339 as well, of course).
9341 Further, the list of dummy arguments that is visible when the
9342 private procedure is active is going to be the expanded version
9343 of the list for whichever particular entry point is active,
9344 as explained above, and the way in which return values are
9345 handled might well be different from how they would be handled
9346 for an equivalent single-entry function.
9348 @node Alternate Returns
9349 @section Alternate Returns (SUBROUTINE and RETURN)
9351 @cindex alternate returns
9352 @cindex SUBROUTINE statement
9353 @cindex statements, SUBROUTINE
9354 @cindex RETURN statement
9355 @cindex statements, RETURN
9357 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9358 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9359 the C @code{int} type.
9360 The actual alternate-return arguments are omitted from the calling sequence.
9361 Instead, the caller uses
9362 the return value to do a rough equivalent of the Fortran
9363 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9364 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9365 function), and the callee just returns whatever integer
9366 is specified in the @code{RETURN} statement for the subroutine
9367 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9369 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9371 @node Assigned Statement Labels
9372 @section Assigned Statement Labels (ASSIGN and GOTO)
9373 @cindex assigned statement labels
9374 @cindex statement labels, assigned
9375 @cindex ASSIGN statement
9376 @cindex statements, ASSIGN
9377 @cindex GOTO statement
9378 @cindex statements, GOTO
9380 For portability to machines where a pointer (such as to a label,
9381 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9382 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9383 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9384 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9385 than it does the numerical value in that variable, unless the
9386 variable is wide enough (can hold enough bits).
9388 In particular, while @code{g77} implements
9395 as, in C notation, @samp{i = 10;}, it implements
9402 as, in GNU's extended C notation (for the label syntax),
9403 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9404 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9405 actually generate the name @samp{L10} or any other name like that,
9406 since debuggers cannot access labels anyway).
9408 While this currently means that an @code{ASSIGN} statement does not
9409 overwrite the numeric contents of its target variable, @emph{do not}
9410 write any code depending on this feature.
9411 @code{g77} has already changed this implementation across
9412 versions and might do so in the future.
9413 This information is provided only to make debugging Fortran programs
9414 compiled with the current version of @code{g77} somewhat easier.
9415 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9416 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9417 means @code{g77} has decided it can store the pointer to the label directly
9418 into @samp{I} itself.
9420 @xref{Ugly Assigned Labels}, for information on a command-line option
9421 to force @code{g77} to use the same storage for both normal and
9422 assigned-label uses of a variable.
9424 @node Run-time Library Errors
9425 @section Run-time Library Errors
9427 @cindex error values
9428 @cindex error messages
9429 @cindex messages, run-time
9432 The @code{libg2c} library currently has the following table to relate
9433 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9434 This information should, in future versions of this document, be
9435 expanded upon to include detailed descriptions of each message.
9437 In line with good coding practices, any of the numbers in the
9438 list below should @emph{not} be directly written into Fortran
9440 Instead, make a separate @code{INCLUDE} file that defines
9441 @code{PARAMETER} names for them, and use those in your code,
9442 so you can more easily change the actual numbers in the future.
9444 The information below is culled from the definition
9445 of @samp{F_err} in @file{f/runtime/libI77/err.c} in the
9446 @code{g77} source tree.
9449 100: "error in format"
9450 101: "illegal unit number"
9451 102: "formatted io not allowed"
9452 103: "unformatted io not allowed"
9453 104: "direct io not allowed"
9454 105: "sequential io not allowed"
9455 106: "can't backspace file"
9456 107: "null file name"
9457 108: "can't stat file"
9458 109: "unit not connected"
9459 110: "off end of record"
9460 111: "truncation failed in endfile"
9461 112: "incomprehensible list input"
9462 113: "out of free space"
9463 114: "unit not connected"
9464 115: "read unexpected character"
9465 116: "bad logical input field"
9466 117: "bad variable type"
9467 118: "bad namelist name"
9468 119: "variable not in namelist"
9469 120: "no end record"
9470 121: "variable count incorrect"
9471 122: "subscript for scalar variable"
9472 123: "invalid array section"
9473 124: "substring out of bounds"
9474 125: "subscript out of bounds"
9475 126: "can't read file"
9476 127: "can't write file"
9477 128: "'new' file exists"
9478 129: "can't append to file"
9479 130: "non-positive record number"
9480 131: "I/O started while already doing I/O"
9483 @node Collected Fortran Wisdom
9484 @chapter Collected Fortran Wisdom
9487 @cindex code, legacy
9488 @cindex writing code
9489 @cindex code, writing
9491 Most users of @code{g77} can be divided into two camps:
9495 Those writing new Fortran code to be compiled by @code{g77}.
9498 Those using @code{g77} to compile existing, ``legacy'' code.
9501 Users writing new code generally understand most of the necessary
9502 aspects of Fortran to write ``mainstream'' code, but often need
9503 help deciding how to handle problems, such as the construction
9504 of libraries containing @code{BLOCK DATA}.
9506 Users dealing with ``legacy'' code sometimes don't have much
9507 experience with Fortran, but believe that the code they're compiling
9508 already works when compiled by other compilers (and might
9509 not understand why, as is sometimes the case, it doesn't work
9510 when compiled by @code{g77}).
9512 The following information is designed to help users do a better job
9513 coping with existing, ``legacy'' Fortran code, and with writing
9517 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9518 * Block Data and Libraries:: How @code{g77} solves a common problem.
9519 * Loops:: Fortran @code{DO} loops surprise many people.
9520 * Working Programs:: Getting programs to work should be done first.
9521 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9522 * Faster Programs:: Everybody wants these, but at what cost?
9525 @node Advantages Over f2c
9526 @section Advantages Over f2c
9528 Without @code{f2c}, @code{g77} would have taken much longer to
9529 do and probably not been as good for quite a while.
9530 Sometimes people who notice how much @code{g77} depends on, and
9531 documents encouragement to use, @code{f2c} ask why @code{g77}
9532 was created if @code{f2c} already existed.
9534 This section gives some basic answers to these questions, though it
9535 is not intended to be comprehensive.
9538 * Language Extensions:: Features used by Fortran code.
9539 * Compiler Options:: Features helpful during development.
9540 * Compiler Speed:: Speed of the compilation process.
9541 * Program Speed:: Speed of the generated, optimized code.
9542 * Ease of Debugging:: Debugging ease-of-use at the source level.
9543 * Character and Hollerith Constants:: A byte saved is a byte earned.
9546 @node Language Extensions
9547 @subsection Language Extensions
9549 @code{g77} offers several extensions to the Fortran language that @code{f2c}
9552 However, @code{f2c} offers a few that @code{g77} doesn't, like
9553 fairly complete support for @code{INTEGER*2}.
9554 It is expected that @code{g77} will offer some or all of these missing
9555 features at some time in the future.
9556 (Version 0.5.18 of @code{g77} offers some rudimentary support for some
9559 @node Compiler Options
9560 @subsection Compiler Options
9562 @code{g77} offers a whole bunch of compiler options that @code{f2c} doesn't.
9564 However, @code{f2c} offers a few that @code{g77} doesn't, like an
9565 option to generate code to check array subscripts at run time.
9566 It is expected that @code{g77} will offer some or all of these
9567 missing options at some time in the future.
9569 @node Compiler Speed
9570 @subsection Compiler Speed
9572 Saving the steps of writing and then rereading C code is a big reason
9573 why @code{g77} should be able to compile code much faster than using
9574 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9576 However, due to @code{g77}'s youth, lots of self-checking is still being
9578 As a result, this improvement is as yet unrealized
9579 (though the potential seems to be there for quite a big speedup
9581 It is possible that, as of version 0.5.18, @code{g77}
9582 is noticeably faster compiling many Fortran source files than using
9583 @code{f2c} in conjunction with @code{gcc}.
9586 @subsection Program Speed
9588 @code{g77} has the potential to better optimize code than @code{f2c},
9589 even when @code{gcc} is used to compile the output of @code{f2c},
9590 because @code{f2c} must necessarily
9591 translate Fortran into a somewhat lower-level language (C) that cannot
9592 preserve all the information that is potentially useful for optimization,
9593 while @code{g77} can gather, preserve, and transmit that information directly
9596 For example, @code{g77} implements @code{ASSIGN} and assigned
9597 @code{GOTO} using direct assignment of pointers to labels and direct
9598 jumps to labels, whereas @code{f2c} maps the assigned labels to
9599 integer values and then uses a C @code{switch} statement to encode
9600 the assigned @code{GOTO} statements.
9602 However, as is typical, theory and reality don't quite match, at least
9603 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9604 can generate code that is faster than @code{g77}.
9606 Version 0.5.18 of @code{g77} offered default
9607 settings and options, via patches to the @code{gcc}
9608 back end, that allow for better program speed, though
9609 some of these improvements also affected the performance
9610 of programs translated by @code{f2c} and then compiled
9611 by @code{g77}'s version of @code{gcc}.
9613 Version 0.5.20 of @code{g77} offers further performance
9614 improvements, at least one of which (alias analysis) is
9615 not generally applicable to @code{f2c} (though @code{f2c}
9616 could presumably be changed to also take advantage of
9617 this new capability of the @code{gcc} back end, assuming
9618 this is made available in an upcoming release of @code{gcc}).
9620 @node Ease of Debugging
9621 @subsection Ease of Debugging
9623 Because @code{g77} compiles directly to assembler code like @code{gcc},
9624 instead of translating to an intermediate language (C) as does @code{f2c},
9625 support for debugging can be better for @code{g77} than @code{f2c}.
9627 However, although @code{g77} might be somewhat more ``native'' in terms of
9628 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9629 of things ``not quite right''.
9630 Many of the important ones should be resolved in the near future.
9632 For example, @code{g77} doesn't have to worry about reserved names
9633 like @code{f2c} does.
9634 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9635 translate this to something @emph{other} than
9636 @samp{for = while;}, because C reserves those words.
9638 However, @code{g77} does still uses things like an extra level of indirection
9639 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9640 yet support multiple entry points.
9642 Another example is that, given
9650 the @code{g77} user should be able to access the variables directly, by name,
9651 without having to traverse C-like structures and unions, while @code{f2c}
9652 is unlikely to ever offer this ability (due to limitations in the
9655 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9656 take advantage of this facility at all---it doesn't emit any debugging
9657 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9658 other than information
9659 on the array of @code{char} it creates (and, in the case
9660 of local @code{EQUIVALENCE}, names) for each such area.
9662 Yet another example is arrays.
9663 @code{g77} represents them to the debugger
9664 using the same ``dimensionality'' as in the source code, while @code{f2c}
9665 must necessarily convert them all to one-dimensional arrays to fit
9666 into the confines of the C language.
9667 However, the level of support
9668 offered by debuggers for interactive Fortran-style access to arrays
9669 as compiled by @code{g77} can vary widely.
9670 In some cases, it can actually
9671 be an advantage that @code{f2c} converts everything to widely supported
9674 In fairness, @code{g77} could do many of the things @code{f2c} does
9675 to get things working at least as well as @code{f2c}---for now,
9676 the developers prefer making @code{g77} work the
9677 way they think it is supposed to, and finding help improving the
9678 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9679 to get things working properly.
9681 @node Character and Hollerith Constants
9682 @subsection Character and Hollerith Constants
9683 @cindex character constants
9684 @cindex constants, character
9685 @cindex Hollerith constants
9686 @cindex constants, Hollerith
9687 @cindex trailing null byte
9688 @cindex null byte, trailing
9689 @cindex zero byte, trailing
9691 To avoid the extensive hassle that would be needed to avoid this,
9692 @code{f2c} uses C character constants to encode character and Hollerith
9694 That means a constant like @samp{'HELLO'} is translated to
9695 @samp{"hello"} in C, which further means that an extra null byte is
9696 present at the end of the constant.
9697 This null byte is superfluous.
9699 @code{g77} does not generate such null bytes.
9700 This represents significant
9701 savings of resources, such as on systems where @file{/dev/null} or
9702 @file{/dev/zero} represent bottlenecks in the systems' performance,
9703 because @code{g77} simply asks for fewer zeros from the operating
9704 system than @code{f2c}.
9705 (Avoiding spurious use of zero bytes, each byte typically have
9706 eight zero bits, also reduces the liabilities in case
9707 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9709 @node Block Data and Libraries
9710 @section Block Data and Libraries
9711 @cindex block data and libraries
9712 @cindex BLOCK DATA statement
9713 @cindex statements, BLOCK DATA
9714 @cindex libraries, containing BLOCK DATA
9715 @cindex @code{f2c} compatibility
9716 @cindex compatibility, @code{f2c}
9718 To ensure that block data program units are linked, especially a concern
9719 when they are put into libraries, give each one a name (as in
9720 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9721 statement in every program unit that uses any common block
9722 initialized by the corresponding @code{BLOCK DATA}.
9723 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9725 that is, it generates an actual procedure having the appropriate name.
9726 The procedure does nothing but return immediately if it happens to be
9728 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9729 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9730 in the program and ensures that by generating a
9731 reference to it so the linker will make sure it is present.
9732 (Specifically, @code{g77} outputs in the data section a static pointer to the
9733 external name @samp{FOO}.)
9735 The implementation @code{g77} currently uses to make this work is
9736 one of the few things not compatible with @code{f2c} as currently
9738 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9739 issue a warning that @samp{FOO} is not otherwise referenced,
9740 and, for @samp{BLOCK DATA FOO},
9741 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9742 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9743 this particular case.
9744 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9745 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9746 will result in an unresolved reference when linked.
9748 opposite, then @samp{FOO} might not be linked in under various
9749 circumstances (such as when @samp{FOO} is in a library, or you're
9750 using a ``clever'' linker---so clever, it produces a broken program
9751 with little or no warning by omitting initializations of global data
9752 because they are contained in unreferenced procedures).
9754 The changes you make to your code to make @code{g77} handle this situation,
9755 however, appear to be a widely portable way to handle it.
9756 That is, many systems permit it (as they should, since the
9757 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9758 is a block data program unit), and of the ones
9759 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9760 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9763 Here is the recommended approach to modifying a program containing
9764 a program unit such as the following:
9768 COMMON /VARS/ X, Y, Z
9769 DATA X, Y, Z / 3., 4., 5. /
9774 If the above program unit might be placed in a library module, then
9775 ensure that every program unit in every program that references that
9776 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9777 to force the area to be initialized.
9779 For example, change a program unit that starts with
9782 INTEGER FUNCTION CURX()
9783 COMMON /VARS/ X, Y, Z
9789 so that it uses the @code{EXTERNAL} statement, as in:
9792 INTEGER FUNCTION CURX()
9793 COMMON /VARS/ X, Y, Z
9800 That way, @samp{CURX} is compiled by @code{g77} (and many other
9801 compilers) so that the linker knows it must include @samp{FOO},
9802 the @code{BLOCK DATA} program unit that sets the initial values
9803 for the variables in @samp{VAR}, in the executable program.
9807 @cindex DO statement
9808 @cindex statements, DO
9809 @cindex trips, number of
9810 @cindex number of trips
9812 The meaning of a @code{DO} loop in Fortran is precisely specified
9813 in the Fortran standard@dots{}and is quite different from what
9814 many programmers might expect.
9816 In particular, Fortran @code{DO} loops are implemented as if
9817 the number of trips through the loop is calculated @emph{before}
9818 the loop is entered.
9820 The number of trips for a loop is calculated from the @var{start},
9821 @var{end}, and @var{increment} values specified in a statement such as:
9824 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9828 The trip count is evaluated using a fairly simple formula
9829 based on the three values following the @samp{=} in the
9830 statement, and it is that trip count that is effectively
9831 decremented during each iteration of the loop.
9832 If, at the beginning of an iteration of the loop, the
9833 trip count is zero or negative, the loop terminates.
9834 The per-loop-iteration modifications to @var{iter} are not
9835 related to determining whether to terminate the loop.
9837 There are two important things to remember about the trip
9842 It can be @emph{negative}, in which case it is
9843 treated as if it was zero---meaning the loop is
9844 not executed at all.
9847 The type used to @emph{calculate} the trip count
9848 is the same type as @var{iter}, but the final
9849 calculation, and thus the type of the trip
9850 count itself, always is @code{INTEGER(KIND=1)}.
9853 These two items mean that there are loops that cannot
9854 be written in straightforward fashion using the Fortran @code{DO}.
9856 For example, on a system with the canonical 32-bit two's-complement
9857 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9860 DO I = -2000000000, 2000000000
9864 Although the @var{start} and @var{end} values are well within
9865 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9866 The expected trip count is 40000000001, which is outside
9867 the range of @code{INTEGER(KIND=1)} on many systems.
9869 Instead, the above loop should be constructed this way:
9874 IF (I .GT. 2000000000) EXIT
9881 The simple @code{DO} construct and the @code{EXIT} statement
9882 (used to leave the innermost loop)
9883 are F90 features that @code{g77} supports.
9885 Some Fortran compilers have buggy implementations of @code{DO},
9886 in that they don't follow the standard.
9887 They implement @code{DO} as a straightforward translation
9888 to what, in C, would be a @code{for} statement.
9889 Instead of creating a temporary variable to hold the trip count
9890 as calculated at run time, these compilers
9891 use the iteration variable @var{iter} to control
9892 whether the loop continues at each iteration.
9894 The bug in such an implementation shows up when the
9895 trip count is within the range of the type of @var{iter},
9896 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9897 exceeds that range. For example:
9900 DO I = 2147483600, 2147483647
9904 A loop started by the above statement will work as implemented
9905 by @code{g77}, but the use, by some compilers, of a
9906 more C-like implementation akin to
9909 for (i = 2147483600; i <= 2147483647; ++i)
9913 produces a loop that does not terminate, because @samp{i}
9914 can never be greater than 2147483647, since incrementing it
9915 beyond that value overflows @samp{i}, setting it to -2147483648.
9916 This is a large, negative number that still is less than 2147483647.
9918 Another example of unexpected behavior of @code{DO} involves
9919 using a nonintegral iteration variable @var{iter}, that is,
9920 a @code{REAL} variable.
9921 Consider the following program:
9924 DATA BEGIN, END, STEP /.1, .31, .007/
9925 DO 10 R = BEGIN, END, STEP
9926 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9930 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9935 A C-like view of @code{DO} would hold that the two ``exclamatory''
9936 @code{PRINT} statements are never executed.
9937 However, this is the output of running the above program
9938 as compiled by @code{g77} on a GNU/Linux ix86 system:
9950 .310000002 .LE. .310000002!!
9953 Note that one of the two checks in the program turned up
9954 an apparent violation of the programmer's expectation---yet,
9955 the loop is correctly implemented by @code{g77}, in that
9956 it has 30 iterations.
9957 This trip count of 30 is correct when evaluated using
9958 the floating-point representations for the @var{begin},
9959 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
9961 On other systems, an apparently more accurate trip count
9962 of 31 might result, but, nevertheless, @code{g77} is
9963 faithfully following the Fortran standard, and the result
9964 is not what the author of the sample program above
9965 apparently expected.
9966 (Such other systems might, for different values in the @code{DATA}
9967 statement, violate the other programmer's expectation,
9970 Due to this combination of imprecise representation
9971 of floating-point values and the often-misunderstood
9972 interpretation of @code{DO} by standard-conforming
9973 compilers such as @code{g77}, use of @code{DO} loops
9974 with @code{REAL} iteration
9975 variables is not recommended.
9976 Such use can be caught by specifying @samp{-Wsurprising}.
9977 @xref{Warning Options}, for more information on this
9980 @node Working Programs
9981 @section Working Programs
9983 Getting Fortran programs to work in the first place can be
9984 quite a challenge---even when the programs already work on
9985 other systems, or when using other compilers.
9987 @code{g77} offers some facilities that might be useful for
9988 tracking down bugs in such programs.
9992 * Variables Assumed To Be Zero::
9993 * Variables Assumed To Be Saved::
9994 * Unwanted Variables::
9995 * Unused Arguments::
9996 * Surprising Interpretations of Code::
9997 * Aliasing Assumed To Work::
9998 * Output Assumed To Flush::
9999 * Large File Unit Numbers::
10003 @subsection Not My Type
10004 @cindex mistyped variables
10005 @cindex variables, mistyped
10006 @cindex mistyped functions
10007 @cindex functions, mistyped
10008 @cindex implicit typing
10010 A fruitful source of bugs in Fortran source code is use, or
10011 mis-use, of Fortran's implicit-typing feature, whereby the
10012 type of a variable, array, or function is determined by the
10013 first character of its name.
10015 Simple cases of this include statements like @samp{LOGX=9.227},
10016 without a statement such as @samp{REAL LOGX}.
10017 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
10018 type, with the result of the assignment being that it is given
10019 the value @samp{9}.
10021 More involved cases include a function that is defined starting
10022 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
10023 Any caller of this function that does not also declare @samp{IPS}
10024 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
10025 is likely to assume it returns
10026 @code{INTEGER}, or some other type, leading to invalid results
10027 or even program crashes.
10029 The @samp{-Wimplicit} option might catch failures to
10030 properly specify the types of
10031 variables, arrays, and functions in the code.
10033 However, in code that makes heavy use of Fortran's
10034 implicit-typing facility, this option might produce so
10035 many warnings about cases that are working, it would be
10036 hard to find the one or two that represent bugs.
10037 This is why so many experienced Fortran programmers strongly
10038 recommend widespread use of the @code{IMPLICIT NONE} statement,
10039 despite it not being standard FORTRAN 77, to completely turn
10040 off implicit typing.
10041 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
10042 FORTRAN 77 compilers.)
10044 Note that @samp{-Wimplicit} catches only implicit typing of
10046 It does not catch implicit typing of expressions such
10047 as @samp{X**(2/3)}.
10048 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
10049 is equivalent to @samp{X**0}, due to the way Fortran expressions
10050 are given types and then evaluated.
10051 (In this particular case, the programmer probably wanted
10052 @samp{X**(2./3.)}.)
10054 @node Variables Assumed To Be Zero
10055 @subsection Variables Assumed To Be Zero
10056 @cindex zero-initialized variables
10057 @cindex variables assumed to be zero
10058 @cindex uninitialized variables
10060 Many Fortran programs were developed on systems that provided
10061 automatic initialization of all, or some, variables and arrays
10063 As a result, many of these programs depend, sometimes
10064 inadvertently, on this behavior, though to do so violates
10065 the Fortran standards.
10067 You can ask @code{g77} for this behavior by specifying the
10068 @samp{-finit-local-zero} option when compiling Fortran code.
10069 (You might want to specify @samp{-fno-automatic} as well,
10070 to avoid code-size inflation for non-optimized compilations.)
10072 Note that a program that works better when compiled with the
10073 @samp{-finit-local-zero} option
10074 is almost certainly depending on a particular system's,
10075 or compiler's, tendency to initialize some variables to zero.
10076 It might be worthwhile finding such cases and fixing them,
10077 using techniques such as compiling with the @samp{-O -Wuninitialized}
10078 options using @code{g77}.
10080 @node Variables Assumed To Be Saved
10081 @subsection Variables Assumed To Be Saved
10082 @cindex variables retaining values across calls
10083 @cindex saved variables
10084 @cindex static variables
10086 Many Fortran programs were developed on systems that
10087 saved the values of all, or some, variables and arrays
10088 across procedure calls.
10089 As a result, many of these programs depend, sometimes
10090 inadvertently, on being able to assign a value to a
10091 variable, perform a @code{RETURN} to a calling procedure,
10092 and, upon subsequent invocation, reference the previously
10093 assigned variable to obtain the value.
10095 They expect this despite not using the @code{SAVE} statement
10096 to specify that the value in a variable is expected to survive
10097 procedure returns and calls.
10098 Depending on variables and arrays to retain values across
10099 procedure calls without using @code{SAVE} to require it violates
10100 the Fortran standards.
10102 You can ask @code{g77} to assume @code{SAVE} is specified for all
10103 relevant (local) variables and arrays by using the
10104 @samp{-fno-automatic} option.
10106 Note that a program that works better when compiled with the
10107 @samp{-fno-automatic} option
10108 is almost certainly depending on not having to use
10109 the @code{SAVE} statement as required by the Fortran standard.
10110 It might be worthwhile finding such cases and fixing them,
10111 using techniques such as compiling with the @samp{-O -Wuninitialized}
10112 options using @code{g77}.
10114 @node Unwanted Variables
10115 @subsection Unwanted Variables
10117 The @samp{-Wunused} option can find bugs involving
10118 implicit typing, sometimes
10119 more easily than using @samp{-Wimplicit} in code that makes
10120 heavy use of implicit typing.
10121 An unused variable or array might indicate that the
10122 spelling for its declaration is different from that of
10125 Other than cases involving typos, unused variables rarely
10126 indicate actual bugs in a program.
10127 However, investigating such cases thoroughly has, on occasion,
10128 led to the discovery of code that had not been completely
10129 written---where the programmer wrote declarations as needed
10130 for the whole algorithm, wrote some or even most of the code
10131 for that algorithm, then got distracted and forgot that the
10132 job was not complete.
10134 @node Unused Arguments
10135 @subsection Unused Arguments
10136 @cindex unused arguments
10137 @cindex arguments, unused
10139 As with unused variables, It is possible that unused arguments
10140 to a procedure might indicate a bug.
10141 Compile with @samp{-W -Wunused} option to catch cases of
10144 Note that @samp{-W} also enables warnings regarding overflow
10145 of floating-point constants under certain circumstances.
10147 @node Surprising Interpretations of Code
10148 @subsection Surprising Interpretations of Code
10150 The @samp{-Wsurprising} option can help find bugs involving
10151 expression evaluation or in
10152 the way @code{DO} loops with non-integral iteration variables
10154 Cases found by this option might indicate a difference of
10155 interpretation between the author of the code involved, and
10156 a standard-conforming compiler such as @code{g77}.
10157 Such a difference might produce actual bugs.
10159 In any case, changing the code to explicitly do what the
10160 programmer might have expected it to do, so @code{g77} and
10161 other compilers are more likely to follow the programmer's
10162 expectations, might be worthwhile, especially if such changes
10163 make the program work better.
10165 @node Aliasing Assumed To Work
10166 @subsection Aliasing Assumed To Work
10167 @cindex -falias-check option
10168 @cindex options, -falias-check
10169 @cindex -fargument-alias option
10170 @cindex options, -fargument-alias
10171 @cindex -fargument-noalias option
10172 @cindex options, -fargument-noalias
10173 @cindex -fno-argument-noalias-global option
10174 @cindex options, -fno-argument-noalias-global
10176 @cindex anti-aliasing
10177 @cindex overlapping arguments
10179 @cindex association, storage
10180 @cindex storage association
10181 @cindex scheduling of reads and writes
10182 @cindex reads and writes, scheduling
10184 The @samp{-falias-check}, @samp{-fargument-alias},
10185 @samp{-fargument-noalias},
10186 and @samp{-fno-argument-noalias-global} options,
10187 introduced in version 0.5.20 and
10188 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10189 were withdrawn as of @code{g77} version 0.5.23
10190 due to their not being supported by @code{gcc} version 2.8.
10192 These options, which control the assumptions regarding aliasing
10193 (overlapping) of writes and reads to main memory (core) made
10194 by the @code{gcc} back end,
10195 might well be added back (in some form) in a future version
10198 However, these options @emph{are} supported by @code{egcs}.
10200 The information below still is useful, but applies to
10201 only those versions of @code{g77} that support the
10202 alias analysis implied by support for these options.
10204 These options are effective only when compiling with @samp{-O}
10205 (specifying any level other than @samp{-O0})
10206 or with @samp{-falias-check}.
10208 The default for Fortran code is @samp{-fargument-noalias-global}.
10209 (The default for C code and code written in other C-based languages
10210 is @samp{-fargument-alias}.
10211 These defaults apply regardless of whether you use @code{g77} or
10212 @code{gcc} to compile your code.)
10214 Note that, on some systems, compiling with @samp{-fforce-addr} in
10215 effect can produce more optimal code when the default aliasing
10216 options are in effect (and when optimization is enabled).
10218 If your program is not working when compiled with optimization,
10219 it is possible it is violating the Fortran standards (77 and 90)
10220 by relying on the ability to ``safely'' modify variables and
10221 arrays that are aliased, via procedure calls, to other variables
10222 and arrays, without using @code{EQUIVALENCE} to explicitly
10223 set up this kind of aliasing.
10225 (The FORTRAN 77 standard's prohibition of this sort of
10226 overlap, generally referred to therein as ``storage
10227 assocation'', appears in Sections 15.9.3.6.
10228 This prohibition allows implementations, such as @code{g77},
10229 to, for example, implement the passing of procedures and
10230 even values in @code{COMMON} via copy operations into local,
10231 perhaps more efficiently accessed temporaries at entry to a
10232 procedure, and, where appropriate, via copy operations back
10233 out to their original locations in memory at exit from that
10234 procedure, without having to take into consideration the
10235 order in which the local copies are updated by the code,
10236 among other things.)
10238 To test this hypothesis, try compiling your program with
10239 the @samp{-fargument-alias} option, which causes the
10240 compiler to revert to assumptions essentially the same as
10241 made by versions of @code{g77} prior to 0.5.20.
10243 If the program works using this option, that strongly suggests
10244 that the bug is in your program.
10245 Finding and fixing the bug(s) should result in a program that
10246 is more standard-conforming and that can be compiled by @code{g77}
10247 in a way that results in a faster executable.
10249 (You might want to try compiling with @samp{-fargument-noalias},
10250 a kind of half-way point, to see if the problem is limited to
10251 aliasing between dummy arguments and @code{COMMON} variables---this
10252 option assumes that such aliasing is not done, while still allowing
10253 aliasing among dummy arguments.)
10255 An example of aliasing that is invalid according to the standards
10256 is shown in the following program, which might @emph{not} produce
10257 the expected results when executed:
10265 SUBROUTINE FOO(J, K)
10272 The above program attempts to use the temporary aliasing of the
10273 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10274 pathological behavior---the simultaneous changing of the values
10275 of @emph{both} @samp{J} and @samp{K} when either one of them
10278 The programmer likely expects the program to print these values:
10285 However, since the program is not standard-conforming, an
10286 implementation's behavior when running it is undefined, because
10287 subroutine @samp{FOO} modifies at least one of the arguments,
10288 and they are aliased with each other.
10289 (Even if one of the assignment statements was deleted, the
10290 program would still violate these rules.
10291 This kind of on-the-fly aliasing is permitted by the standard
10292 only when none of the aliased items are defined, or written,
10293 while the aliasing is in effect.)
10295 As a practical example, an optimizing compiler might schedule
10296 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10297 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10298 resulting in the following output:
10305 Essentially, compilers are promised (by the standard and, therefore,
10306 by programmers who write code they claim to be standard-conforming)
10307 that if they cannot detect aliasing via static analysis of a single
10308 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10309 such aliasing exists.
10310 In such cases, compilers are free to assume that an assignment to
10311 one variable will not change the value of another variable, allowing
10312 it to avoid generating code to re-read the value of the other
10313 variable, to re-schedule reads and writes, and so on, to produce
10314 a faster executable.
10316 The same promise holds true for arrays (as seen by the called
10317 procedure)---an element of one dummy array cannot be aliased
10318 with, or overlap, any element of another dummy array or be
10319 in a @code{COMMON} area known to the procedure.
10321 (These restrictions apply only when the procedure defines, or
10322 writes to, one of the aliased variables or arrays.)
10324 Unfortunately, there is no way to find @emph{all} possible cases of
10325 violations of the prohibitions against aliasing in Fortran code.
10326 Static analysis is certainly imperfect, as is run-time analysis,
10327 since neither can catch all violations.
10328 (Static analysis can catch all likely violations, and some that
10329 might never actually happen, while run-time analysis can catch
10330 only those violations that actually happen during a particular run.
10331 Neither approach can cope with programs mixing Fortran code with
10332 routines written in other languages, however.)
10334 Currently, @code{g77} provides neither static nor run-time facilities
10335 to detect any cases of this problem, although other products might.
10336 Run-time facilities are more likely to be offered by future
10337 versions of @code{g77}, though patches improving @code{g77} so that
10338 it provides either form of detection are welcome.
10340 @node Output Assumed To Flush
10341 @subsection Output Assumed To Flush
10342 @cindex ALWAYS_FLUSH
10343 @cindex synchronous write errors
10345 @cindex flushing output
10347 @cindex I/O, flushing
10348 @cindex output, flushing
10349 @cindex writes, flushing
10351 @cindex network file system
10353 For several versions prior to 0.5.20, @code{g77} configured its
10354 version of the @code{libf2c} run-time library so that one of
10355 its configuration macros, @samp{ALWAYS_FLUSH}, was defined.
10357 This was done as a result of a belief that many programs expected
10358 output to be flushed to the operating system (under UNIX, via
10359 the @code{fflush()} library call) with the result that errors,
10360 such as disk full, would be immediately flagged via the
10361 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10363 Because of the adverse effects this approach had on the performance
10364 of many programs, @code{g77} no longer configures @code{libf2c}
10365 (now named @code{libg2c} in its @code{g77} incarnation)
10366 to always flush output.
10368 If your program depends on this behavior, either insert the
10369 appropriate @samp{CALL FLUSH} statements, or modify the sources
10370 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10371 relink your programs with the modified library.
10373 (Ideally, @code{libg2c} would offer the choice at run-time, so
10374 that a compile-time option to @code{g77} or @code{f2c} could
10375 result in generating the appropriate calls to flushing or
10376 non-flushing library routines.)
10378 @xref{Always Flush Output}, for information on how to modify
10379 the @code{g77} source tree so that a version of @code{libg2c}
10380 can be built and installed with the @samp{ALWAYS_FLUSH} macro defined.
10382 @node Large File Unit Numbers
10383 @subsection Large File Unit Numbers
10385 @cindex unit numbers
10386 @cindex maximum unit number
10387 @cindex illegal unit number
10388 @cindex increasing maximum unit number
10390 If your program crashes at run time with a message including
10391 the text @samp{illegal unit number}, that probably is
10392 a message from the run-time library, @code{libg2c}.
10394 The message means that your program has attempted to use a
10395 file unit number that is out of the range accepted by
10397 Normally, this range is 0 through 99, and the high end
10398 of the range is controlled by a @code{libg2c} source-file
10399 macro named @samp{MXUNIT}.
10401 If you can easily change your program to use unit numbers
10402 in the range 0 through 99, you should do so.
10404 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10405 to change @samp{MXUNIT} in @code{libg2c} so you can build and
10406 install a new version of @code{libg2c} that supports the larger
10407 unit numbers you need.
10409 @emph{Note:} While @code{libg2c} places a limit on the range
10410 of Fortran file-unit numbers, the underlying library and operating
10411 system might impose different kinds of limits.
10412 For example, some systems limit the number of files simultaneously
10413 open by a running program.
10414 Information on how to increase these limits should be found
10415 in your system's documentation.
10417 @node Overly Convenient Options
10418 @section Overly Convenient Command-line Options
10419 @cindex overly convenient options
10420 @cindex options, overly convenient
10422 These options should be used only as a quick-and-dirty way to determine
10423 how well your program will run under different compilation models
10424 without having to change the source.
10425 Some are more problematic
10426 than others, depending on how portable and maintainable you want the
10427 program to be (and, of course, whether you are allowed to change it
10428 at all is crucial).
10430 You should not continue to use these command-line options to compile
10431 a given program, but rather should make changes to the source code:
10434 @cindex -finit-local-zero option
10435 @cindex options, -finit-local-zero
10436 @item -finit-local-zero
10437 (This option specifies that any uninitialized local variables
10438 and arrays have default initialization to binary zeros.)
10440 Many other compilers do this automatically, which means lots of
10441 Fortran code developed with those compilers depends on it.
10443 It is safer (and probably
10444 would produce a faster program) to find the variables and arrays that
10445 need such initialization and provide it explicitly via @code{DATA}, so that
10446 @samp{-finit-local-zero} is not needed.
10448 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10449 find likely candidates, but
10450 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10451 or this technique won't work.
10453 @cindex -fno-automatic option
10454 @cindex options, -fno-automatic
10455 @item -fno-automatic
10456 (This option specifies that all local variables and arrays
10457 are to be treated as if they were named in @code{SAVE} statements.)
10459 Many other compilers do this automatically, which means lots of
10460 Fortran code developed with those compilers depends on it.
10462 The effect of this is that all non-automatic variables and arrays
10463 are made static, that is, not placed on the stack or in heap storage.
10464 This might cause a buggy program to appear to work better.
10465 If so, rather than relying on this command-line option (and hoping all
10466 compilers provide the equivalent one), add @code{SAVE}
10467 statements to some or all program unit sources, as appropriate.
10468 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10469 to find likely candidates, but
10470 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10471 or this technique won't work.
10473 The default is @samp{-fautomatic}, which tells @code{g77} to try
10474 and put variables and arrays on the stack (or in fast registers)
10475 where possible and reasonable.
10476 This tends to make programs faster.
10478 @cindex automatic arrays
10479 @cindex arrays, automatic
10480 @emph{Note:} Automatic variables and arrays are not affected
10482 These are variables and arrays that are @emph{necessarily} automatic,
10483 either due to explicit statements, or due to the way they are
10485 Examples include local variables and arrays not given the
10486 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10487 and local arrays declared with non-constant bounds (automatic
10489 Currently, @code{g77} supports only automatic arrays, not
10490 @code{RECURSIVE} procedures or other means of explicitly
10491 specifying that variables or arrays are automatic.
10493 @cindex -fugly option
10494 @cindex options, -fugly
10496 Fix the source code so that @samp{-fno-ugly} will work.
10497 Note that, for many programs, it is difficult to practically
10498 avoid using the features enabled via @samp{-fugly-init}, and these
10499 features pose the lowest risk of writing nonportable code, among the
10500 various ``ugly'' features.
10502 @cindex -f@var{group}-intrinsics-hide option
10503 @cindex options, -f@var{group}-intrinsics-hide
10504 @item -f@var{group}-intrinsics-hide
10505 Change the source code to use @code{EXTERNAL} for any external procedure
10506 that might be the name of an intrinsic.
10507 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10510 @node Faster Programs
10511 @section Faster Programs
10512 @cindex speeding up programs
10513 @cindex programs, speeding up
10515 Aside from the usual @code{gcc} options, such as @samp{-O},
10516 @samp{-ffast-math}, and so on, consider trying some of the
10517 following approaches to speed up your program (once you get
10522 * Prefer Automatic Uninitialized Variables::
10523 * Avoid f2c Compatibility::
10524 * Use Submodel Options::
10528 @subsection Aligned Data
10529 @cindex data, aligned
10530 @cindex stack, aligned
10531 @cindex aligned data
10532 @cindex aligned stack
10533 @cindex Pentium optimizations
10534 @cindex optimizations, Pentium
10536 On some systems, such as those with Pentium Pro CPUs, programs
10537 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10538 might run much slower
10539 than possible due to the compiler not aligning these 64-bit
10540 values to 64-bit boundaries in memory.
10541 (The effect also is present, though
10542 to a lesser extent, on the 586 (Pentium) architecture.)
10544 The Intel x86 architecture generally ensures that these programs will
10545 work on all its implementations,
10546 but particular implementations (such as Pentium Pro)
10547 perform better with more strict alignment.
10548 (Such behavior isn't unique to the Intel x86 architecture.)
10549 Other architectures might @emph{demand} 64-bit alignment
10552 There are a variety of approaches to use to address this problem:
10556 @cindex COMMON, layout
10557 @cindex layout of common blocks
10558 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10559 that the variables and arrays with the widest alignment
10560 guidelines come first.
10562 For example, on most systems, this would mean placing
10563 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10564 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10565 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10566 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10567 and @code{INTEGER(KIND=3)} entities.
10569 The reason to use such placement is it makes it more likely
10570 that your data will be aligned properly, without requiring
10571 you to do detailed analysis of each aggregate (@code{COMMON}
10572 and @code{EQUIVALENCE}) area.
10574 Specifically, on systems where the above guidelines are
10575 appropriate, placing @code{CHARACTER} entities before
10576 @code{REAL(KIND=2)} entities can work just as well,
10577 but only if the number of bytes occupied by the @code{CHARACTER}
10578 entities is divisible by the recommended alignment for
10579 @code{REAL(KIND=2)}.
10581 By ordering the placement of entities in aggregate
10582 areas according to the simple guidelines above, you
10583 avoid having to carefully count the number of bytes
10584 occupied by each entity to determine whether the
10585 actual alignment of each subsequent entity meets the
10586 alignment guidelines for the type of that entity.
10588 If you don't ensure correct alignment of @code{COMMON} elements, the
10589 compiler may be forced by some systems to violate the Fortran semantics by
10590 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10591 If the unfortunate practice is employed of overlaying different types of
10592 data in the @code{COMMON} block, the different variants
10593 of this block may become misaligned with respect to each other.
10594 Even if your platform doesn't require strict alignment,
10595 @code{COMMON} should be laid out as above for portability.
10596 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10597 possible requirement, which is compiler-independent on a given platform.)
10600 @cindex -malign-double option
10601 @cindex options, -malign-double
10602 Use the (x86-specific) @samp{-malign-double} option when compiling
10603 programs for the Pentium and Pentium Pro architectures (called 586
10604 and 686 in the @code{gcc} configuration subsystem).
10605 The warning about this in the @code{gcc} manual isn't
10606 generally relevant to Fortran,
10607 but using it will force @code{COMMON} to be padded if necessary to align
10608 @code{DOUBLE PRECISION} data.
10610 When @code{DOUBLE PRECISION} data is forcibly aligned
10611 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10612 @code{g77} issues a warning about the need to
10615 In this case, each and every program unit that uses
10616 the same @code{COMMON} area
10617 must specify the same layout of variables and their types
10619 and be compiled with @samp{-malign-double} as well.
10620 @code{g77} will issue warnings in each case,
10621 but as long as every program unit using that area
10622 is compiled with the same warnings,
10623 the resulting object files should work when linked together
10624 unless the program makes additional assumptions about
10625 @code{COMMON} area layouts that are outside the scope
10626 of the FORTRAN 77 standard,
10627 or uses @code{EQUIVALENCE} or different layouts
10628 in ways that assume no padding is ever inserted by the compiler.
10630 @emph{Note:} @samp{-malign-double} applies only to
10631 statically-allocated data.
10632 Double-precision data on the stack can still
10633 cause problems due to misalignment.
10634 @xref{Aligned Data}.
10637 Ensure that @file{crt0.o} or @file{crt1.o}
10638 on your system guarantees a 64-bit
10639 aligned stack for @code{main()}.
10640 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10641 but we don't know of any other x86 setups where it will be right.
10642 Read your system's documentation to determine if
10643 it is appropriate to upgrade to a more recent version
10644 to obtain the optimal alignment.
10647 Progress is being made on making this work
10648 ``out of the box'' on future versions of @code{g77},
10649 @code{gcc}, and some of the relevant operating systems
10650 (such as GNU/Linux).
10652 @node Prefer Automatic Uninitialized Variables
10653 @subsection Prefer Automatic Uninitialized Variables
10655 If you're using @samp{-fno-automatic} already, you probably
10656 should change your code to allow compilation with @samp{-fautomatic}
10657 (the default), to allow the program to run faster.
10659 Similarly, you should be able to use @samp{-fno-init-local-zero}
10660 (the default) instead of @samp{-finit-local-zero}.
10661 This is because it is rare that every variable affected by these
10662 options in a given program actually needs to
10665 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10666 every local non-automatic variable and array, affects even things like
10667 @code{DO} iteration
10668 variables, which rarely need to be @code{SAVE}d, and this often reduces
10669 run-time performances.
10670 Similarly, @samp{-fno-init-local-zero} forces such
10671 variables to be initialized to zero---when @code{SAVE}d (such as when
10672 @samp{-fno-automatic}), this by itself generally affects only
10673 startup time for a program, but when not @code{SAVE}d,
10674 it can slow down the procedure every time it is called.
10676 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10677 for information on the @samp{-fno-automatic} and
10678 @samp{-finit-local-zero} options and how to convert
10679 their use into selective changes in your own code.
10681 @node Avoid f2c Compatibility
10682 @subsection Avoid f2c Compatibility
10683 @cindex -fno-f2c option
10684 @cindex options, -fno-f2c
10685 @cindex @code{f2c} compatibility
10686 @cindex compatibility, @code{f2c}
10688 If you aren't linking with any code compiled using
10689 @code{f2c}, try using the @samp{-fno-f2c} option when
10690 compiling @emph{all} the code in your program.
10691 (Note that @code{libf2c} is @emph{not} an example of code
10692 that is compiled using @code{f2c}---it is compiled by a C
10693 compiler, typically @code{gcc}.)
10695 @node Use Submodel Options
10696 @subsection Use Submodel Options
10697 @cindex Pentium optimizations
10698 @cindex optimizations, Pentium
10699 @cindex 586/686 CPUs
10702 Using an appropriate @samp{-m} option to generate specific code for your
10703 CPU may be worthwhile, though it may mean the executable won't run on
10704 other versions of the CPU that don't support the same instruction set.
10705 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10708 For recent CPUs that don't have explicit support in
10709 the released version of @code{gcc}, it may still be possible to get
10711 For instance, the flags recommended for 586/686
10712 (Pentium(Pro)) chips for building the Linux kernel are:
10715 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
10716 -fomit-frame-pointer
10719 @noindent @samp{-fomit-frame-pointer} will, however, inhibit debugging
10723 @chapter Known Causes of Trouble with GNU Fortran
10724 @cindex bugs, known
10725 @cindex installation trouble
10726 @cindex known causes of trouble
10728 This section describes known problems that affect users of GNU Fortran.
10729 Most of these are not GNU Fortran bugs per se---if they were, we would
10731 But the result for a user might be like the result of a bug.
10733 Some of these problems are due to bugs in other software, some are
10734 missing features that are too much work to add, and some are places
10735 where people's opinions differ as to what is best.
10737 Information on bugs that show up when configuring, porting, building,
10738 or installing @code{g77} is not provided here.
10739 @xref{Problems Installing}.
10741 To find out about major bugs discovered in the current release and
10742 possible workarounds for them, retrieve
10743 @uref{ftp://alpha.gnu.org/g77.plan}.
10745 (Note that some of this portion of the manual is lifted
10746 directly from the @code{gcc} manual, with minor modifications
10747 to tailor it to users of @code{g77}.
10748 Anytime a bug seems to have more to do with the @code{gcc}
10749 portion of @code{g77},
10750 @xref{Trouble,,Known Causes of Trouble with GNU CC,
10751 gcc,Using and Porting GNU CC}.)
10754 * But-bugs:: Bugs really in other programs or elsewhere.
10755 * Actual Bugs:: Bugs and misfeatures we will fix later.
10756 * Missing Features:: Features we already know we want to add later.
10757 * Disappointments:: Regrettable things we can't change.
10758 * Non-bugs:: Things we think are right, but some others disagree.
10759 * Warnings and Errors:: Which problems in your code get warnings,
10760 and which get errors.
10764 @section Bugs Not In GNU Fortran
10767 These are bugs to which the maintainers often have to reply,
10768 ``but that isn't a bug in @code{g77}@dots{}''.
10769 Some of these already are fixed in new versions of other
10770 software; some still need to be fixed; some are problems
10771 with how @code{g77} is installed or is being used;
10772 some are the result of bad hardware that causes software
10773 to misbehave in sometimes bizarre ways;
10774 some just cannot be addressed at this time until more
10775 is known about the problem.
10777 Please don't re-report these bugs to the @code{g77} maintainers---if
10778 you must remind someone how important it is to you that the problem
10779 be fixed, talk to the people responsible for the other products
10780 identified below, but preferably only after you've tried the
10781 latest versions of those products.
10782 The @code{g77} maintainers have their hands full working on
10783 just fixing and improving @code{g77}, without serving as a
10784 clearinghouse for all bugs that happen to affect @code{g77}
10787 @xref{Collected Fortran Wisdom}, for information on behavior
10788 of Fortran programs, and the programs that compile them, that
10789 might be @emph{thought} to indicate bugs.
10792 * Signal 11 and Friends:: Strange behavior by any software.
10793 * Cannot Link Fortran Programs:: Unresolved references.
10794 * Large Common Blocks:: Problems on older GNU/Linux systems.
10795 * Debugger Problems:: When the debugger crashes.
10796 * NeXTStep Problems:: Misbehaving executables.
10797 * Stack Overflow:: More misbehaving executables.
10798 * Nothing Happens:: Less behaving executables.
10799 * Strange Behavior at Run Time:: Executables misbehaving due to
10800 bugs in your program.
10801 * Floating-point Errors:: The results look wrong, but@dots{}.
10804 @node Signal 11 and Friends
10805 @subsection Signal 11 and Friends
10807 @cindex hardware errors
10809 A whole variety of strange behaviors can occur when the
10810 software, or the way you are using the software,
10811 stresses the hardware in a way that triggers hardware bugs.
10812 This might seem hard to believe, but it happens frequently
10813 enough that there exist documents explaining in detail
10814 what the various causes of the problems are, what
10815 typical symptoms look like, and so on.
10817 Generally these problems are referred to in this document
10818 as ``signal 11'' crashes, because the Linux kernel, running
10819 on the most popular hardware (the Intel x86 line), often
10820 stresses the hardware more than other popular operating
10822 When hardware problems do occur under GNU/Linux on x86
10823 systems, these often manifest themselves as ``signal 11''
10824 problems, as illustrated by the following diagnostic:
10827 sh# @kbd{g77 myprog.f}
10828 gcc: Internal compiler error: program f771 got fatal signal 11
10832 It is @emph{very} important to remember that the above
10833 message is @emph{not} the only one that indicates a
10834 hardware problem, nor does it always indicate a hardware
10837 In particular, on systems other than those running the Linux
10838 kernel, the message might appear somewhat or very different,
10839 as it will if the error manifests itself while running a
10840 program other than the @code{g77} compiler.
10842 it will appear somewhat different when running your program,
10843 when running Emacs, and so on.
10845 How to cope with such problems is well beyond the scope
10848 However, users of Linux-based systems (such as GNU/Linux)
10849 should review @uref{http://www.bitwizard.nl/sig11}, a source
10850 of detailed information on diagnosing hardware problems,
10851 by recognizing their common symptoms.
10853 Users of other operating systems and hardware might
10854 find this reference useful as well.
10855 If you know of similar material for another hardware/software
10856 combination, please let us know so we can consider including
10857 a reference to it in future versions of this manual.
10859 @node Cannot Link Fortran Programs
10860 @subsection Cannot Link Fortran Programs
10861 @cindex unresolved reference (various)
10862 @cindex linking error for user code
10864 @cindex ld error for user code
10865 @cindex ld can't find strange names
10866 On some systems, perhaps just those with out-of-date (shared?)
10867 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10868 programs (which should be done using @code{g77}).
10870 If this happens to you, try appending @samp{-lc} to the command you
10871 use to link the program, e.g. @samp{g77 foo.f -lc}.
10872 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10873 but it cannot also specify @samp{-lc} because not all systems have a
10874 file named @file{libc.a}.
10876 It is unclear at this point whether there are legitimately installed
10877 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10880 @cindex undefined reference (_main)
10881 @cindex linking error for user code
10882 @cindex ld error for user code
10884 @cindex ld can't find _main
10885 If your program doesn't link due to unresolved references to names
10886 like @samp{_main}, make sure you're using the @code{g77} command to do the
10887 link, since this command ensures that the necessary libraries are
10888 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10889 command to do the actual link.
10890 (Use the @samp{-v} option to discover
10891 more about what actually happens when you use the @code{g77} and @code{gcc}
10894 Also, try specifying @samp{-lc} as the last item on the @code{g77}
10895 command line, in case that helps.
10897 @node Large Common Blocks
10898 @subsection Large Common Blocks
10899 @cindex common blocks, large
10900 @cindex large common blocks
10901 @cindex linker errors
10903 @cindex errors, linker
10904 On some older GNU/Linux systems, programs with common blocks larger
10905 than 16MB cannot be linked without some kind of error
10906 message being produced.
10908 This is a bug in older versions of @code{ld}, fixed in
10909 more recent versions of @code{binutils}, such as version 2.6.
10911 @node Debugger Problems
10912 @subsection Debugger Problems
10913 @cindex @code{gdb} support
10914 @cindex support, @code{gdb}
10915 There are some known problems when using @code{gdb} on code
10916 compiled by @code{g77}.
10917 Inadequate investigation as of the release of 0.5.16 results in not
10918 knowing which products are the culprit, but @file{gdb-4.14} definitely
10919 crashes when, for example, an attempt is made to print the contents
10920 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
10921 machines, plus some others.
10922 Attempts to access assumed-size arrays are
10923 also known to crash recent versions of @code{gdb}.
10924 (@code{gdb}'s Fortran support was done for a different compiler
10925 and isn't properly compatible with @code{g77}.)
10927 @node NeXTStep Problems
10928 @subsection NeXTStep Problems
10929 @cindex NeXTStep problems
10931 @cindex segmentation violation
10932 Developers of Fortran code on NeXTStep (all architectures) have to
10933 watch out for the following problem when writing programs with
10934 large, statically allocated (i.e. non-stack based) data structures
10935 (common blocks, saved arrays).
10937 Due to the way the native loader (@file{/bin/ld}) lays out
10938 data structures in virtual memory, it is very easy to create an
10939 executable wherein the @samp{__DATA} segment overlaps (has addresses in
10940 common) with the @samp{UNIX STACK} segment.
10942 This leads to all sorts of trouble, from the executable simply not
10943 executing, to bus errors.
10944 The NeXTStep command line tool @code{ebadexec} points to
10945 the problem as follows:
10948 % @kbd{/bin/ebadexec a.out}
10949 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
10950 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
10951 STACK segment (truncated address = 0x400000 rounded size =
10952 0x3c00000) of executable file: a.out
10955 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
10958 This can be cured by assigning the @samp{__DATA} segment
10959 (virtual) addresses beyond the stack segment.
10961 estimate for this is from address 6000000 (hexadecimal) onwards---this
10962 has always worked for me [Toon Moene]:
10965 % @kbd{g77 -segaddr __DATA 6000000 test.f}
10966 % @kbd{ebadexec a.out}
10967 ebadexec: file: a.out appears to be executable
10971 Browsing through @file{@value{path-g77}/Makefile.in},
10972 you will find that the @code{f771} program itself also has to be
10973 linked with these flags---it has large statically allocated
10975 (Version 0.5.18 reduces this somewhat, but probably
10978 (The above item was contributed by Toon Moene
10979 (@email{toon@@moene.indiv.nluug.nl}).)
10981 @node Stack Overflow
10982 @subsection Stack Overflow
10983 @cindex stack overflow
10984 @cindex segmentation violation
10985 @code{g77} code might fail at runtime (probably with a ``segmentation
10986 violation'') due to overflowing the stack.
10987 This happens most often on systems with an environment
10988 that provides substantially more heap space (for use
10989 when arbitrarily allocating and freeing memory) than stack
10992 Often this can be cured by
10993 increasing or removing your shell's limit on stack usage, typically
10994 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
10995 @kbd{ulimit -s} (in @code{sh} and derivatives).
10997 Increasing the allowed stack size might, however, require
10998 changing some operating system or system configuration parameters.
11000 You might be able to work around the problem by compiling with the
11001 @samp{-fno-automatic} option to reduce stack usage, probably at the
11004 @xref{Maximum Stackable Size}, for information on patching
11005 @code{g77} to use different criteria for placing local
11006 non-automatic variables and arrays on the stack.
11008 @cindex automatic arrays
11009 @cindex arrays, automatic
11010 However, if your program uses large automatic arrays
11011 (for example, has declarations like @samp{REAL A(N)} where
11012 @samp{A} is a local array and @samp{N} is a dummy or
11013 @code{COMMON} variable that can have a large value),
11014 neither use of @samp{-fno-automatic},
11015 nor changing the cut-off point for @code{g77} for using the stack,
11016 will solve the problem by changing the placement of these
11017 large arrays, as they are @emph{necessarily} automatic.
11019 @code{g77} currently provides no means to specify that
11020 automatic arrays are to be allocated on the heap instead
11022 So, other than increasing the stack size, your best bet is to
11023 change your source code to avoid large automatic arrays.
11024 Methods for doing this currently are outside the scope of
11027 (@emph{Note:} If your system puts stack and heap space in the
11028 same memory area, such that they are effectively combined, then
11029 a stack overflow probably indicates a program that is either
11030 simply too large for the system, or buggy.)
11032 @node Nothing Happens
11033 @subsection Nothing Happens
11034 @cindex nothing happens
11035 @cindex naming programs @samp{test}
11036 @cindex @samp{test} programs
11037 @cindex programs named @samp{test}
11038 It is occasionally reported that a ``simple'' program,
11039 such as a ``Hello, World!'' program, does nothing when
11040 it is run, even though the compiler reported no errors,
11041 despite the program containing nothing other than a
11042 simple @code{PRINT} statement.
11044 This most often happens because the program has been
11045 compiled and linked on a UNIX system and named @samp{test},
11046 though other names can lead to similarly unexpected
11047 run-time behavior on various systems.
11049 Essentially this problem boils down to giving
11050 your program a name that is already known to
11051 the shell you are using to identify some other program,
11052 which the shell continues to execute instead of your
11053 program when you invoke it via, for example:
11060 Under UNIX and many other system, a simple command name
11061 invokes a searching mechanism that might well not choose
11062 the program located in the current working directory if
11063 there is another alternative (such as the @code{test}
11064 command commonly installed on UNIX systems).
11066 The reliable way to invoke a program you just linked in
11067 the current directory under UNIX is to specify it using
11068 an explicit pathname, as in:
11076 Users who encounter this problem should take the time to
11077 read up on how their shell searches for commands, how to
11078 set their search path, and so on.
11079 The relevant UNIX commands to learn about include
11080 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
11081 @code{set} and @code{env}), @code{which}, and @code{find}.
11083 @node Strange Behavior at Run Time
11084 @subsection Strange Behavior at Run Time
11085 @cindex segmentation violation
11087 @cindex overwritten data
11088 @cindex data, overwritten
11089 @code{g77} code might fail at runtime with ``segmentation violation'',
11090 ``bus error'', or even something as subtle as a procedure call
11091 overwriting a variable or array element that it is not supposed
11094 These can be symptoms of a wide variety of actual bugs that
11095 occurred earlier during the program's run, but manifested
11096 themselves as @emph{visible} problems some time later.
11098 Overflowing the bounds of an array---usually by writing beyond
11099 the end of it---is one of two kinds of bug that often occurs
11102 The other kind of bug is a mismatch between the actual arguments
11103 passed to a procedure and the dummy arguments as declared by that
11106 Both of these kinds of bugs, and some others as well, can be
11107 difficult to track down, because the bug can change its behavior,
11108 or even appear to not occur, when using a debugger.
11110 That is, these bugs can be quite sensitive to data, including
11111 data representing the placement of other data in memory (that is,
11112 pointers, such as the placement of stack frames in memory).
11114 Plans call for improving @code{g77} so that it can offer the
11115 ability to catch and report some of these problems at compile, link, or
11116 run time, such as by generating code to detect references to
11117 beyond the bounds of an array, or checking for agreement between
11118 calling and called procedures.
11120 In the meantime, finding and fixing the programming
11121 bugs that lead to these behaviors is, ultimately, the user's
11122 responsibility, as difficult as that task can sometimes be.
11124 @cindex ``infinite spaces'' printed
11125 @cindex spaces, endless printing of
11126 @cindex libc, non-ANSI or non-default
11128 @cindex linking against non-standard library
11130 One runtime problem that has been observed might have a simple solution.
11131 If a formatted @code{WRITE} produces an endless stream of spaces, check
11132 that your program is linked against the correct version of the C library.
11133 The configuration process takes care to account for your
11134 system's normal @file{libc} not being ANSI-standard, which will
11135 otherwise cause this behaviour.
11136 If your system's default library is
11137 ANSI-standard and you subsequently link against a non-ANSI one, there
11138 might be problems such as this one.
11140 Specifically, on Solaris2 systems,
11141 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
11143 @node Floating-point Errors
11144 @subsection Floating-point Errors
11145 @cindex floating-point errors
11146 @cindex rounding errors
11147 @cindex inconsistent floating-point results
11148 @cindex results, inconsistent
11149 Some programs appear to produce inconsistent floating-point
11150 results compiled by @code{g77} versus by other compilers.
11152 Often the reason for this behavior is the fact that floating-point
11153 values are represented on almost all Fortran systems by
11154 @emph{approximations}, and these approximations are inexact
11155 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
11156 0.7, 0.8, 0.9, 1.1, and so on.
11157 Most Fortran systems, including all current ports of @code{g77},
11158 use binary arithmetic to represent these approximations.
11160 Therefore, the exact value of any floating-point approximation
11161 as manipulated by @code{g77}-compiled code is representable by
11162 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11163 so on (just keep dividing by two) through the precision of the
11164 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11165 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11166 power of two (in Fortran, by @samp{2**N}) that typically is between
11167 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11168 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11171 So, a value like 0.2 is exactly represented in decimal---since
11172 it is a fraction, @samp{2/10}, with a denominator that is compatible
11173 with the base of the number system (base 10).
11174 However, @samp{2/10} cannot be represented by any finite number
11175 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11176 be exactly represented in binary notation.
11178 (On the other hand, decimal notation can represent any binary
11179 number in a finite number of digits.
11180 Decimal notation cannot do so with ternary, or base-3,
11181 notation, which would represent floating-point numbers as
11182 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11183 After all, no finite number of decimal digits can exactly
11184 represent @samp{1/3}.
11185 Fortunately, few systems use ternary notation.)
11187 Moreover, differences in the way run-time I/O libraries convert
11188 between these approximations and the decimal representation often
11189 used by programmers and the programs they write can result in
11190 apparent differences between results that do not actually exist,
11191 or exist to such a small degree that they usually are not worth
11194 For example, consider the following program:
11201 When compiled by @code{g77}, the above program might output
11202 @samp{0.20000003}, while another compiler might produce a
11203 executable that outputs @samp{0.2}.
11205 This particular difference is due to the fact that, currently,
11206 conversion of floating-point values by the @code{libg2c} library,
11207 used by @code{g77}, handles only double-precision values.
11209 Since @samp{0.2} in the program is a single-precision value, it
11210 is converted to double precision (still in binary notation)
11211 before being converted back to decimal.
11212 The conversion to binary appends _binary_ zero digits to the
11213 original value---which, again, is an inexact approximation of
11214 0.2---resulting in an approximation that is much less exact
11215 than is connoted by the use of double precision.
11217 (The appending of binary zero digits has essentially the same
11218 effect as taking a particular decimal approximation of
11219 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11220 zeros to it, producing @samp{0.33333330000000000}.
11221 Treating the resulting decimal approximation as if it really
11222 had 18 or so digits of valid precision would make it seem
11223 a very poor approximation of @samp{1/3}.)
11225 As a result of converting the single-precision approximation
11226 to double precision by appending binary zeros, the conversion
11227 of the resulting double-precision
11228 value to decimal produces what looks like an incorrect
11229 result, when in fact the result is @emph{inexact}, and
11230 is probably no less inaccurate or imprecise an approximation
11231 of 0.2 than is produced by other compilers that happen to output
11232 the converted value as ``exactly'' @samp{0.2}.
11233 (Some compilers behave in a way that can make them appear
11234 to retain more accuracy across a conversion of a single-precision
11235 constant to double precision.
11236 @xref{Context-Sensitive Constants}, to see why
11237 this practice is illusory and even dangerous.)
11239 Note that a more exact approximation of the constant is
11240 computed when the program is changed to specify a
11241 double-precision constant:
11248 Future versions of @code{g77} and/or @code{libg2c} might convert
11249 single-precision values directly to decimal,
11250 instead of converting them to double precision first.
11251 This would tend to result in output that is more consistent
11252 with that produced by some other Fortran implementations.
11256 @node Missing Features
11257 @section Missing Features
11259 This section lists features we know are missing from @code{g77},
11260 and which we want to add someday.
11261 (There is no priority implied in the ordering below.)
11264 GNU Fortran language:
11265 * Better Source Model::
11266 * Fortran 90 Support::
11267 * Intrinsics in PARAMETER Statements::
11268 * SELECT CASE on CHARACTER Type::
11269 * RECURSIVE Keyword::
11270 * Popular Non-standard Types::
11271 * Full Support for Compiler Types::
11272 * Array Bounds Expressions::
11273 * POINTER Statements::
11274 * Sensible Non-standard Constructs::
11275 * FLUSH Statement::
11276 * Expressions in FORMAT Statements::
11277 * Explicit Assembler Code::
11278 * Q Edit Descriptor::
11280 GNU Fortran dialects:
11281 * Old-style PARAMETER Statements::
11282 * TYPE and ACCEPT I/O Statements::
11283 * STRUCTURE UNION RECORD MAP::
11284 * OPEN CLOSE and INQUIRE Keywords::
11285 * ENCODE and DECODE::
11286 * Suppressing Space Padding::
11287 * Fortran Preprocessor::
11288 * Bit Operations on Floating-point Data::
11292 * Floating-point Exception Handling::
11293 * Nonportable Conversions::
11294 * Large Automatic Arrays::
11295 * Support for Threads::
11296 * Increasing Precision/Range::
11298 Better diagnostics:
11299 * Gracefully Handle Sensible Bad Code::
11300 * Non-standard Conversions::
11301 * Non-standard Intrinsics::
11302 * Modifying DO Variable::
11303 * Better Pedantic Compilation::
11304 * Warn About Implicit Conversions::
11305 * Invalid Use of Hollerith Constant::
11306 * Dummy Array Without Dimensioning Dummy::
11307 * Invalid FORMAT Specifiers::
11308 * Ambiguous Dialects::
11310 * Informational Messages::
11312 Run-time facilities:
11313 * Uninitialized Variables at Run Time::
11314 * Bounds Checking at Run Time::
11317 * Labels Visible to Debugger::
11320 @node Better Source Model
11321 @subsection Better Source Model
11323 @code{g77} needs to provide, as the default source-line model,
11324 a ``pure visual'' mode, where
11325 the interpretation of a source program in this mode can be accurately
11326 determined by a user looking at a traditionally displayed rendition
11327 of the program (assuming the user knows whether the program is fixed
11330 The design should assume the user cannot tell tabs from spaces
11331 and cannot see trailing spaces on lines, but has canonical tab stops
11332 and, for fixed-form source, has the ability to always know exactly
11333 where column 72 is (since the Fortran standard itself requires
11334 this for fixed-form source).
11336 This would change the default treatment of fixed-form source
11337 to not treat lines with tabs as if they were infinitely long---instead,
11338 they would end at column 72 just as if the tabs were replaced
11339 by spaces in the canonical way.
11341 As part of this, provide common alternate models (Digital, @code{f2c},
11342 and so on) via command-line options.
11343 This includes allowing arbitrarily long
11344 lines for free-form source as well as fixed-form source and providing
11345 various limits and diagnostics as appropriate.
11347 @cindex sequence numbers
11348 @cindex columns 73 through 80
11349 Also, @code{g77} should offer, perhaps even default to, warnings
11350 when characters beyond the last valid column are anything other
11352 This would mean code with ``sequence numbers'' in columns 73 through 80
11353 would be rejected, and there's a lot of that kind of code around,
11354 but one of the most frequent bugs encountered by new users is
11355 accidentally writing fixed-form source code into and beyond
11357 So, maybe the users of old code would be able to more easily handle
11358 having to specify, say, a @code{-Wno-col73to80} option.
11360 @node Fortran 90 Support
11361 @subsection Fortran 90 Support
11362 @cindex Fortran 90 support
11363 @cindex support, Fortran 90
11365 @code{g77} does not support many of the features that
11366 distinguish Fortran 90 (and, now, Fortran 95) from
11369 Some Fortran 90 features are supported, because they
11370 make sense to offer even to die-hard users of F77.
11371 For example, many of them codify various ways F77 has
11372 been extended to meet users' needs during its tenure,
11373 so @code{g77} might as well offer them as the primary
11374 way to meet those same needs, even if it offers compatibility
11375 with one or more of the ways those needs were met
11376 by other F77 compilers in the industry.
11378 Still, many important F90 features are not supported,
11379 because no attempt has been made to research each and
11380 every feature and assess its viability in @code{g77}.
11381 In the meantime, users who need those features must
11382 use Fortran 90 compilers anyway, and the best approach
11383 to adding some F90 features to GNU Fortran might well be
11384 to fund a comprehensive project to create GNU Fortran 95.
11386 @node Intrinsics in PARAMETER Statements
11387 @subsection Intrinsics in @code{PARAMETER} Statements
11388 @cindex PARAMETER statement
11389 @cindex statements, PARAMETER
11391 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11392 This feature is considered to be absolutely vital, even though it
11393 is not standard-conforming, and is scheduled for version 0.6.
11395 Related to this, @code{g77} doesn't allow non-integral
11396 exponentiation in @code{PARAMETER} statements, such as
11397 @samp{PARAMETER (R=2**.25)}.
11398 It is unlikely @code{g77} will ever support this feature,
11399 as doing it properly requires complete emulation of
11400 a target computer's floating-point facilities when
11401 building @code{g77} as a cross-compiler.
11402 But, if the @code{gcc} back end is enhanced to provide
11403 such a facility, @code{g77} will likely use that facility
11404 in implementing this feature soon afterwards.
11406 @node SELECT CASE on CHARACTER Type
11407 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11409 Character-type selector/cases for @code{SELECT CASE} currently
11412 @node RECURSIVE Keyword
11413 @subsection @code{RECURSIVE} Keyword
11414 @cindex RECURSIVE keyword
11415 @cindex keywords, RECURSIVE
11416 @cindex recursion, lack of
11417 @cindex lack of recursion
11419 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11421 Nor does it provide any means for compiling procedures
11422 designed to do recursion.
11424 All recursive code can be rewritten to not use recursion,
11425 but the result is not pretty.
11427 @node Increasing Precision/Range
11428 @subsection Increasing Precision/Range
11432 @cindex increasing precision
11433 @cindex precision, increasing
11434 @cindex increasing range
11435 @cindex range, increasing
11439 Some compilers, such as @code{f2c}, have an option (@samp{-r8} or
11440 similar) that provides automatic treatment of @code{REAL}
11441 entities such that they have twice the storage size, and
11442 a corresponding increase in the range and precision, of what
11443 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11444 (This affects @code{COMPLEX} the same way.)
11446 They also typically offer another option (@samp{-i8}) to increase
11447 @code{INTEGER} entities so they are twice as large
11448 (with roughly twice as much range).
11450 (There are potential pitfalls in using these options.)
11452 @code{g77} does not yet offer any option that performs these
11453 kinds of transformations.
11454 Part of the problem is the lack of detailed specifications regarding
11455 exactly how these options affect the interpretation of constants,
11456 intrinsics, and so on.
11458 Until @code{g77} addresses this need, programmers could improve
11459 the portability of their code by modifying it to not require
11460 compile-time options to produce correct results.
11461 Some free tools are available which may help, specifically
11462 in Toolpack (which one would expect to be sound) and the @file{fortran}
11463 section of the Netlib repository.
11465 Use of preprocessors can provide a fairly portable means
11466 to work around the lack of widely portable methods in the Fortran
11467 language itself (though increasing acceptance of Fortran 90 would
11468 alleviate this problem).
11470 @node Popular Non-standard Types
11471 @subsection Popular Non-standard Types
11472 @cindex INTEGER*2 support
11473 @cindex LOGICAL*1 support
11475 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11477 Version 0.6 will provide full support for this very
11478 popular set of features.
11479 In the meantime, version 0.5.18 provides rudimentary support
11482 @node Full Support for Compiler Types
11483 @subsection Full Support for Compiler Types
11485 @cindex REAL*16 support
11486 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11487 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11488 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11489 This means providing intrinsic support, and maybe constant
11490 support (using F90 syntax) as well, and, for most
11491 machines will result in automatic support of @code{INTEGER*1},
11492 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11494 This is scheduled for version 0.6.
11496 @node Array Bounds Expressions
11497 @subsection Array Bounds Expressions
11498 @cindex array elements, in adjustable array bounds
11499 @cindex function references, in adjustable array bounds
11500 @cindex array bounds, adjustable
11501 @cindex DIMENSION statement
11502 @cindex statements, DIMENSION
11504 @code{g77} doesn't support more general expressions to dimension
11505 arrays, such as array element references, function
11508 For example, @code{g77} currently does not accept the following:
11512 INTEGER N(10), M(N(2), N(1))
11515 @node POINTER Statements
11516 @subsection POINTER Statements
11517 @cindex POINTER statement
11518 @cindex statements, POINTER
11519 @cindex Cray pointers
11521 @code{g77} doesn't support pointers or allocatable objects
11522 (other than automatic arrays).
11523 This set of features is
11524 probably considered just behind intrinsics
11525 in @code{PARAMETER} statements on the list of large,
11526 important things to add to @code{g77}.
11528 In the meantime, consider using the @code{INTEGER(KIND=7)}
11529 declaration to specify that a variable must be
11530 able to hold a pointer.
11531 This construct is not portable to other non-GNU compilers,
11532 but it is portable to all machines GNU Fortran supports
11533 when @code{g77} is used.
11535 @xref{Functions and Subroutines}, for information on
11536 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11537 constructs, which are useful for passing pointers to
11538 procedures written in languages other than Fortran.
11540 @node Sensible Non-standard Constructs
11541 @subsection Sensible Non-standard Constructs
11543 @code{g77} rejects things other compilers accept,
11544 like @samp{INTRINSIC SQRT,SQRT}.
11545 As time permits in the future, some of these things that are easy for
11546 humans to read and write and unlikely to be intended to mean something
11547 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11548 trigger warnings about such non-standard constructs).
11550 Until @code{g77} no longer gratuitously rejects sensible code,
11551 you might as well fix your code
11552 to be more standard-conforming and portable.
11554 The kind of case that is important to except from the
11555 recommendation to change your code is one where following
11556 good coding rules would force you to write non-standard
11557 code that nevertheless has a clear meaning.
11559 For example, when writing an @code{INCLUDE} file that
11560 defines a common block, it might be appropriate to
11561 include a @code{SAVE} statement for the common block
11562 (such as @samp{SAVE /CBLOCK/}), so that variables
11563 defined in the common block retain their values even
11564 when all procedures declaring the common block become
11565 inactive (return to their callers).
11567 However, putting @code{SAVE} statements in an @code{INCLUDE}
11568 file would prevent otherwise standard-conforming code
11569 from also specifying the @code{SAVE} statement, by itself,
11570 to indicate that all local variables and arrays are to
11571 have the @code{SAVE} attribute.
11573 For this reason, @code{g77} already has been changed to
11574 allow this combination, because although the general
11575 problem of gratuitously rejecting unambiguous and
11576 ``safe'' constructs still exists in @code{g77}, this
11577 particular construct was deemed useful enough that
11578 it was worth fixing @code{g77} for just this case.
11580 So, while there is no need to change your code
11581 to avoid using this particular construct, there
11582 might be other, equally appropriate but non-standard
11583 constructs, that you shouldn't have to stop using
11584 just because @code{g77} (or any other compiler)
11585 gratuitously rejects it.
11587 Until the general problem is solved, if you have
11588 any such construct you believe is worthwhile
11589 using (e.g. not just an arbitrary, redundant
11590 specification of an attribute), please submit a
11591 bug report with an explanation, so we can consider
11592 fixing @code{g77} just for cases like yours.
11594 @node FLUSH Statement
11595 @subsection @code{FLUSH} Statement
11597 @code{g77} could perhaps use a @code{FLUSH} statement that
11598 does what @samp{CALL FLUSH} does,
11599 but that supports @samp{*} as the unit designator (same unit as for
11600 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11603 @node Expressions in FORMAT Statements
11604 @subsection Expressions in @code{FORMAT} Statements
11605 @cindex FORMAT statement
11606 @cindex statements, FORMAT
11608 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11609 Supporting this requires a significant redesign or replacement
11612 However, @code{g77} does support
11613 this construct when the expression is constant
11614 (as of version 0.5.22).
11618 PARAMETER (IWIDTH = 12)
11619 10 FORMAT (I<IWIDTH>)
11622 Otherwise, at least for output (@code{PRINT} and
11623 @code{WRITE}), Fortran code making use of this feature can
11624 be rewritten to avoid it by constructing the @code{FORMAT}
11625 string in a @code{CHARACTER} variable or array, then
11626 using that variable or array in place of the @code{FORMAT}
11627 statement label to do the original @code{PRINT} or @code{WRITE}.
11629 Many uses of this feature on input can be rewritten this way
11630 as well, but not all can.
11631 For example, this can be rewritten:
11638 However, this cannot, in general, be rewritten, especially
11639 when @code{ERR=} and @code{END=} constructs are employed:
11646 @node Explicit Assembler Code
11647 @subsection Explicit Assembler Code
11649 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11650 code to specify explicit assembler code.
11652 @node Q Edit Descriptor
11653 @subsection Q Edit Descriptor
11654 @cindex FORMAT statement
11655 @cindex Q edit descriptor
11657 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11658 (This is meant to get the number of characters remaining in an input record.)
11659 Supporting this requires a significant redesign or replacement
11662 A workaround might be using internal I/O or the stream-based intrinsics.
11663 @xref{FGetC Intrinsic (subroutine)}.
11665 @node Old-style PARAMETER Statements
11666 @subsection Old-style PARAMETER Statements
11667 @cindex PARAMETER statement
11668 @cindex statements, PARAMETER
11670 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11671 Supporting this obsolete form of
11672 the @code{PARAMETER} statement would not be particularly hard, as most of the
11673 parsing code is already in place and working.
11675 Until time/money is
11676 spent implementing it, you might as well fix your code to use the
11677 standard form, @samp{PARAMETER (I=1)} (possibly needing
11678 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11679 otherwise, in the obsolete form of @code{PARAMETER}, the
11680 type of the variable is set from the type of the constant being
11683 @node TYPE and ACCEPT I/O Statements
11684 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11685 @cindex TYPE statement
11686 @cindex statements, TYPE
11687 @cindex ACCEPT statement
11688 @cindex statements, ACCEPT
11690 @code{g77} doesn't support the I/O statements @code{TYPE} and
11692 These are common extensions that should be easy to support,
11693 but also are fairly easy to work around in user code.
11695 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11696 by @samp{PRINT fmt,list}.
11697 And, any @samp{ACCEPT fmt,list} statement can be
11698 replaced by @samp{READ fmt,list}.
11700 @node STRUCTURE UNION RECORD MAP
11701 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11702 @cindex STRUCTURE statement
11703 @cindex statements, STRUCTURE
11704 @cindex UNION statement
11705 @cindex statements, UNION
11706 @cindex RECORD statement
11707 @cindex statements, RECORD
11708 @cindex MAP statement
11709 @cindex statements, MAP
11711 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11713 This set of extensions is quite a bit
11714 lower on the list of large, important things to add to @code{g77}, partly
11715 because it requires a great deal of work either upgrading or
11716 replacing @code{libg2c}.
11718 @node OPEN CLOSE and INQUIRE Keywords
11719 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11720 @cindex disposition of files
11721 @cindex OPEN statement
11722 @cindex statements, OPEN
11723 @cindex CLOSE statement
11724 @cindex statements, CLOSE
11725 @cindex INQUIRE statement
11726 @cindex statements, INQUIRE
11728 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11729 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11730 These extensions are easy to add to @code{g77} itself, but
11731 require much more work on @code{libg2c}.
11733 @node ENCODE and DECODE
11734 @subsection @code{ENCODE} and @code{DECODE}
11735 @cindex ENCODE statement
11736 @cindex statements, ENCODE
11737 @cindex DECODE statement
11738 @cindex statements, DECODE
11740 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11742 These statements are best replaced by READ and WRITE statements
11743 involving internal files (CHARACTER variables and arrays).
11745 For example, replace a code fragment like
11750 DECODE (80, 9000, LINE) A, B, C
11752 9000 FORMAT (1X, 3(F10.5))
11761 READ (UNIT=LINE, FMT=9000) A, B, C
11763 9000 FORMAT (1X, 3(F10.5))
11766 Similarly, replace a code fragment like
11771 ENCODE (80, 9000, LINE) A, B, C
11773 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11782 WRITE (UNIT=LINE, FMT=9000) A, B, C
11784 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11787 It is entirely possible that @code{ENCODE} and @code{DECODE} will
11788 be supported by a future version of @code{g77}.
11790 @node Suppressing Space Padding
11791 @subsection Suppressing Space Padding of Source Lines
11793 @code{g77} should offer VXT-Fortran-style suppression of virtual
11794 spaces at the end of a source line
11795 if an appropriate command-line option is specified.
11797 This affects cases where
11798 a character constant is continued onto the next line in a fixed-form
11799 source file, as in the following example:
11802 10 PRINT *,'HOW MANY
11807 @code{g77}, and many other compilers, virtually extend
11808 the continued line through column 72 with spaces that become part
11809 of the character constant, but Digital Fortran normally didn't,
11810 leaving only one space between @samp{MANY} and @samp{SPACES?}
11811 in the output of the above statement.
11813 Fairly recently, at least one version of Digital Fortran
11814 was enhanced to provide the other behavior when a
11815 command-line option is specified, apparently due to demand
11816 from readers of the USENET group @file{comp.lang.fortran}
11817 to offer conformance to this widespread practice in the
11819 @code{g77} should return the favor by offering conformance
11820 to Digital's approach to handling the above example.
11822 @node Fortran Preprocessor
11823 @subsection Fortran Preprocessor
11825 @code{g77} should offer a preprocessor designed specifically
11826 for Fortran to replace @samp{cpp -traditional}.
11827 There are several out there worth evaluating, at least.
11829 Such a preprocessor would recognize Hollerith constants,
11830 properly parse comments and character constants, and so on.
11831 It might also recognize, process, and thus preprocess
11832 files included via the @code{INCLUDE} directive.
11834 @node Bit Operations on Floating-point Data
11835 @subsection Bit Operations on Floating-point Data
11836 @cindex AND intrinsic
11837 @cindex intrinsics, AND
11838 @cindex OR intrinsic
11839 @cindex intrinsics, OR
11840 @cindex SHIFT intrinsic
11841 @cindex intrinsics, SHIFT
11843 @code{g77} does not allow @code{REAL} and other non-integral types for
11844 arguments to intrinsics like @code{AND}, @code{OR}, and @code{SHIFT}.
11846 For example, this program is rejected by @code{g77}, because
11847 the intrinsic @code{IAND} does not accept @code{REAL} arguments:
11850 DATA A/7.54/, B/9.112/
11851 PRINT *, IAND(A, B)
11855 @node POSIX Standard
11856 @subsection @code{POSIX} Standard
11858 @code{g77} should support the POSIX standard for Fortran.
11860 @node Floating-point Exception Handling
11861 @subsection Floating-point Exception Handling
11862 @cindex floating point exceptions
11863 @cindex exceptions, floating point
11864 @cindex FPE handling
11867 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
11868 control over whether or not floating-point exceptions are trapped or
11870 (Ignoring them typically results in NaN values being
11871 propagated in systems that conform to IEEE 754.)
11872 The behaviour is inherited from the system-dependent startup code.
11874 Most systems provide some C-callable mechanism to change this; this can
11875 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
11876 For example, just compiling and linking the following C code with your
11877 program will turn on exception trapping for the ``common'' exceptions
11878 on an x86-based GNU system:
11881 #include <fpu_control.h>
11882 void __attribute__ ((constructor))
11884 (void) __setfpucw (_FPU_DEFAULT &
11885 ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
11889 @node Nonportable Conversions
11890 @subsection Nonportable Conversions
11891 @cindex nonportable conversions
11892 @cindex conversions, nonportable
11894 @code{g77} doesn't accept some particularly nonportable,
11895 silent data-type conversions such as @code{LOGICAL}
11896 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
11897 is type @code{REAL}), that other compilers might
11900 Some of these conversions are accepted by @code{g77}
11901 when the @samp{-fugly} option is specified.
11902 Perhaps it should accept more or all of them.
11904 @node Large Automatic Arrays
11905 @subsection Large Automatic Arrays
11906 @cindex automatic arrays
11907 @cindex arrays, automatic
11909 Currently, automatic arrays always are allocated on the stack.
11910 For situations where the stack cannot be made large enough,
11911 @code{g77} should offer a compiler option that specifies
11912 allocation of automatic arrays in heap storage.
11914 @node Support for Threads
11915 @subsection Support for Threads
11917 @cindex parallel processing
11919 Neither the code produced by @code{g77} nor the @code{libg2c} library
11920 are thread-safe, nor does @code{g77} have support for parallel processing
11921 (other than the instruction-level parallelism available on some
11923 A package such as PVM might help here.
11925 @node Gracefully Handle Sensible Bad Code
11926 @subsection Gracefully Handle Sensible Bad Code
11928 @code{g77} generally should continue processing for
11929 warnings and recoverable (user) errors whenever possible---that
11930 is, it shouldn't gratuitously make bad or useless code.
11941 When compiling the above with @samp{-ff2c-intrinsics-disable},
11942 @code{g77} should indeed complain about passing @code{ZABS},
11943 but it still should compile, instead of rejecting
11944 the entire @code{CALL} statement.
11945 (Some of this is related to improving
11946 the compiler internals to improve how statements are analyzed.)
11948 @node Non-standard Conversions
11949 @subsection Non-standard Conversions
11951 @samp{-Wconversion} and related should flag places where non-standard
11952 conversions are found.
11953 Perhaps much of this would be part of @samp{-Wugly*}.
11955 @node Non-standard Intrinsics
11956 @subsection Non-standard Intrinsics
11958 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
11959 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
11960 This would help find code that might fail silently when ported to another
11963 @node Modifying DO Variable
11964 @subsection Modifying @code{DO} Variable
11966 @code{g77} should warn about modifying @code{DO} variables
11967 via @code{EQUIVALENCE}.
11968 (The internal information gathered to produce this warning
11969 might also be useful in setting the
11970 internal ``doiter'' flag for a variable or even array
11971 reference within a loop, since that might produce faster code someday.)
11973 For example, this code is invalid, so @code{g77} should warn about
11974 the invalid assignment to @samp{NOTHER}:
11977 EQUIVALENCE (I, NOTHER)
11979 IF (I.EQ. 10) NOTHER = 20
11983 @node Better Pedantic Compilation
11984 @subsection Better Pedantic Compilation
11986 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
11987 and use it only to generate
11988 warnings instead of rejecting constructs outright.
11990 if a variable that dimensions an array is not a dummy or placed
11991 explicitly in @code{COMMON} (F77 does not allow it to be
11992 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
11993 follow statement-function-definition statements; about all sorts of
11994 syntactic extensions.
11996 @node Warn About Implicit Conversions
11997 @subsection Warn About Implicit Conversions
11999 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
12000 to expect automatic, silent, and
12001 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
12002 constants to @code{REAL(KIND=2)} based on context.
12004 For example, it would warn about cases like this:
12007 DOUBLE PRECISION FOO
12008 PARAMETER (TZPHI = 9.435784839284958)
12012 @node Invalid Use of Hollerith Constant
12013 @subsection Invalid Use of Hollerith Constant
12015 @code{g77} should disallow statements like @samp{RETURN 2HAB},
12016 which are invalid in both source forms
12017 (unlike @samp{RETURN (2HAB)},
12018 which probably still makes no sense but at least can
12019 be reliably parsed).
12020 Fixed-form processing rejects it, but not free-form, except
12021 in a way that is a bit difficult to understand.
12023 @node Dummy Array Without Dimensioning Dummy
12024 @subsection Dummy Array Without Dimensioning Dummy
12026 @code{g77} should complain when a list of dummy arguments containing an
12027 adjustable dummy array does
12028 not also contain every variable listed in the dimension list of the
12031 Currently, @code{g77} does complain about a variable that
12032 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
12033 area, but this needs to be extended to catch cases where it doesn't appear in
12034 every dummy list that also lists any arrays it dimensions.
12036 For example, @code{g77} should warn about the entry point @samp{ALT}
12037 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
12041 SUBROUTINE PRIMARY(ARRAY, ISIZE)
12046 @node Invalid FORMAT Specifiers
12047 @subsection Invalid FORMAT Specifiers
12049 @code{g77} should check @code{FORMAT} specifiers for validity
12050 as it does @code{FORMAT} statements.
12052 For example, a diagnostic would be produced for:
12055 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
12058 @node Ambiguous Dialects
12059 @subsection Ambiguous Dialects
12061 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
12062 @samp{-Wvxt}, @samp{-Wf90}, and so on.
12063 These would warn about places in the user's source where ambiguities
12064 are found, helpful in resolving ambiguities in the program's
12065 dialect or dialects.
12067 @node Unused Labels
12068 @subsection Unused Labels
12070 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
12072 @node Informational Messages
12073 @subsection Informational Messages
12075 @code{g77} needs an option to suppress information messages (notes).
12076 @samp{-w} does this but also suppresses warnings.
12077 The default should be to suppress info messages.
12079 Perhaps info messages should simply be eliminated.
12081 @node Uninitialized Variables at Run Time
12082 @subsection Uninitialized Variables at Run Time
12084 @code{g77} needs an option to initialize everything (not otherwise
12085 explicitly initialized) to ``weird''
12086 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
12087 largest-magnitude integers, would help track down references to
12088 some kinds of uninitialized variables at run time.
12090 Note that use of the options @samp{-O -Wuninitialized} can catch
12091 many such bugs at compile time.
12093 @node Bounds Checking at Run Time
12094 @subsection Bounds Checking at Run Time
12096 @code{g77} should offer run-time bounds-checking of array/subscript references
12097 in a fashion similar to @code{f2c}.
12099 Note that @code{g77} already warns about references to out-of-bounds
12100 elements of arrays when it detects these at compile time.
12102 @node Labels Visible to Debugger
12103 @subsection Labels Visible to Debugger
12105 @code{g77} should output debugging information for statements labels,
12106 for use by debuggers that know how to support them.
12107 Same with weirder things like construct names.
12108 It is not yet known if any debug formats or debuggers support these.
12110 @node Disappointments
12111 @section Disappointments and Misunderstandings
12113 These problems are perhaps regrettable, but we don't know any practical
12114 way around them for now.
12117 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
12118 external name @samp{foo_}.
12119 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
12120 and @samp{SUBROUTINE FOO}.
12121 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
12124 @node Mangling of Names
12125 @subsection Mangling of Names in Source Code
12126 @cindex naming issues
12127 @cindex external names
12128 @cindex common blocks
12130 @cindex underscores
12132 The current external-interface design, which includes naming of
12133 external procedures, COMMON blocks, and the library interface,
12134 has various usability problems, including things like adding
12135 underscores where not really necessary (and preventing easier
12136 inter-language operability) and yet not providing complete
12137 namespace freedom for user C code linked with Fortran apps (due
12138 to the naming of functions in the library, among other things).
12140 Project GNU should at least get all this ``right'' for systems
12141 it fully controls, such as the Hurd, and provide defaults and
12142 options for compatibility with existing systems and interoperability
12143 with popular existing compilers.
12145 @node Multiple Definitions of External Names
12146 @subsection Multiple Definitions of External Names
12148 @cindex BLOCK DATA statement
12149 @cindex statements, BLOCK DATA
12150 @cindex COMMON statement
12151 @cindex statements, COMMON
12152 @cindex naming conflicts
12154 @code{g77} doesn't allow a common block and an external procedure or
12155 @code{BLOCK DATA} to have the same name.
12156 Some systems allow this, but @code{g77} does not,
12157 to be compatible with @code{f2c}.
12159 @code{g77} could special-case the way it handles
12160 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12161 particular area (necessarily, since @code{g77} offers an
12162 important feature here), but
12163 it is likely that such special-casing would be very annoying to people
12164 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12165 @samp{FOO} in the same program unit, to refer to external procedures, since
12166 the result would be that @code{g77} would treat these references as requests to
12167 force-load BLOCK DATA program units.
12169 In that case, if @code{g77} modified
12170 names of @code{BLOCK DATA} so they could have the same names as
12171 @code{COMMON}, users
12172 would find that their programs wouldn't link because the @samp{FOO} procedure
12173 didn't have its name translated the same way.
12175 (Strictly speaking,
12176 @code{g77} could emit a null-but-externally-satisfying definition of
12177 @samp{FOO} with its name transformed as if it had been a
12178 @code{BLOCK DATA}, but that probably invites more trouble than it's
12181 @node Limitation on Implicit Declarations
12182 @subsection Limitation on Implicit Declarations
12183 @cindex IMPLICIT CHARACTER*(*) statement
12184 @cindex statements, IMPLICIT CHARACTER*(*)
12186 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12187 This is not standard-conforming.
12190 @section Certain Changes We Don't Want to Make
12192 This section lists changes that people frequently request, but which
12193 we do not make because we think GNU Fortran is better without them.
12196 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12197 is one, not two, characters long.
12198 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12200 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12201 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12202 single-precision constant,
12203 and might be interpreted as
12204 @samp{9.435785} or similar.
12205 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12206 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12207 not behave as expected.
12210 @node Backslash in Constants
12211 @subsection Backslash in Constants
12213 @cindex f77 support
12214 @cindex support, f77
12216 In the opinion of many experienced Fortran users,
12217 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12218 as currently set by @code{g77}.
12220 First of all, you can always specify
12221 @samp{-fno-backslash} to turn off this processing.
12223 Despite not being within the spirit (though apparently within the
12224 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12225 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12226 default to, and apparently lots of code depends on this feature.
12228 This is a particularly troubling issue.
12229 The use of a C construct in the midst of Fortran code
12230 is bad enough, worse when it makes existing Fortran
12231 programs stop working (as happens when programs written
12232 for non-UNIX systems are ported to UNIX systems with
12233 compilers that provide the @samp{-fbackslash} feature
12234 as the default---sometimes with no option to turn it off).
12236 The author of GNU Fortran wished, for reasons of linguistic
12237 purity, to make @samp{-fno-backslash} the default for GNU
12238 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12239 to specify @samp{-fbackslash} to get the UNIX behavior.
12241 However, the realization that @code{g77} is intended as
12242 a replacement for @emph{UNIX} @code{f77}, caused the author
12243 to choose to make @code{g77} as compatible with
12244 @code{f77} as feasible, which meant making @samp{-fbackslash}
12247 The primary focus on compatibility is at the source-code
12248 level, and the question became ``What will users expect
12249 a replacement for @code{f77} to do, by default?''
12250 Although at least one UNIX @code{f77} does not provide
12251 @samp{-fbackslash} as a default, it appears that
12252 the majority of them do, which suggests that
12253 the majority of code that is compiled by UNIX @code{f77}
12254 compilers expects @samp{-fbackslash} to be the default.
12256 It is probably the case that more code exists
12257 that would @emph{not} work with @samp{-fbackslash}
12258 in force than code that requires it be in force.
12260 However, most of @emph{that} code is not being compiled
12262 and when it is, new build procedures (shell scripts,
12263 makefiles, and so on) must be set up anyway so that
12264 they work under UNIX.
12265 That makes a much more natural and safe opportunity for
12266 non-UNIX users to adapt their build procedures for
12267 @code{g77}'s default of @samp{-fbackslash} than would
12268 exist for the majority of UNIX @code{f77} users who
12269 would have to modify existing, working build procedures
12270 to explicitly specify @samp{-fbackslash} if that was
12273 One suggestion has been to configure the default for
12274 @samp{-fbackslash} (and perhaps other options as well)
12275 based on the configuration of @code{g77}.
12277 This is technically quite straightforward, but will be avoided
12278 even in cases where not configuring defaults to be
12279 dependent on a particular configuration greatly inconveniences
12280 some users of legacy code.
12282 Many users appreciate the GNU compilers because they provide an
12283 environment that is uniform across machines.
12284 These users would be
12285 inconvenienced if the compiler treated things like the
12286 format of the source code differently on certain machines.
12288 Occasionally users write programs intended only for a particular machine
12290 On these occasions, the users would benefit if the GNU Fortran compiler
12291 were to support by default the same dialect as the other compilers on
12293 But such applications are rare.
12294 And users writing a
12295 program to run on more than one type of machine cannot possibly benefit
12296 from this kind of compatibility.
12297 (This is consistent with the design goals for @code{gcc}.
12298 To change them for @code{g77}, you must first change them
12300 Do not ask the maintainers of @code{g77} to do this for you,
12301 or to disassociate @code{g77} from the widely understood, if
12302 not widely agreed-upon, goals for GNU compilers in general.)
12304 This is why GNU Fortran does and will treat backslashes in the same
12305 fashion on all types of machines (by default).
12306 @xref{Direction of Language Development}, for more information on
12307 this overall philosophy guiding the development of the GNU Fortran
12310 Of course, users strongly concerned about portability should indicate
12311 explicitly in their build procedures which options are expected
12312 by their source code, or write source code that has as few such
12313 expectations as possible.
12315 For example, avoid writing code that depends on backslash (@samp{\})
12316 being interpreted either way in particular, such as by
12317 starting a program unit with:
12321 PARAMETER (BACKSL = '\\')
12325 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12327 In this way, users can write programs which have the same meaning
12328 in many Fortran dialects.
12330 (However, this technique does not work for Hollerith constants---which
12331 is just as well, since the only generally portable uses for Hollerith
12332 constants are in places where character constants can and should
12333 be used instead, for readability.)
12335 @node Initializing Before Specifying
12336 @subsection Initializing Before Specifying
12337 @cindex initialization, statement placement
12338 @cindex placing initialization statements
12340 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12341 source code before @samp{COMMON VAR},
12342 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12343 In general, @code{g77} requires initialization of a variable
12344 or array to be specified @emph{after} all other specifications
12345 of attributes (type, size, placement, and so on) of that variable
12346 or array are specified (though @emph{confirmation} of data type is
12349 It is @emph{possible} @code{g77} will someday allow all of this,
12350 even though it is not allowed by the FORTRAN 77 standard.
12352 Then again, maybe it is better to have
12353 @code{g77} always require placement of @code{DATA}
12354 so that it can possibly immediately write constants
12355 to the output file, thus saving time and space.
12357 That is, @samp{DATA A/1000000*1/} should perhaps always
12358 be immediately writable to canonical assembler, unless it's already known
12359 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12360 and to do this it cannot be followed by @samp{COMMON A}.
12362 @node Context-Sensitive Intrinsicness
12363 @subsection Context-Sensitive Intrinsicness
12364 @cindex intrinsics, context-sensitive
12365 @cindex context-sensitive intrinsics
12367 @code{g77} treats procedure references to @emph{possible} intrinsic
12368 names as always enabling their intrinsic nature, regardless of
12369 whether the @emph{form} of the reference is valid for that
12372 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12373 an invalid reference to the @code{SQRT} intrinsic function,
12374 because the reference is a subroutine invocation.
12376 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12377 as a reference to a @emph{procedure} named @samp{SQRT}, not
12378 to a @emph{variable} with that name (as it would for a statement
12379 such as @samp{V = SQRT}).
12381 Next, @code{g77} establishes that, in the program unit being compiled,
12382 @code{SQRT} is an intrinsic---not a subroutine that
12383 happens to have the same name as an intrinsic (as would be
12384 the case if, for example, @samp{EXTERNAL SQRT} was present).
12386 Finally, @code{g77} recognizes that the @emph{form} of the
12387 reference is invalid for that particular intrinsic.
12388 That is, it recognizes that it is invalid for an intrinsic
12389 @emph{function}, such as @code{SQRT}, to be invoked as
12390 a @emph{subroutine}.
12392 At that point, @code{g77} issues a diagnostic.
12394 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12395 references an external subroutine of their own, not an
12396 intrinsic function.
12398 However, @code{g77} knows about intrinsic
12399 subroutines, not just functions, and is able to support both having
12400 the same names, for example.
12402 As a result of this, @code{g77} rejects calls
12403 to intrinsics that are not subroutines, and function invocations
12404 of intrinsics that are not functions, just as it (and most compilers)
12405 rejects invocations of intrinsics with the wrong number (or types)
12408 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12409 a user-written subroutine named @samp{SQRT}.
12411 @node Context-Sensitive Constants
12412 @subsection Context-Sensitive Constants
12413 @cindex constants, context-sensitive
12414 @cindex context-sensitive constants
12416 @code{g77} does not use context to determine the types of
12417 constants or named constants (@code{PARAMETER}), except
12418 for (non-standard) typeless constants such as @samp{'123'O}.
12420 For example, consider the following statement:
12423 PRINT *, 9.435784839284958 * 2D0
12427 @code{g77} will interpret the (truncated) constant
12428 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12429 constant, because the suffix @code{D0} is not specified.
12431 As a result, the output of the above statement when
12432 compiled by @code{g77} will appear to have ``less precision''
12433 than when compiled by other compilers.
12435 In these and other cases, some compilers detect the
12436 fact that a single-precision constant is used in
12437 a double-precision context and therefore interpret the
12438 single-precision constant as if it was @emph{explicitly}
12439 specified as a double-precision constant.
12440 (This has the effect of appending @emph{decimal}, not
12441 @emph{binary}, zeros to the fractional part of the
12442 number---producing different computational results.)
12444 The reason this misfeature is dangerous is that a slight,
12445 apparently innocuous change to the source code can change
12446 the computational results.
12451 DOUBLE PRECISION FIVE
12452 PARAMETER (ALMOST = 5.000000000001)
12454 CLOSE = 5.000000000001
12455 PRINT *, 5.000000000001 - FIVE
12456 PRINT *, ALMOST - FIVE
12457 PRINT *, CLOSE - FIVE
12462 Running the above program should
12463 result in the same value being
12464 printed three times.
12465 With @code{g77} as the compiler,
12468 However, compiled by many other compilers,
12469 running the above program would print
12470 two or three distinct values, because
12471 in two or three of the statements, the
12472 constant @samp{5.000000000001}, which
12473 on most systems is exactly equal to @samp{5.}
12474 when interpreted as a single-precision constant,
12475 is instead interpreted as a double-precision
12476 constant, preserving the represented
12478 However, this ``clever'' promotion of
12479 type does not extend to variables or,
12480 in some compilers, to named constants.
12482 Since programmers often are encouraged to replace manifest
12483 constants or permanently-assigned variables with named
12484 constants (@code{PARAMETER} in Fortran), and might need
12485 to replace some constants with variables having the same
12486 values for pertinent portions of code,
12487 it is important that compilers treat code so modified in the
12488 same way so that the results of such programs are the same.
12489 @code{g77} helps in this regard by treating constants just
12490 the same as variables in terms of determining their types
12491 in a context-independent way.
12493 Still, there is a lot of existing Fortran code that has
12494 been written to depend on the way other compilers freely
12495 interpret constants' types based on context, so anything
12496 @code{g77} can do to help flag cases of this in such code
12497 could be very helpful.
12499 @node Equivalence Versus Equality
12500 @subsection Equivalence Versus Equality
12501 @cindex .EQV., with integer operands
12502 @cindex comparing logical expressions
12503 @cindex logical expressions, comparing
12505 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12506 is not supported, except via @samp{-fugly}, which is not
12507 recommended except for legacy code (where the behavior expected
12508 by the @emph{code} is assumed).
12510 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12511 and @code{.NEQV.} instead, as these are permitted by the various
12514 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12515 to work if either of its operands is @code{LOGICAL}.
12517 The problem with supporting this ``feature'' is that there is
12518 unlikely to be consensus on how it works, as illustrated by the
12519 following sample program:
12523 DATA L,M,N /3*.FALSE./
12524 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
12528 The issue raised by the above sample program is: what is the
12529 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
12530 @code{LOGICAL} operands?
12532 Some programmers will argue that it is the same as the precedence
12533 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
12535 By this interpretation, the subexpression @samp{M.EQ.N} must be
12536 evaluated first in the above program, resulting in a program that,
12537 when run, does not execute the @code{PRINT} statement.
12539 Other programmers will argue that the precedence is the same as
12540 the precedence for @code{.EQV.}, which is restricted by the standards
12541 to @code{LOGICAL} operands.
12542 By this interpretation, the subexpression @samp{L.AND.M} must be
12543 evaluated first, resulting in a program that @emph{does} execute
12544 the @code{PRINT} statement.
12546 Assigning arbitrary semantic interpretations to syntactic expressions
12547 that might legitimately have more than one ``obvious'' interpretation
12548 is generally unwise.
12550 The creators of the various Fortran standards have done a good job
12551 in this case, requiring a distinct set of operators (which have their
12552 own distinct precedence) to compare @code{LOGICAL} operands.
12553 This requirement results in expression syntax with more certain
12554 precedence (without requiring substantial context), making it easier
12555 for programmers to read existing code.
12556 @code{g77} will avoid muddying up elements of the Fortran language
12557 that were well-designed in the first place.
12559 (Ask C programmers about the precedence of expressions such as
12560 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
12561 you, without knowing more context, whether the @samp{&} and @samp{-}
12562 operators are infix (binary) or unary!)
12564 @node Order of Side Effects
12565 @subsection Order of Side Effects
12566 @cindex side effects, order of evaluation
12567 @cindex order of evaluation, side effects
12569 @code{g77} does not necessarily produce code that, when run, performs
12570 side effects (such as those performed by function invocations)
12571 in the same order as in some other compiler---or even in the same
12572 order as another version, port, or invocation (using different
12573 command-line options) of @code{g77}.
12575 It is never safe to depend on the order of evaluation of side effects.
12576 For example, an expression like this may very well behave differently
12577 from one compiler to another:
12580 J = IFUNC() - IFUNC()
12584 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
12586 Either invocation might happen first.
12587 If @samp{IFUNC} returns 5 the first time it is invoked, and
12588 returns 12 the second time, @samp{J} might end up with the
12589 value @samp{7}, or it might end up with @samp{-7}.
12591 Generally, in Fortran, procedures with side-effects intended to
12592 be visible to the caller are best designed as @emph{subroutines},
12594 Examples of such side-effects include:
12598 The generation of random numbers
12599 that are intended to influence return values.
12603 (other than internal I/O to local variables).
12606 Updating information in common blocks.
12609 An example of a side-effect that is not intended to be visible
12610 to the caller is a function that maintains a cache of recently
12611 calculated results, intended solely to speed repeated invocations
12612 of the function with identical arguments.
12613 Such a function can be safely used in expressions, because
12614 if the compiler optimizes away one or more calls to the
12615 function, operation of the program is unaffected (aside
12616 from being speeded up).
12618 @node Warnings and Errors
12619 @section Warning Messages and Error Messages
12621 @cindex error messages
12622 @cindex warnings vs errors
12623 @cindex messages, warning and error
12624 The GNU compiler can produce two kinds of diagnostics: errors and
12626 Each kind has a different purpose:
12630 @emph{Errors} report problems that make it impossible to compile your
12632 GNU Fortran reports errors with the source file name, line
12633 number, and column within the line where the problem is apparent.
12636 @emph{Warnings} report other unusual conditions in your code that
12637 @emph{might} indicate a problem, although compilation can (and does)
12639 Warning messages also report the source file name, line number,
12640 and column information,
12641 but include the text @samp{warning:} to distinguish them
12642 from error messages.
12645 Warnings might indicate danger points where you should check to make sure
12646 that your program really does what you intend; or the use of obsolete
12647 features; or the use of nonstandard features of GNU Fortran.
12648 Many warnings are issued only if you ask for them, with one of the
12649 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
12652 @emph{Note:} Currently, the text of the line and a pointer to the column
12653 is printed in most @code{g77} diagnostics.
12654 Probably, as of version 0.6, @code{g77} will
12655 no longer print the text of the source line, instead printing
12656 the column number following the file name and line number in
12657 a form that GNU Emacs recognizes.
12658 This change is expected to speed up and reduce the memory usage
12659 of the @code{g77} compiler.
12661 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
12663 @c GNU Fortran always tries to compile your program if possible; it never
12664 @c gratuitously rejects a program whose meaning is clear merely because
12665 @c (for instance) it fails to conform to a standard. In some cases,
12666 @c however, the Fortran standard specifies that certain extensions are
12667 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
12668 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
12669 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
12670 @c This does not mean that @emph{all} non-ANSI constructs get warnings
12673 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
12674 more detail on these and related command-line options.
12676 @node Open Questions
12677 @chapter Open Questions
12679 Please consider offering useful answers to these questions!
12683 @code{LOC()} and other intrinsics are probably somewhat misclassified.
12684 Is the a need for more precise classification of intrinsics, and if so,
12685 what are the appropriate groupings?
12686 Is there a need to individually
12687 enable/disable/delete/hide intrinsics from the command line?
12691 @chapter Reporting Bugs
12693 @cindex reporting bugs
12695 Your bug reports play an essential role in making GNU Fortran reliable.
12697 When you encounter a problem, the first thing to do is to see if it is
12700 If it isn't known, then you should report the problem.
12702 Reporting a bug might help you by bringing a solution to your problem, or
12704 (If it does not, look in the service directory; see
12706 In any case, the principal function of a bug report is
12707 to help the entire community by making the next version of GNU Fortran work
12709 Bug reports are your contribution to the maintenance of GNU Fortran.
12711 Since the maintainers are very overloaded, we cannot respond to every
12713 However, if the bug has not been fixed, we are likely to
12714 send you a patch and ask you to tell us whether it works.
12716 In order for a bug report to serve its purpose, you must include the
12717 information that makes for fixing the bug.
12720 * Criteria: Bug Criteria. Have you really found a bug?
12721 * Where: Bug Lists. Where to send your bug report.
12722 * Reporting: Bug Reporting. How to report a bug effectively.
12723 * Patches: Sending Patches. How to send a patch for GNU Fortran.
12726 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
12727 for information on problems we already know about.
12729 @xref{Service,,How To Get Help with GNU Fortran},
12730 for information on where to ask for help.
12733 @section Have You Found a Bug?
12734 @cindex bug criteria
12736 If you are not sure whether you have found a bug, here are some guidelines:
12739 @cindex fatal signal
12742 If the compiler gets a fatal signal, for any input whatever, that is a
12744 Reliable compilers never crash---they just remain obsolete.
12746 @cindex invalid assembly code
12747 @cindex assembly code, invalid
12749 If the compiler produces invalid assembly code, for any input whatever,
12750 @c (except an @code{asm} statement),
12751 that is a compiler bug, unless the
12752 compiler reports errors (not just warnings) which would ordinarily
12753 prevent the assembler from being run.
12755 @cindex undefined behavior
12756 @cindex undefined function value
12758 If the compiler produces valid assembly code that does not correctly
12759 execute the input source code, that is a compiler bug.
12761 However, you must double-check to make sure, because you might have run
12762 into an incompatibility between GNU Fortran and traditional Fortran.
12763 @c (@pxref{Incompatibilities}).
12764 These incompatibilities might be considered
12765 bugs, but they are inescapable consequences of valuable features.
12767 Or you might have a program whose behavior is undefined, which happened
12768 by chance to give the desired results with another Fortran compiler.
12769 It is best to check the relevant Fortran standard thoroughly if
12770 it is possible that the program indeed does something undefined.
12772 After you have localized the error to a single source line, it should
12773 be easy to check for these things.
12774 If your program is correct and well defined, you have found
12777 It might help if, in your submission, you identified the specific
12778 language in the relevant Fortran standard that specifies the
12779 desired behavior, if it isn't likely to be obvious and agreed-upon
12780 by all Fortran users.
12783 If the compiler produces an error message for valid input, that is a
12786 @cindex invalid input
12788 If the compiler does not produce an error message for invalid input,
12789 that is a compiler bug.
12790 However, you should note that your idea of
12791 ``invalid input'' might be someone else's idea
12792 of ``an extension'' or ``support for traditional practice''.
12795 If you are an experienced user of Fortran compilers, your suggestions
12796 for improvement of GNU Fortran are welcome in any case.
12799 Many, perhaps most, bug reports against @code{g77} turn out to
12800 be bugs in the user's code.
12801 While we find such bug reports educational, they sometimes take
12802 a considerable amount of time to track down or at least respond
12803 to---time we could be spending making @code{g77}, not some user's
12806 Some steps you can take to verify that the bug is not certainly
12807 in the code you're compiling with @code{g77}:
12811 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
12812 These options enable many useful warning; the @samp{-O} option
12813 enables flow analysis that enables the uninitialized-variable
12816 If you investigate the warnings and find evidence of possible bugs
12817 in your code, fix them first and retry @code{g77}.
12820 Compile your code using the @code{g77} options @samp{-finit-local-zero},
12821 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
12822 combinations thereof.
12824 If your code works with any of these combinations, that is not
12825 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
12826 by your code might simply be avoided, or have a different, more subtle
12827 effect, when different options are used---but it can be a
12828 strong indicator that your code is making unwarranted assumptions
12829 about the Fortran dialect and/or underlying machine it is
12830 being compiled and run on.
12832 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
12833 for information on the @samp{-fno-automatic} and
12834 @samp{-finit-local-zero} options and how to convert
12835 their use into selective changes in your own code.
12839 Validate your code with @code{ftnchek} or a similar code-checking
12841 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
12842 or @uref{ftp://ftp.dsm.fordham.edu}.
12845 @cindex Makefile example
12846 Here are some sample @file{Makefile} rules using @code{ftnchek}
12847 ``project'' files to do cross-file checking and @code{sfmakedepend}
12848 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
12849 to maintain dependencies automatically.
12850 These assume the use of GNU @code{make}.
12853 # Dummy suffix for ftnchek targets:
12857 # How to compile .f files (for implicit rule):
12859 # Assume `include' directory:
12860 FFLAGS = -Iinclude -g -O -Wall
12862 # Flags for ftnchek:
12863 CHEK1 = -array=0 -include=includes -noarray
12864 CHEK2 = -nonovice -usage=1 -notruncation
12865 CHEKFLAGS = $(CHEK1) $(CHEK2)
12867 # Run ftnchek with all the .prj files except the one corresponding
12868 # to the target's root:
12870 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
12871 -noextern -library $<
12873 # Derive a project file from a source file:
12875 ftnchek $(CHEKFLAGS) -noextern -project -library $<
12877 # The list of objects is assumed to be in variable OBJS.
12878 # Sources corresponding to the objects:
12879 SRCS = $(OBJS:%.o=%.f)
12880 # ftnchek project files:
12881 PRJS = $(OBJS:%.o=%.prj)
12883 # Build the program
12885 $(FC) -o $@ $(OBJS)
12887 chekall: $(PRJS) ; \
12888 ftnchek $(CHEKFLAGS) $(PRJS)
12892 # For Emacs M-x find-tag:
12896 # Rebuild dependencies:
12898 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
12902 Try your code out using other Fortran compilers, such as @code{f2c}.
12903 If it does not work on at least one other compiler (assuming the
12904 compiler supports the features the code needs), that is a strong
12905 indicator of a bug in the code.
12907 However, even if your code works on many compilers @emph{except}
12908 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
12909 It might mean the bug is in your code, and that @code{g77} simply
12910 exposes it more readily than other compilers.
12914 @section Where to Report Bugs
12915 @cindex bug report mailing lists
12916 @kindex @value{email-bugs}
12917 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
12919 Often people think of posting bug reports to a newsgroup instead of
12921 This sometimes appears to work, but it has one problem which can be
12922 crucial: a newsgroup posting does not contain a mail path back to the
12924 Thus, if maintainers need more information, they might be unable
12925 to reach you. For this reason, you should always send bug reports by
12926 mail to the proper mailing list.
12928 As a last resort, send bug reports on paper to:
12932 Free Software Foundation
12933 59 Temple Place - Suite 330
12934 Boston, MA 02111-1307, USA
12937 @node Bug Reporting
12938 @section How to Report Bugs
12939 @cindex compiler bugs, reporting
12941 The fundamental principle of reporting bugs usefully is this:
12942 @strong{report all the facts}.
12943 If you are not sure whether to state a
12944 fact or leave it out, state it!
12946 Often people omit facts because they think they know what causes the
12947 problem and they conclude that some details don't matter.
12949 assume that the name of the variable you use in an example does not matter.
12950 Well, probably it doesn't, but one cannot be sure.
12951 Perhaps the bug is a
12952 stray memory reference which happens to fetch from the location where that
12953 name is stored in memory; perhaps, if the name were different, the contents
12954 of that location would fool the compiler into doing the right thing despite
12956 Play it safe and give a specific, complete example.
12958 easiest thing for you to do, and the most helpful.
12960 Keep in mind that the purpose of a bug report is to enable someone to
12961 fix the bug if it is not known.
12962 It isn't very important what happens if
12963 the bug is already known.
12964 Therefore, always write your bug reports on
12965 the assumption that the bug is not known.
12967 Sometimes people give a few sketchy facts and ask, ``Does this ring a
12969 This cannot help us fix a bug, so it is rarely helpful.
12970 We respond by asking for enough details to enable us to investigate.
12971 You might as well expedite matters by sending them to begin with.
12972 (Besides, there are enough bells ringing around here as it is.)
12974 Try to make your bug report self-contained.
12975 If we have to ask you for
12976 more information, it is best if you include all the previous information
12977 in your response, as well as the information that was missing.
12979 Please report each bug in a separate message.
12980 This makes it easier for
12981 us to track which bugs have been fixed and to forward your bugs reports
12982 to the appropriate maintainer.
12984 Do not compress and encode any part of your bug report using programs
12985 such as @file{uuencode}.
12986 If you do so it will slow down the processing
12988 If you must submit multiple large files, use @file{shar},
12989 which allows us to read your message without having to run any
12990 decompression programs.
12992 (As a special exception for GNU Fortran bug-reporting, at least
12993 for now, if you are sending more than a few lines of code, if
12994 your program's source file format contains ``interesting'' things
12995 like trailing spaces or strange characters, or if you need to
12996 include binary data files, it is acceptable to put all the
12997 files together in a @code{tar} archive, and, whether you need to
12998 do that, it is acceptable to then compress the single file (@code{tar}
12999 archive or source file)
13000 using @code{gzip} and encode it via @code{uuencode}.
13001 Do not use any MIME stuff---the current maintainer can't decode this.
13002 Using @code{compress} instead of @code{gzip} is acceptable, assuming
13003 you have licensed the use of the patented algorithm in
13004 @code{compress} from Unisys.)
13006 To enable someone to investigate the bug, you should include all these
13011 The version of GNU Fortran.
13012 You can get this by running @code{g77} with the @samp{-v} option.
13013 (Ignore any error messages that might be displayed
13014 when the linker is run.)
13016 Without this, we won't know whether there is any point in looking for
13017 the bug in the current version of GNU Fortran.
13020 @cindex preprocessor
13021 @cindex cpp program
13022 @cindex programs, cpp
13023 A complete input file that will reproduce the bug.
13024 If the bug is in the compiler proper (@file{f771}) and
13025 you are using the C preprocessor, run your
13026 source file through the C preprocessor by doing @samp{g77 -E
13027 @var{sourcefile} > @var{outfile}}, then include the contents of
13028 @var{outfile} in the bug report. (When you do this, use the same
13029 @samp{-I}, @samp{-D} or @samp{-U} options that you used in actual
13032 A single statement is not enough of an example.
13033 In order to compile it,
13034 it must be embedded in a complete file of compiler input; and the bug
13035 might depend on the details of how this is done.
13037 Without a real example one can compile, all anyone can do about your bug
13038 report is wish you luck. It would be futile to try to guess how to
13039 provoke the bug. For example, bugs in register allocation and reloading
13040 frequently depend on every little detail of the function they happen in.
13043 @cindex included files
13044 @cindex INCLUDE directive
13045 @cindex directive, INCLUDE
13046 @cindex #include directive
13047 @cindex directive, #include
13048 Note that you should include with your bug report any files
13049 included by the source file
13050 (via the @code{#include} or @code{INCLUDE} directive)
13051 that you send, and any files they include, and so on.
13053 It is not necessary to replace
13054 the @code{#include} and @code{INCLUDE} directives
13055 with the actual files in the version of the source file that
13056 you send, but it might make submitting the bug report easier
13058 However, be sure to @emph{reproduce} the bug using the @emph{exact}
13059 version of the source material you submit, to avoid wild-goose
13063 The command arguments you gave GNU Fortran to compile that example
13064 and observe the bug. For example, did you use @samp{-O}? To guarantee
13065 you won't omit something important, list all the options.
13067 If we were to try to guess the arguments, we would probably guess wrong
13068 and then we would not encounter the bug.
13071 The type of machine you are using, and the operating system name and
13073 (Much of this information is printed by @samp{g77 -v}---if you
13074 include that, send along any additional info you have that you
13075 don't see clearly represented in that output.)
13078 The operands you gave to the @code{configure} command when you installed
13082 A complete list of any modifications you have made to the compiler
13083 source. (We don't promise to investigate the bug unless it happens in
13084 an unmodified compiler. But if you've made modifications and don't tell
13085 us, then you are sending us on a wild-goose chase.)
13087 Be precise about these changes. A description in English is not
13088 enough---send a context diff for them.
13090 Adding files of your own (such as a machine description for a machine we
13091 don't support) is a modification of the compiler source.
13094 Details of any other deviations from the standard procedure for installing
13098 A description of what behavior you observe that you believe is
13099 incorrect. For example, ``The compiler gets a fatal signal,'' or,
13100 ``The assembler instruction at line 208 in the output is incorrect.''
13102 Of course, if the bug is that the compiler gets a fatal signal, then one
13103 can't miss it. But if the bug is incorrect output, the maintainer might
13104 not notice unless it is glaringly wrong. None of us has time to study
13105 all the assembler code from a 50-line Fortran program just on the chance that
13106 one instruction might be wrong. We need @emph{you} to do this part!
13108 Even if the problem you experience is a fatal signal, you should still
13109 say so explicitly. Suppose something strange is going on, such as, your
13110 copy of the compiler is out of synch, or you have encountered a bug in
13111 the C library on your system. (This has happened!) Your copy might
13112 crash and the copy here would not. If you @i{said} to expect a crash,
13113 then when the compiler here fails to crash, we would know that the bug
13114 was not happening. If you don't say to expect a crash, then we would
13115 not know whether the bug was happening. We would not be able to draw
13116 any conclusion from our observations.
13118 If the problem is a diagnostic when building GNU Fortran with some other
13119 compiler, say whether it is a warning or an error.
13121 Often the observed symptom is incorrect output when your program is run.
13122 Sad to say, this is not enough information unless the program is short
13123 and simple. None of us has time to study a large program to figure out
13124 how it would work if compiled correctly, much less which line of it was
13125 compiled wrong. So you will have to do that. Tell us which source line
13126 it is, and what incorrect result happens when that line is executed. A
13127 person who understands the program can find this as easily as finding a
13128 bug in the program itself.
13131 If you send examples of assembler code output from GNU Fortran,
13132 please use @samp{-g} when you make them. The debugging information
13133 includes source line numbers which are essential for correlating the
13134 output with the input.
13137 If you wish to mention something in the GNU Fortran source, refer to it by
13138 context, not by line number.
13140 The line numbers in the development sources don't match those in your
13141 sources. Your line numbers would convey no convenient information to the
13145 Additional information from a debugger might enable someone to find a
13146 problem on a machine which he does not have available. However, you
13147 need to think when you collect this information if you want it to have
13148 any chance of being useful.
13150 @cindex backtrace for bug reports
13151 For example, many people send just a backtrace, but that is never
13152 useful by itself. A simple backtrace with arguments conveys little
13153 about GNU Fortran because the compiler is largely data-driven; the same
13154 functions are called over and over for different RTL insns, doing
13155 different things depending on the details of the insn.
13157 Most of the arguments listed in the backtrace are useless because they
13158 are pointers to RTL list structure. The numeric values of the
13159 pointers, which the debugger prints in the backtrace, have no
13160 significance whatever; all that matters is the contents of the objects
13161 they point to (and most of the contents are other such pointers).
13163 In addition, most compiler passes consist of one or more loops that
13164 scan the RTL insn sequence. The most vital piece of information about
13165 such a loop---which insn it has reached---is usually in a local variable,
13166 not in an argument.
13169 What you need to provide in addition to a backtrace are the values of
13170 the local variables for several stack frames up. When a local
13171 variable or an argument is an RTX, first print its value and then use
13172 the GDB command @code{pr} to print the RTL expression that it points
13173 to. (If GDB doesn't run on your machine, use your debugger to call
13174 the function @code{debug_rtx} with the RTX as an argument.) In
13175 general, whenever a variable is a pointer, its value is no use
13176 without the data it points to.
13179 Here are some things that are not necessary:
13183 A description of the envelope of the bug.
13185 Often people who encounter a bug spend a lot of time investigating
13186 which changes to the input file will make the bug go away and which
13187 changes will not affect it.
13189 This is often time consuming and not very useful, because the way we
13190 will find the bug is by running a single example under the debugger with
13191 breakpoints, not by pure deduction from a series of examples. You might
13192 as well save your time for something else.
13194 Of course, if you can find a simpler example to report @emph{instead} of
13195 the original one, that is a convenience. Errors in the output will be
13196 easier to spot, running under the debugger will take less time, etc.
13197 Most GNU Fortran bugs involve just one function, so the most straightforward
13198 way to simplify an example is to delete all the function definitions
13199 except the one where the bug occurs. Those earlier in the file may be
13200 replaced by external declarations if the crucial function depends on
13201 them. (Exception: inline functions might affect compilation of functions
13202 defined later in the file.)
13204 However, simplification is not vital; if you don't want to do this,
13205 report the bug anyway and send the entire test case you used.
13208 In particular, some people insert conditionals @samp{#ifdef BUG} around
13209 a statement which, if removed, makes the bug not happen. These are just
13210 clutter; we won't pay any attention to them anyway. Besides, you should
13211 send us preprocessor output, and that can't have conditionals.
13214 A patch for the bug.
13216 A patch for the bug is useful if it is a good one. But don't omit the
13217 necessary information, such as the test case, on the assumption that a
13218 patch is all we need. We might see problems with your patch and decide
13219 to fix the problem another way, or we might not understand it at all.
13221 Sometimes with a program as complicated as GNU Fortran it is very hard to
13222 construct an example that will make the program follow a certain path
13223 through the code. If you don't send the example, we won't be able to
13224 construct one, so we won't be able to verify that the bug is fixed.
13226 And if we can't understand what bug you are trying to fix, or why your
13227 patch should be an improvement, we won't install it. A test case will
13228 help us to understand.
13230 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13231 understand and install your patches.
13234 A guess about what the bug is or what it depends on.
13236 Such guesses are usually wrong. Even the maintainer can't guess right
13237 about such things without first using the debugger to find the facts.
13242 We have no way of examining a core dump for your type of machine
13243 unless we have an identical system---and if we do have one,
13244 we should be able to reproduce the crash ourselves.
13247 @node Sending Patches
13248 @section Sending Patches for GNU Fortran
13250 If you would like to write bug fixes or improvements for the GNU Fortran
13251 compiler, that is very helpful.
13252 Send suggested fixes to the bug report
13253 mailing list, @email{@value{email-bugs}}.
13255 Please follow these guidelines so we can study your patches efficiently.
13256 If you don't follow these guidelines, your information might still be
13257 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13258 of work in the best of circumstances, and we can't keep up unless you do
13263 Send an explanation with your changes of what problem they fix or what
13264 improvement they bring about. For a bug fix, just include a copy of the
13265 bug report, and explain why the change fixes the bug.
13267 (Referring to a bug report is not as good as including it, because then
13268 we will have to look it up, and we have probably already deleted it if
13269 we've already fixed the bug.)
13272 Always include a proper bug report for the problem you think you have
13273 fixed. We need to convince ourselves that the change is right before
13274 installing it. Even if it is right, we might have trouble judging it if
13275 we don't have a way to reproduce the problem.
13278 Include all the comments that are appropriate to help people reading the
13279 source in the future understand why this change was needed.
13282 Don't mix together changes made for different reasons.
13283 Send them @emph{individually}.
13285 If you make two changes for separate reasons, then we might not want to
13286 install them both. We might want to install just one. If you send them
13287 all jumbled together in a single set of diffs, we have to do extra work
13288 to disentangle them---to figure out which parts of the change serve
13289 which purpose. If we don't have time for this, we might have to ignore
13290 your changes entirely.
13292 If you send each change as soon as you have written it, with its own
13293 explanation, then the two changes never get tangled up, and we can
13294 consider each one properly without any extra work to disentangle them.
13296 Ideally, each change you send should be impossible to subdivide into
13297 parts that we might want to consider separately, because each of its
13298 parts gets its motivation from the other parts.
13301 Send each change as soon as that change is finished. Sometimes people
13302 think they are helping us by accumulating many changes to send them all
13303 together. As explained above, this is absolutely the worst thing you
13306 Since you should send each change separately, you might as well send it
13307 right away. That gives us the option of installing it immediately if it
13311 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13312 for us to install reliably. More than that, they make it hard for us to
13313 study the diffs to decide whether we want to install them. Unidiff
13314 format is better than contextless diffs, but not as easy to read as
13317 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13318 function that each change occurs in.
13319 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13322 Write the change log entries for your changes. We get lots of changes,
13323 and we don't have time to do all the change log writing ourselves.
13325 Read the @file{ChangeLog} file to see what sorts of information to put
13326 in, and to learn the style that we use. The purpose of the change log
13327 is to show people where to find what was changed. So you need to be
13328 specific about what functions you changed; in large functions, it's
13329 often helpful to indicate where within the function the change was.
13331 On the other hand, once you have shown people where to find the change,
13332 you need not explain its purpose. Thus, if you add a new function, all
13333 you need to say about it is that it is new. If you feel that the
13334 purpose needs explaining, it probably does---but the explanation will be
13335 much more useful if you put it in comments in the code.
13337 If you would like your name to appear in the header line for who made
13338 the change, send us the header line.
13341 When you write the fix, keep in mind that we can't install a change that
13342 would break other systems.
13344 People often suggest fixing a problem by changing machine-independent
13345 files such as @file{toplev.c} to do something special that a particular
13346 system needs. Sometimes it is totally obvious that such changes would
13347 break GNU Fortran for almost all users. We can't possibly make a change like
13348 that. At best it might tell us how to write another patch that would
13349 solve the problem acceptably.
13351 Sometimes people send fixes that @emph{might} be an improvement in
13352 general---but it is hard to be sure of this. It's hard to install
13353 such changes because we have to study them very carefully. Of course,
13354 a good explanation of the reasoning by which you concluded the change
13355 was correct can help convince us.
13357 The safest changes are changes to the configuration files for a
13358 particular machine. These are safe because they can't create new bugs
13361 Please help us keep up with the workload by designing the patch in a
13362 form that is good to install.
13366 @chapter How To Get Help with GNU Fortran
13368 If you need help installing, using or changing GNU Fortran, there are two
13373 Look in the service directory for someone who might help you for a fee.
13374 The service directory is found in the file named @file{SERVICE} in the
13375 GNU CC distribution.
13378 Send a message to @email{@value{email-general}}.
13383 @node Adding Options
13384 @chapter Adding Options
13385 @cindex options, adding
13386 @cindex adding options
13388 To add a new command-line option to @code{g77}, first decide
13389 what kind of option you wish to add.
13390 Search the @code{g77} and @code{gcc} documentation for one
13391 or more options that is most closely like the one you want to add
13392 (in terms of what kind of effect it has, and so on) to
13393 help clarify its nature.
13397 @emph{Fortran options} are options that apply only
13398 when compiling Fortran programs.
13399 They are accepted by @code{g77} and @code{gcc}, but
13400 they apply only when compiling Fortran programs.
13403 @emph{Compiler options} are options that apply
13404 when compiling most any kind of program.
13407 @emph{Fortran options} are listed in the file
13408 @file{@value{path-g77}/lang-options.h},
13409 which is used during the build of @code{gcc} to
13410 build a list of all options that are accepted by
13411 at least one language's compiler.
13412 This list goes into the @samp{lang_options} array
13413 in @file{gcc/toplev.c}, which uses this array to
13414 determine whether a particular option should be
13415 offered to the linked-in front end for processing
13416 by calling @samp{lang_option_decode}, which, for
13417 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13418 calls @samp{ffe_decode_option}.
13420 If the linked-in front end ``rejects'' a
13421 particular option passed to it, @file{toplev.c}
13422 just ignores the option, because @emph{some}
13423 language's compiler is willing to accept it.
13425 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13426 to work, even though Fortran compilation does
13427 not currently support the @samp{-fno-asm} option;
13428 even though the @code{f771} version of @samp{lang_decode_option}
13429 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13430 produce a diagnostic because some other language (C)
13433 This also means that commands like
13434 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13435 despite the fact that no phase of the command was
13436 able to recognize and process @samp{-fno-asm}---perhaps
13437 a warning about this would be helpful if it were
13440 Code that processes Fortran options is found in
13441 @file{@value{path-g77}/top.c}, function @samp{ffe_decode_option}.
13442 This code needs to check positive and negative forms
13445 The defaults for Fortran options are set in their
13446 global definitions, also found in @file{@value{path-g77}/top.c}.
13447 Many of these defaults are actually macros defined
13448 in @file{@value{path-g77}/target.h}, since they might be
13450 However, since, in practice, GNU compilers
13451 should behave the same way on all configurations
13452 (especially when it comes to language constructs),
13453 the practice of setting defaults in @file{target.h}
13454 is likely to be deprecated and, ultimately, stopped
13455 in future versions of @code{g77}.
13457 Accessor macros for Fortran options, used by code
13458 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13460 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13461 in the array @samp{f_options}.
13462 An option not listed in @samp{lang_options} is
13463 looked up in @samp{f_options} and handled from there.
13465 The defaults for compiler options are set in the
13466 global definitions for the corresponding variables,
13467 some of which are in @file{gcc/toplev.c}.
13469 You can set different defaults for @emph{Fortran-oriented}
13470 or @emph{Fortran-reticent} compiler options by changing
13471 the way @code{f771} handles the @samp{-fset-g77-defaults}
13472 option, which is always provided as the first option when
13473 called by @code{g77} or @code{gcc}.
13475 This code is in @samp{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13476 Have it change just the variables that you want to default
13477 to a different setting for Fortran compiles compared to
13478 compiles of other languages.
13480 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13481 automatically because of the specification information
13482 kept in @file{@value{path-g77}/lang-specs.h}.
13483 This file tells the @code{gcc} command how to recognize,
13484 in this case, Fortran source files (those to be preprocessed,
13485 and those that are not), and further, how to invoke the
13486 appropriate programs (including @code{f771}) to process
13487 those source files.
13489 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
13490 @samp{-fversion}, and other options are passed, as appropriate,
13491 even when the user has not explicitly specified them.
13492 Other ``internal'' options such as @samp{-quiet} also
13493 are passed via this mechanism.
13499 If you want to contribute to @code{g77} by doing research,
13500 design, specification, documentation, coding, or testing,
13501 the following information should give you some ideas.
13504 * Efficiency:: Make @code{g77} itself compile code faster.
13505 * Better Optimization:: Teach @code{g77} to generate faster code.
13506 * Simplify Porting:: Make @code{g77} easier to configure, build,
13508 * More Extensions:: Features many users won't know to ask for.
13509 * Machine Model:: @code{g77} should better leverage @code{gcc}.
13510 * Internals Documentation:: Make maintenance easier.
13511 * Internals Improvements:: Make internals more robust.
13512 * Better Diagnostics:: Make using @code{g77} on new code easier.
13516 @section Improve Efficiency
13519 Don't bother doing any performance analysis until most of the
13520 following items are taken care of, because there's no question
13521 they represent serious space/time problems, although some of
13522 them show up only given certain kinds of (popular) input.
13526 Improve @samp{malloc} package and its uses to specify more info about
13527 memory pools and, where feasible, use obstacks to implement them.
13530 Skip over uninitialized portions of aggregate areas (arrays,
13531 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
13532 This would reduce memory usage for large initialized aggregate
13533 areas, even ones with only one initialized element.
13535 As of version 0.5.18, a portion of this item has already been
13539 Prescan the statement (in @file{sta.c}) so that the nature of the statement
13540 is determined as much as possible by looking entirely at its form,
13541 and not looking at any context (previous statements, including types
13543 This would allow ripping out of the statement-confirmation,
13544 symbol retraction/confirmation, and diagnostic inhibition
13546 Plus, it would result in much-improved diagnostics.
13547 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
13548 is not a subroutine intrinsic, would result actual error instead of the
13549 unimplemented-statement catch-all.
13552 Throughout @code{g77}, don't pass line/column pairs where
13553 a simple @samp{ffewhere} type, which points to the error as much as is
13554 desired by the configuration, will do, and don't pass @samp{ffelexToken} types
13555 where a simple @samp{ffewhere} type will do.
13556 Then, allow new default
13557 configuration of @samp{ffewhere} such that the source line text is not
13558 preserved, and leave it to things like Emacs' next-error function
13559 to point to them (now that @samp{next-error} supports column,
13560 or, perhaps, character-offset, numbers).
13561 The change in calling sequences should improve performance somewhat,
13562 as should not having to save source lines.
13563 (Whether this whole
13564 item will improve performance is questionable, but it should
13565 improve maintainability.)
13568 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
13569 as regards the assembly output.
13570 Some of this might require improving
13571 the back end, but lots of improvement in space/time required in @code{g77}
13572 itself can be fairly easily obtained without touching the back end.
13573 Maybe type-conversion, where necessary, can be speeded up as well in
13574 cases like the one shown (converting the @samp{2} into @samp{2.}).
13577 If analysis shows it to be worthwhile, optimize @file{lex.c}.
13580 Consider redesigning @file{lex.c} to not need any feedback
13581 during tokenization, by keeping track of enough parse state on its
13585 @node Better Optimization
13586 @section Better Optimization
13587 @cindex optimization, better
13588 @cindex code generation, improving
13590 Much of this work should be put off until after @code{g77} has
13591 all the features necessary for its widespread acceptance as a
13592 useful F77 compiler.
13593 However, perhaps this work can be done in parallel during
13594 the feature-adding work.
13598 Do the equivalent of the trick of putting @samp{extern inline} in front
13599 of every function definition in @code{libg2c} and #include'ing the resulting
13600 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
13601 that are at all worth inlining.
13602 (Some of this has already been done, such as for integral exponentiation.)
13605 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
13606 and it's clear that types line up
13607 and @samp{CHAR_VAR} is addressable or not a @samp{VAR_DECL},
13608 make @samp{CHAR_VAR}, not a
13609 temporary, be the receiver for @samp{CHAR_FUNC}.
13610 (This is now done for @code{COMPLEX} variables.)
13613 Design and implement Fortran-specific optimizations that don't
13614 really belong in the back end, or where the front end needs to
13615 give the back end more info than it currently does.
13618 Design and implement a new run-time library interface, with the
13619 code going into @code{libgcc} so no special linking is required to
13620 link Fortran programs using standard language features.
13622 would speed up lots of things, from I/O (using precompiled formats,
13623 doing just one, or, at most, very few, calls for arrays or array sections,
13624 and so on) to general computing (array/section implementations of
13625 various intrinsics, implementation of commonly performed loops that
13626 aren't likely to be optimally compiled otherwise, etc.).
13628 Among the important things the library would do are:
13632 Be a one-stop-shop-type
13633 library, hence shareable and usable by all, in that what are now
13634 library-build-time options in @code{libg2c} would be moved at least to the
13635 @code{g77} compile phase, if not to finer grains (such as choosing how
13636 list-directed I/O formatting is done by default at @code{OPEN} time, for
13637 preconnected units via options or even statements in the main program
13638 unit, maybe even on a per-I/O basis with appropriate pragma-like
13643 Probably requiring the new library design, change interface to
13644 normally have @code{COMPLEX} functions return their values in the way
13645 @code{gcc} would if they were declared @code{__complex__ float},
13647 the mechanism currently used by @code{CHARACTER} functions (whereby the
13648 functions are compiled as returning void and their first arg is
13649 a pointer to where to store the result).
13650 (Don't append underscores to
13651 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
13652 @code{gcc} rather than @code{f2c} calling conventions.)
13655 Do something useful with @samp{doiter} references where possible.
13656 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
13657 a @code{DO} loop that uses @samp{I} as the
13658 iteration variable, and the back end might find that info useful
13659 in determining whether it needs to read @samp{I} back into a register after
13661 (It normally has to do that, unless it knows @samp{FOO} never
13662 modifies its passed-by-reference argument, which is rarely the case
13663 for Fortran-77 code.)
13666 @node Simplify Porting
13667 @section Simplify Porting
13668 @cindex porting, simplify
13669 @cindex simplify porting
13671 Making @code{g77} easier to configure, port, build, and install, either
13672 as a single-system compiler or as a cross-compiler, would be
13677 A new library (replacing @code{libg2c}) should improve portability as well as
13678 produce more optimal code.
13679 Further, @code{g77} and the new library should
13680 conspire to simplify naming of externals, such as by removing unnecessarily
13681 added underscores, and to reduce/eliminate the possibility of naming
13682 conflicts, while making debugger more straightforward.
13685 make multi-language applications more feasible, such as by providing
13686 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
13690 Possibly related to a new library, @code{g77} should produce the equivalent
13691 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
13692 main program unit, instead of compiling something that must be
13693 called by a library
13694 implementation of @code{main()}.
13696 This would do many useful things such as
13697 provide more flexibility in terms of setting up exception handling,
13698 not requiring programmers to start their debugging sessions with
13699 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
13702 The GBE needs to understand the difference between alignment
13703 requirements and desires.
13704 For example, on Intel x86 machines, @code{g77} currently imposes
13705 overly strict alignment requirements, due to the back end, but it
13706 would be useful for Fortran and C programmers to be able to override
13707 these @emph{recommendations} as long as they don't violate the actual
13708 processor @emph{requirements}.
13711 @node More Extensions
13712 @section More Extensions
13713 @cindex extensions, more
13715 These extensions are not the sort of things users ask for ``by name'',
13716 but they might improve the usability of @code{g77}, and Fortran in
13717 general, in the long run.
13718 Some of these items really pertain to improving @code{g77} internals
13719 so that some popular extensions can be more easily supported.
13723 Look through all the documentation on the GNU Fortran language,
13724 dialects, compiler, missing features, bugs, and so on.
13725 Many mentions of incomplete or missing features are
13726 sprinkled throughout.
13727 It is not worth repeating them here.
13730 @cindex concatenation
13731 @cindex CHARACTER*(*)
13732 Support arbitrary operands for concatenation, even in contexts where
13733 run-time allocation is required.
13736 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
13738 The idea is to provide a forward-looking, effective
13739 replacement for things like the old-style @code{PARAMETER} statement
13741 really need typelessness in a maintainable, portable, clearly documented
13743 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
13744 and whatever else might come along.
13745 (This is not really a call for polymorphism per se, just
13746 an ability to express limited, syntactic polymorphism.)
13749 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
13752 Support arbitrary file unit numbers, instead of limiting them
13753 to 0 through @samp{MXUNIT-1}.
13754 (This is a @code{libg2c} issue.)
13757 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
13758 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
13759 later @code{UNIT=} in the first example is invalid.
13760 Make sure this is what users of this feature would expect.
13763 Currently @code{g77} disallows @samp{READ(1'10)} since
13764 it is an obnoxious syntax, but
13765 supporting it might be pretty easy if needed.
13766 More details are needed, such
13767 as whether general expressions separated by an apostrophe are supported,
13768 or maybe the record number can be a general expression, and so on.
13771 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
13773 Currently there is no support at all
13774 for @code{%FILL} in @code{STRUCTURE} and related syntax,
13775 whereas the rest of the
13776 stuff has at least some parsing support.
13777 This requires either major
13778 changes to @code{libg2c} or its replacement.
13781 F90 and @code{g77} probably disagree about label scoping relative to
13782 @code{INTERFACE} and @code{END INTERFACE}, and their contained
13783 procedure interface bodies (blocks?).
13786 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
13787 since that was added after S8.112.
13790 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
13791 with the final form of the standard (it was vague at S8.112).
13794 It seems to be an ``open'' question whether a file, immediately after being
13795 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
13796 might be nice to offer an option of opening to ``undefined'' status, requiring
13797 an explicit absolute-positioning operation to be performed before any
13798 other (besides @code{CLOSE}) to assist in making applications port to systems
13799 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
13802 @node Machine Model
13803 @section Machine Model
13805 This items pertain to generalizing @code{g77}'s view of
13806 the machine model to more fully accept whatever the GBE
13807 provides it via its configuration.
13811 Switch to using @samp{REAL_VALUE_TYPE} to represent floating-point constants
13812 exclusively so the target float format need not be required.
13814 means changing the way @code{g77} handles initialization of aggregate areas
13815 having more than one type, such as @code{REAL} and @code{INTEGER},
13817 it initializes them as if they were arrays of @code{char} and uses the
13818 bit patterns of the constants of the various types in them to determine
13819 what to stuff in elements of the arrays.
13822 Rely more and more on back-end info and capabilities, especially in the
13823 area of constants (where having the @code{g77} front-end's IL just store
13824 the appropriate tree nodes containing constants might be best).
13827 Suite of C and Fortran programs that a user/administrator can run on a
13828 machine to help determine the configuration for @code{g77} before building
13829 and help determine if the compiler works (especially with whatever
13830 libraries are installed) after building.
13833 @node Internals Documentation
13834 @section Internals Documentation
13836 Better info on how @code{g77} works and how to port it is needed.
13837 Much of this should be done only after the redesign planned for
13840 @node Internals Improvements
13841 @section Internals Improvements
13843 Some more items that would make @code{g77} more reliable
13844 and easier to maintain:
13848 Generally make expression handling focus
13849 more on critical syntax stuff, leaving semantics to callers.
13851 anything a caller can check, semantically, let it do so, rather
13852 than having @file{expr.c} do it.
13853 (Exceptions might include things like
13854 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
13856 important to preserve the left-to-right-in-source order of production
13860 Come up with better naming conventions for @samp{-D} to establish requirements
13861 to achieve desired implementation dialect via @file{proj.h}.
13864 Clean up used tokens and @samp{ffewhere}s in @samp{ffeglobal_terminate_1}.
13867 Replace @file{sta.c} @samp{outpooldisp} mechanism with @samp{malloc_pool_use}.
13870 Check for @samp{opANY} in more places in @file{com.c}, @file{std.c},
13871 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
13872 (after determining if there is indeed no real need for it).
13875 Utility to read and check @file{bad.def} messages and their references in the
13876 code, to make sure calls are consistent with message templates.
13879 Search and fix @samp{&ffe@dots{}} and similar so that
13880 @samp{ffe@dots{}ptr@dots{}} macros are
13881 available instead (a good argument for wishing this could have written all
13882 this stuff in C++, perhaps).
13883 On the other hand, it's questionable whether this sort of
13884 improvement is really necessary, given the availability of
13885 tools such as Emacs and Perl, which make finding any
13886 address-taking of structure members easy enough?
13889 Some modules truly export the member names of their structures (and the
13890 structures themselves), maybe fix this, and fix other modules that just
13891 appear to as well (by appending @samp{_}, though it'd be ugly and probably
13892 not worth the time).
13895 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
13897 and use them throughout @code{g77} source code (especially in the definitions
13898 of access macros in @samp{.h} files) so they can be tailored
13899 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
13902 Decorate throughout with @code{const} and other such stuff.
13905 All F90 notational derivations in the source code are still based
13906 on the S8.112 version of the draft standard.
13907 Probably should update
13908 to the official standard, or put documentation of the rules as used
13909 in the code@dots{}uh@dots{}in the code.
13912 Some @samp{ffebld_new} calls (those outside of @file{ffeexpr.c} or
13913 inside but invoked via paths not involving @samp{ffeexpr_lhs} or
13914 @samp{ffeexpr_rhs}) might be creating things
13915 in improper pools, leading to such things staying around too long or
13916 (doubtful, but possible and dangerous) not long enough.
13919 Some @samp{ffebld_list_new} (or whatever) calls might not be matched by
13920 @samp{ffebld_list_bottom} (or whatever) calls, which might someday matter.
13921 (It definitely is not a problem just yet.)
13924 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
13925 due to alignment/mismatch or other problems---they end up without
13926 @samp{ffestorag} objects, so maybe the backend (and other parts of the front
13927 end) can notice that and handle like an @samp{opANY} (do what it wants, just
13928 don't complain or crash).
13929 Most of this seems to have been addressed
13930 by now, but a code review wouldn't hurt.
13933 @node Better Diagnostics
13934 @section Better Diagnostics
13936 These are things users might not ask about, or that need to
13937 be looked into, before worrying about.
13938 Also here are items that involve reducing unnecessary diagnostic
13943 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
13944 lengths, type classes, and so on),
13945 @samp{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
13949 Speed up and improve error handling for data when repeat-count is
13951 For example, don't output 20 unnecessary messages after the
13952 first necessary one for:
13957 DATA (X(I), J= 1, 20) /20*5/
13962 (The @code{CONTINUE} statement ensures the @code{DATA} statement
13963 is processed in the context of executable, not specification,
13970 @chapter Diagnostics
13971 @cindex diagnostics
13973 Some diagnostics produced by @code{g77} require sufficient explanation
13974 that the explanations are given below, and the diagnostics themselves
13975 identify the appropriate explanation.
13977 Identification uses the GNU Info format---specifically, the @code{info}
13978 command that displays the explanation is given within square
13979 brackets in the diagnostic.
13983 foo.f:5: Invalid statement [info -f g77 M FOOEY]
13986 More details about the above diagnostic is found in the @code{g77} Info
13987 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
13988 which is displayed by typing the UNIX command
13989 @samp{info -f g77 M FOOEY}.
13991 Other Info readers, such as EMACS, may be just as easily used to display
13992 the pertinent node.
13993 In the above example, @samp{g77} is the Info document name,
13994 @samp{M} is the top-level menu item to select,
13995 and, in that node (named @samp{Diagnostics}, the name of
13996 this chapter, which is the very text you're reading now),
13997 @samp{FOOEY} is the menu item to select.
14000 In this printed version of the @code{g77} manual, the above example
14001 points to a section, below, entitled @samp{FOOEY}---though, of course,
14002 as the above is just a sample, no such section exists.
14006 * CMPAMBIG:: Ambiguous use of intrinsic.
14007 * EXPIMP:: Intrinsic used explicitly and implicitly.
14008 * INTGLOB:: Intrinsic also used as name of global.
14009 * LEX:: Various lexer messages
14010 * GLOBALS:: Disagreements about globals.
14011 * LINKFAIL:: When linking @samp{f771} fails.
14015 @section @code{CMPAMBIG}
14019 Ambiguous use of intrinsic @var{intrinsic} @dots{}
14022 The type of the argument to the invocation of the @var{intrinsic}
14023 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
14024 Typically, it is @code{COMPLEX(KIND=2)}, also known as
14025 @code{DOUBLE COMPLEX}.
14027 The interpretation of this invocation depends on the particular
14028 dialect of Fortran for which the code was written.
14029 Some dialects convert the real part of the argument to
14030 @code{REAL(KIND=1)}, thus losing precision; other dialects,
14031 and Fortran 90, do no such conversion.
14033 So, GNU Fortran rejects such invocations except under certain
14034 circumstances, to avoid making an incorrect assumption that results
14035 in generating the wrong code.
14037 To determine the dialect of the program unit, perhaps even whether
14038 that particular invocation is properly coded, determine how the
14039 result of the intrinsic is used.
14041 The result of @var{intrinsic} is expected (by the original programmer)
14042 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
14046 It is passed as an argument to a procedure that explicitly or
14047 implicitly declares that argument @code{REAL(KIND=1)}.
14050 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
14051 statement specifying the dummy argument corresponding to an
14052 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14053 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14054 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
14055 of @code{REAL(KIND=2)}.
14058 It is used in a context that would otherwise not include
14059 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
14060 invocation as @code{REAL(KIND=2)} would result in unnecessary
14061 promotions and (typically) more expensive operations on the
14072 The above example suggests the programmer expected the real part
14073 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
14074 multiplied by @samp{T} (presumed, along with @samp{R} above, to
14075 be type @code{REAL(KIND=1)}).
14077 Otherwise, the conversion would have to be delayed until after
14078 the multiplication, requiring not only an extra conversion
14079 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
14080 expensive multiplication (a double-precision multiplication instead
14081 of a single-precision one).
14084 The result of @var{intrinsic} is expected (by the original programmer)
14085 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
14089 It is passed as an argument to a procedure that explicitly or
14090 implicitly declares that argument @code{REAL(KIND=2)}.
14092 For example, a procedure specifying a @code{DOUBLE PRECISION}
14093 dummy argument corresponding to an
14094 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14095 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14096 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
14097 of @code{REAL(KIND=1)}.
14100 It is used in an expression context that includes
14101 other @code{REAL(KIND=2)} operands,
14102 or is assigned to a @code{REAL(KIND=2)} variable or array element.
14108 DOUBLE PRECISION R, T
14113 The above example suggests the programmer expected the real part
14114 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
14115 by the @code{REAL()} intrinsic.
14117 Otherwise, the conversion would have to be immediately followed
14118 by a conversion back to @code{REAL(KIND=2)}, losing
14119 the original, full precision of the real part of @code{Z},
14120 before being multiplied by @samp{T}.
14123 Once you have determined whether a particular invocation of @var{intrinsic}
14124 expects the Fortran 90 interpretation, you can:
14128 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
14129 @samp{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
14131 if it expected the Fortran 90 interpretation.
14133 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
14134 some other type, such as @code{COMPLEX*32}, you should use the
14135 appropriate intrinsic, such as the one to convert to @code{REAL*16}
14136 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
14137 @code{QIMAG()} in place of @code{DIMAG()}).
14140 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
14142 This converts to @code{REAL(KIND=1)} in all working
14146 If you don't want to change the code, and you are certain that all
14147 ambiguous invocations of @var{intrinsic} in the source file have
14148 the same expectation regarding interpretation, you can:
14152 Compile with the @code{g77} option @samp{-ff90}, to enable the
14153 Fortran 90 interpretation.
14156 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
14157 to enable the non-Fortran-90 interpretations.
14160 @xref{REAL() and AIMAG() of Complex}, for more information on this
14163 Note: If the above suggestions don't produce enough evidence
14164 as to whether a particular program expects the Fortran 90
14165 interpretation of this ambiguous invocation of @var{intrinsic},
14166 there is one more thing you can try.
14168 If you have access to most or all the compilers used on the
14169 program to create successfully tested and deployed executables,
14170 read the documentation for, and @emph{also} test out, each compiler
14171 to determine how it treats the @var{intrinsic} intrinsic in
14173 (If all the compilers don't agree on an interpretation, there
14174 might be lurking bugs in the deployed versions of the program.)
14176 The following sample program might help:
14178 @cindex JCB003 program
14182 C Written by James Craig Burley 1997-02-23.
14183 C Contact via Internet email: burley@@gnu.org
14185 C Determine how compilers handle non-standard REAL
14186 C and AIMAG on DOUBLE COMPLEX operands.
14194 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14195 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14199 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14200 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14203 C Just to make sure compiler doesn't use naive flow
14204 C analysis to optimize away careful work above,
14205 C which might invalidate results....
14207 SUBROUTINE DUMDUM(Z, R)
14213 If the above program prints contradictory results on a
14214 particular compiler, run away!
14217 @section @code{EXPIMP}
14221 Intrinsic @var{intrinsic} referenced @dots{}
14224 The @var{intrinsic} is explicitly declared in one program
14225 unit in the source file and implicitly used as an intrinsic
14226 in another program unit in the same source file.
14228 This diagnostic is designed to catch cases where a program
14229 might depend on using the name @var{intrinsic} as an intrinsic
14230 in one program unit and as a global name (such as the name
14231 of a subroutine or function) in another, but @code{g77} recognizes
14232 the name as an intrinsic in both cases.
14234 After verifying that the program unit making implicit use
14235 of the intrinsic is indeed written expecting the intrinsic,
14236 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14237 program unit to prevent this warning.
14239 This and related warnings are disabled by using
14240 the @samp{-Wno-globals} option when compiling.
14242 Note that this warning is not issued for standard intrinsics.
14243 Standard intrinsics include those described in the FORTRAN 77
14244 standard and, if @samp{-ff90} is specified, those described
14245 in the Fortran 90 standard.
14246 Such intrinsics are not as likely to be confused with user
14247 procedures as intrinsics provided as extensions to the
14248 standard by @code{g77}.
14251 @section @code{INTGLOB}
14255 Same name `@var{intrinsic}' given @dots{}
14258 The name @var{intrinsic} is used for a global entity (a common
14259 block or a program unit) in one program unit and implicitly
14260 used as an intrinsic in another program unit.
14262 This diagnostic is designed to catch cases where a program
14263 intends to use a name entirely as a global name, but @code{g77}
14264 recognizes the name as an intrinsic in the program unit that
14265 references the name, a situation that would likely produce
14271 INTEGER FUNCTION TIME()
14277 PRINT *, 'Time is ', TIME()
14281 The above example defines a program unit named @samp{TIME}, but
14282 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14283 is normally treated by @code{g77} as a reference to the intrinsic
14284 @code{TIME()} (unless a command-line option that prevents such
14285 treatment has been specified).
14287 As a result, the program @samp{SAMP} will @emph{not}
14288 invoke the @samp{TIME} function in the same source file.
14290 Since @code{g77} recognizes @code{libU77} procedures as
14291 intrinsics, and since some existing code uses the same names
14292 for its own procedures as used by some @code{libU77}
14293 procedures, this situation is expected to arise often enough
14294 to make this sort of warning worth issuing.
14296 After verifying that the program unit making implicit use
14297 of the intrinsic is indeed written expecting the intrinsic,
14298 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14299 program unit to prevent this warning.
14301 Or, if you believe the program unit is designed to invoke the
14302 program-defined procedure instead of the intrinsic (as
14303 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14304 statement to the program unit that references the name to
14305 prevent this warning.
14307 This and related warnings are disabled by using
14308 the @samp{-Wno-globals} option when compiling.
14310 Note that this warning is not issued for standard intrinsics.
14311 Standard intrinsics include those described in the FORTRAN 77
14312 standard and, if @samp{-ff90} is specified, those described
14313 in the Fortran 90 standard.
14314 Such intrinsics are not as likely to be confused with user
14315 procedures as intrinsics provided as extensions to the
14316 standard by @code{g77}.
14319 @section @code{LEX}
14323 Unrecognized character @dots{}
14324 Invalid first character @dots{}
14325 Line too long @dots{}
14326 Non-numeric character @dots{}
14327 Continuation indicator @dots{}
14328 Label at @dots{} invalid with continuation line indicator @dots{}
14329 Character constant @dots{}
14330 Continuation line @dots{}
14331 Statement at @dots{} begins with invalid token
14334 Although the diagnostics identify specific problems, they can
14335 be produced when general problems such as the following occur:
14339 The source file contains something other than Fortran code.
14341 If the code in the file does not look like many of the examples
14342 elsewhere in this document, it might not be Fortran code.
14343 (Note that Fortran code often is written in lower case letters,
14344 while the examples in this document use upper case letters,
14345 for stylistic reasons.)
14347 For example, if the file contains lots of strange-looking
14348 characters, it might be APL source code; if it contains lots
14349 of parentheses, it might be Lisp source code; if it
14350 contains lots of bugs, it might be C++ source code.
14353 The source file contains free-form Fortran code, but @samp{-ffree-form}
14354 was not specified on the command line to compile it.
14356 Free form is a newer form for Fortran code.
14357 The older, classic form is called fixed form.
14359 Fixed-form code is visually fairly distinctive, because
14360 numerical labels and comments are all that appear in
14361 the first five columns of a line, the sixth column is
14362 reserved to denote continuation lines,
14363 and actual statements start at or beyond column 7.
14364 Spaces generally are not significant, so if you
14365 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14366 you are looking at fixed-form code.
14367 Comment lines are indicated by the letter @samp{C} or the symbol
14368 @samp{*} in column 1.
14369 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14370 which many compilers support.)
14372 Free-form code is distinguished from fixed-form source
14373 primarily by the fact that statements may start anywhere.
14374 (If lots of statements start in columns 1 through 6,
14375 that's a strong indicator of free-form source.)
14376 Consecutive keywords must be separated by spaces, so
14377 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14378 There are no comment lines per se, but @samp{!} starts a
14379 comment anywhere in a line (other than within a character or
14380 hollerith constant).
14382 @xref{Source Form}, for more information.
14385 The source file is in fixed form and has been edited without
14386 sensitivity to the column requirements.
14388 Statements in fixed-form code must be entirely contained within
14389 columns 7 through 72 on a given line.
14390 Starting them ``early'' is more likely to result in diagnostics
14391 than finishing them ``late'', though both kinds of errors are
14392 often caught at compile time.
14394 For example, if the following code fragment is edited by following
14395 the commented instructions literally, the result, shown afterward,
14396 would produce a diagnostic when compiled:
14399 C On XYZZY systems, remove "C" on next line:
14403 The result of editing the above line might be:
14406 C On XYZZY systems, remove "C" on next line:
14410 However, that leaves the first @samp{C} in the @samp{CALL}
14411 statement in column 6, making it a comment line, which is
14412 not really what the author intended, and which is likely
14413 to result in one of the above-listed diagnostics.
14415 @emph{Replacing} the @samp{C} in column 1 with a space
14416 is the proper change to make, to ensure the @samp{CALL}
14417 keyword starts in or after column 7.
14419 Another common mistake like this is to forget that fixed-form
14420 source lines are significant through only column 72, and that,
14421 normally, any text beyond column 72 is ignored or is diagnosed
14424 @xref{Source Form}, for more information.
14427 The source file requires preprocessing, and the preprocessing
14428 is not being specified at compile time.
14430 A source file containing lines beginning with @code{#define},
14431 @code{#include}, @code{#if}, and so on is likely one that
14432 requires preprocessing.
14434 If the file's suffix is @samp{.f} or @samp{.for}, the file
14435 will normally be compiled @emph{without} preprocessing by @code{g77}.
14437 Change the file's suffix from @samp{.f} to @samp{.F} (or, on
14438 systems with case-insensitive file names, to @samp{.fpp}) or
14439 from @samp{.for} to @samp{.fpp}.
14440 @code{g77} compiles files with such names @emph{with}
14443 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14444 the language @samp{f77-cpp-input} for Fortran files that
14445 require preprocessing.
14446 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14449 The source file is preprocessed, and the results of preprocessing
14450 result in syntactic errors that are not necessarily obvious to
14451 someone examining the source file itself.
14453 Examples of errors resulting from preprocessor macro expansion
14454 include exceeding the line-length limit, improperly starting,
14455 terminating, or incorporating the apostrophe or double-quote in
14456 a character constant, improperly forming a hollerith constant,
14459 @xref{Overall Options,,Options Controlling the Kind of Output},
14460 for suggestions about how to use, and not use, preprocessing
14465 @section @code{GLOBALS}
14469 Global name @var{name} defined at @dots{} already defined@dots{}
14470 Global name @var{name} at @dots{} has different type@dots{}
14471 Too many arguments passed to @var{name} at @dots{}
14472 Too few arguments passed to @var{name} at @dots{}
14473 Argument #@var{n} of @var{name} is @dots{}
14476 These messages all identify disagreements about the
14477 global procedure named @var{name} among different program
14478 units (usually including @var{name} itself).
14480 These disagreements, if not diagnosed, could result in a
14481 compiler crash if the compiler attempted to inline a reference
14482 to @var{name} within a calling program unit that disagreed
14483 with the @var{name} program unit regarding whether the
14484 procedure is a subroutine or function, the type of the
14485 return value of the procedure (if it is a function), the
14486 number of arguments the procedure accepts, or the type
14489 Such disagreements @emph{should} be fixed in the Fortran
14491 However, if that is not immediately practical, and the code
14492 has been working for some time, it is possible it will work
14493 when compiled by @code{g77} with the @samp{-fno-globals} option.
14495 The @samp{-fno-globals} option disables these diagnostics, and
14496 also disables all inlining of references to global procedures
14497 to avoid compiler crashes.
14498 The diagnostics are actually produced, but as warnings, unless
14499 the @samp{-Wno-globals} option also is specified.
14501 After using @samp{-fno-globals} to work around these problems,
14502 it is wise to stop using that option and address them by fixing
14503 the Fortran code, because such problems, while they might not
14504 actually result in bugs on some systems, indicate that the code
14505 is not as portable as it could be.
14506 In particular, the code might appear to work on a particular
14507 system, but have bugs that affect the reliability of the data
14508 without exhibiting any other outward manifestations of the bugs.
14511 @section @code{LINKFAIL}
14515 If the above command failed due to an unresolved reference
14516 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
14517 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
14518 for information on what causes this, how to work around
14519 the problem by editing $@{srcdir@}/proj.c, and what else to do.
14522 @xref{Missing strtoul or bsearch}, for more information on
14524 which occurs only in releases of @code{g77}
14525 based on @code{gcc}.
14526 (It does not occur in @code{egcs}.)
14528 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
14529 due to a linker bug in coping with the @samp{-bbigtoc} option
14530 which leads to a @samp{Relocation overflow} error.
14532 Compiling with @samp{-mminimal-toc}
14533 might solve this problem, e.g.@: by adding
14535 BOOT_CFLAGS='-mminimal-toc -O2 -g'
14537 to the @code{make bootstrap} command line.