1 \input texinfo @c -*-texinfo-*-
5 @set last-update 1999-04-03
6 @set copyrights-g77 1995-1999
10 @c This tells @include'd files that they're part of the overall G77 doc
11 @c set. (They might be part of a higher-level doc set too.)
14 @c @setfilename useg77.info
15 @c @setfilename portg77.info
16 @c To produce the full manual, use the "g77.info" setfilename, and
17 @c make sure the following do NOT begin with '@c' (and the @clear lines DO)
20 @c To produce a user-only manual, use the "useg77.info" setfilename, and
21 @c make sure the following does NOT begin with '@c':
23 @c To produce a porter-only manual, use the "portg77.info" setfilename,
24 @c and make sure the following does NOT begin with '@c':
27 @c 6/27/96 FSF DO wants smallbook fmt for 1st bound edition. (from gcc.texi)
30 @c i also commented out the finalout command, so if there *are* any
31 @c overfulls, you'll (hopefully) see the rectangle in the right hand
32 @c margin. -- burley 1999-03-13 (from mew's comment in gcc.texi).
37 @settitle Using and Porting GNU Fortran
40 @c seems reasonable to assume at least one of INTERNALS or USING is set...
42 @settitle Using GNU Fortran
45 @settitle Porting GNU Fortran
47 @c then again, have some fun
50 @settitle Doing Squat with GNU Fortran
58 @c Cause even numbered pages to be printed on the left hand side of
59 @c the page and odd numbered pages to be printed on the right hand
60 @c side of the page. Using this, you can print on both sides of a
61 @c sheet of paper and have the text on the same part of the sheet.
63 @c The text on right hand pages is pushed towards the right hand
64 @c margin and the text on left hand pages is pushed toward the left
66 @c (To provide the reverse effect, set bindingoffset to -0.75in.)
69 @c \global\bindingoffset=0.75in
70 @c \global\normaloffset =0.75in
74 @dircategory Programming
76 * g77: (g77). The GNU Fortran compiler.
80 This file documents the use and the internals of the GNU Fortran (@code{g77})
82 It corresponds to the @value{which-g77} version of @code{g77}.
86 This file documents the internals of the GNU Fortran (@code{g77}) compiler.
87 It corresponds to the @value{which-g77} version of @code{g77}.
90 This file documents the use of the GNU Fortran (@code{g77}) compiler.
91 It corresponds to the @value{which-g77} version of @code{g77}.
94 Published by the Free Software Foundation
95 59 Temple Place - Suite 330
96 Boston, MA 02111-1307 USA
98 Copyright (C) @value{copyrights-g77} Free Software Foundation, Inc.
100 Permission is granted to make and distribute verbatim copies of
101 this manual provided the copyright notice and this permission notice
102 are preserved on all copies.
105 Permission is granted to process this file through Tex and print the
106 results, provided the printed document carries copying permission
107 notice identical to this one except for the removal of this paragraph
108 (this paragraph not being relevant to the printed manual).
111 Permission is granted to copy and distribute modified versions of this
112 manual under the conditions for verbatim copying, provided also that the
113 sections entitled ``GNU General Public License,'' ``Funding for Free
114 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
115 included exactly as in the original, and provided that the entire
116 resulting derived work is distributed under the terms of a permission
117 notice identical to this one.
119 Permission is granted to copy and distribute translations of this manual
120 into another language, under the above conditions for modified versions,
121 except that the sections entitled ``GNU General Public License,''
122 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
123 And Feel'@w{}'', and this permission notice, may be included in
124 translations approved by the Free Software Foundation instead of in the
128 Contributed by James Craig Burley (@email{@value{email-burley}}).
129 Inspired by a first pass at translating @file{g77-0.5.16/f/DOC} that
130 was contributed to Craig by David Ronis (@email{ronis@@onsager.chem.mcgill.ca}).
132 @setchapternewpage odd
137 @center @titlefont{Using and Porting GNU Fortran}
142 @title Using GNU Fortran
145 @title Porting GNU Fortran
148 @center James Craig Burley
150 @center Last updated @value{last-update}
152 @center for version @value{version-g77}
154 @vskip 0pt plus 1filll
155 Copyright @copyright{} @value{copyrights-g77} Free Software Foundation, Inc.
157 For the @value{which-g77} Version*
159 Published by the Free Software Foundation @*
160 59 Temple Place - Suite 330@*
161 Boston, MA 02111-1307, USA@*
162 @c Last printed ??ber, 19??.@*
163 @c Printed copies are available for $? each.@*
166 Permission is granted to make and distribute verbatim copies of
167 this manual provided the copyright notice and this permission notice
168 are preserved on all copies.
170 Permission is granted to copy and distribute modified versions of this
171 manual under the conditions for verbatim copying, provided also that the
172 sections entitled ``GNU General Public License,'' ``Funding for Free
173 Software,'' and ``Protect Your Freedom---Fight `Look And Feel'@w{}'' are
174 included exactly as in the original, and provided that the entire
175 resulting derived work is distributed under the terms of a permission
176 notice identical to this one.
178 Permission is granted to copy and distribute translations of this manual
179 into another language, under the above conditions for modified versions,
180 except that the sections entitled ``GNU General Public License,''
181 ``Funding for Free Software,'' and ``Protect Your Freedom---Fight `Look
182 And Feel'@w{}'', and this permission notice, may be included in
183 translations approved by the Free Software Foundation instead of in the
190 @node Top, Copying,, (DIR)
196 This manual documents how to run, install and port @code{g77},
197 as well as its new features and incompatibilities,
198 and how to report bugs.
199 It corresponds to the @value{which-g77} version of @code{g77}.
204 This manual documents how to run and install @code{g77},
205 as well as its new features and incompatibilities, and how to report
207 It corresponds to the @value{which-g77} version of @code{g77}.
210 This manual documents how to port @code{g77},
211 as well as its new features and incompatibilities,
212 and how to report bugs.
213 It corresponds to the @value{which-g77} version of @code{g77}.
219 @emph{Warning:} This document is still under development,
220 and might not accurately reflect the @code{g77} code base
221 of which it is a part.
222 Efforts are made to keep it somewhat up-to-date,
223 but they are particularly concentrated
224 on any version of this information
225 that is distributed as part of a @emph{released} @code{g77}.
227 In particular, while this document is intended to apply to
228 the @value{which-g77} version of @code{g77},
229 only an official @emph{release} of that version
230 is expected to contain documentation that is
231 most consistent with the @code{g77} product in that version.
235 * Copying:: GNU General Public License says
236 how you can copy and share GNU Fortran.
237 * Contributors:: People who have contributed to GNU Fortran.
238 * Funding:: How to help assure continued work for free software.
239 * Funding GNU Fortran:: How to help assure continued work on GNU Fortran.
240 * Look and Feel:: Protect your freedom---fight ``look and feel''.
242 * Getting Started:: Finding your way around this manual.
243 * What is GNU Fortran?:: How @code{g77} fits into the universe.
244 * G77 and GCC:: You can compile Fortran, C, or other programs.
245 * Invoking G77:: Command options supported by @code{g77}.
246 * News:: News about recent releases of @code{g77}.
247 * Changes:: User-visible changes to recent releases of @code{g77}.
248 * Language:: The GNU Fortran language.
249 * Compiler:: The GNU Fortran compiler.
250 * Other Dialects:: Dialects of Fortran supported by @code{g77}.
251 * Other Compilers:: Fortran compilers other than @code{g77}.
252 * Other Languages:: Languages other than Fortran.
253 * Installation:: How to configure, compile and install GNU Fortran.
254 * Debugging and Interfacing:: How @code{g77} generates code.
255 * Collected Fortran Wisdom:: How to avoid Trouble.
256 * Trouble:: If you have trouble with GNU Fortran.
257 * Open Questions:: Things we'd like to know.
258 * Bugs:: How, why, and where to report bugs.
259 * Service:: How to find suppliers of support for GNU Fortran.
262 * Adding Options:: Guidance on teaching @code{g77} about new options.
263 * Projects:: Projects for @code{g77} internals hackers.
266 * M: Diagnostics. Diagnostics produced by @code{g77}.
268 * Index:: Index of concepts and symbol names.
270 @c yes, the "M: " @emph{is} intentional -- bad.def references it (CMPAMBIG)!
273 @unnumbered GNU GENERAL PUBLIC LICENSE
274 @center Version 2, June 1991
277 Copyright @copyright{} 1989, 1991 Free Software Foundation, Inc.
278 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
280 Everyone is permitted to copy and distribute verbatim copies
281 of this license document, but changing it is not allowed.
284 @unnumberedsec Preamble
286 The licenses for most software are designed to take away your
287 freedom to share and change it. By contrast, the GNU General Public
288 License is intended to guarantee your freedom to share and change free
289 software---to make sure the software is free for all its users. This
290 General Public License applies to most of the Free Software
291 Foundation's software and to any other program whose authors commit to
292 using it. (Some other Free Software Foundation software is covered by
293 the GNU Library General Public License instead.) You can apply it to
296 When we speak of free software, we are referring to freedom, not
297 price. Our General Public Licenses are designed to make sure that you
298 have the freedom to distribute copies of free software (and charge for
299 this service if you wish), that you receive source code or can get it
300 if you want it, that you can change the software or use pieces of it
301 in new free programs; and that you know you can do these things.
303 To protect your rights, we need to make restrictions that forbid
304 anyone to deny you these rights or to ask you to surrender the rights.
305 These restrictions translate to certain responsibilities for you if you
306 distribute copies of the software, or if you modify it.
308 For example, if you distribute copies of such a program, whether
309 gratis or for a fee, you must give the recipients all the rights that
310 you have. You must make sure that they, too, receive or can get the
311 source code. And you must show them these terms so they know their
314 We protect your rights with two steps: (1) copyright the software, and
315 (2) offer you this license which gives you legal permission to copy,
316 distribute and/or modify the software.
318 Also, for each author's protection and ours, we want to make certain
319 that everyone understands that there is no warranty for this free
320 software. If the software is modified by someone else and passed on, we
321 want its recipients to know that what they have is not the original, so
322 that any problems introduced by others will not reflect on the original
323 authors' reputations.
325 Finally, any free program is threatened constantly by software
326 patents. We wish to avoid the danger that redistributors of a free
327 program will individually obtain patent licenses, in effect making the
328 program proprietary. To prevent this, we have made it clear that any
329 patent must be licensed for everyone's free use or not licensed at all.
331 The precise terms and conditions for copying, distribution and
335 @unnumberedsec TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
338 @center TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION
343 This License applies to any program or other work which contains
344 a notice placed by the copyright holder saying it may be distributed
345 under the terms of this General Public License. The ``Program'', below,
346 refers to any such program or work, and a ``work based on the Program''
347 means either the Program or any derivative work under copyright law:
348 that is to say, a work containing the Program or a portion of it,
349 either verbatim or with modifications and/or translated into another
350 language. (Hereinafter, translation is included without limitation in
351 the term ``modification''.) Each licensee is addressed as ``you''.
353 Activities other than copying, distribution and modification are not
354 covered by this License; they are outside its scope. The act of
355 running the Program is not restricted, and the output from the Program
356 is covered only if its contents constitute a work based on the
357 Program (independent of having been made by running the Program).
358 Whether that is true depends on what the Program does.
361 You may copy and distribute verbatim copies of the Program's
362 source code as you receive it, in any medium, provided that you
363 conspicuously and appropriately publish on each copy an appropriate
364 copyright notice and disclaimer of warranty; keep intact all the
365 notices that refer to this License and to the absence of any warranty;
366 and give any other recipients of the Program a copy of this License
367 along with the Program.
369 You may charge a fee for the physical act of transferring a copy, and
370 you may at your option offer warranty protection in exchange for a fee.
373 You may modify your copy or copies of the Program or any portion
374 of it, thus forming a work based on the Program, and copy and
375 distribute such modifications or work under the terms of Section 1
376 above, provided that you also meet all of these conditions:
380 You must cause the modified files to carry prominent notices
381 stating that you changed the files and the date of any change.
384 You must cause any work that you distribute or publish, that in
385 whole or in part contains or is derived from the Program or any
386 part thereof, to be licensed as a whole at no charge to all third
387 parties under the terms of this License.
390 If the modified program normally reads commands interactively
391 when run, you must cause it, when started running for such
392 interactive use in the most ordinary way, to print or display an
393 announcement including an appropriate copyright notice and a
394 notice that there is no warranty (or else, saying that you provide
395 a warranty) and that users may redistribute the program under
396 these conditions, and telling the user how to view a copy of this
397 License. (Exception: if the Program itself is interactive but
398 does not normally print such an announcement, your work based on
399 the Program is not required to print an announcement.)
402 These requirements apply to the modified work as a whole. If
403 identifiable sections of that work are not derived from the Program,
404 and can be reasonably considered independent and separate works in
405 themselves, then this License, and its terms, do not apply to those
406 sections when you distribute them as separate works. But when you
407 distribute the same sections as part of a whole which is a work based
408 on the Program, the distribution of the whole must be on the terms of
409 this License, whose permissions for other licensees extend to the
410 entire whole, and thus to each and every part regardless of who wrote it.
412 Thus, it is not the intent of this section to claim rights or contest
413 your rights to work written entirely by you; rather, the intent is to
414 exercise the right to control the distribution of derivative or
415 collective works based on the Program.
417 In addition, mere aggregation of another work not based on the Program
418 with the Program (or with a work based on the Program) on a volume of
419 a storage or distribution medium does not bring the other work under
420 the scope of this License.
423 You may copy and distribute the Program (or a work based on it,
424 under Section 2) in object code or executable form under the terms of
425 Sections 1 and 2 above provided that you also do one of the following:
429 Accompany it with the complete corresponding machine-readable
430 source code, which must be distributed under the terms of Sections
431 1 and 2 above on a medium customarily used for software interchange; or,
434 Accompany it with a written offer, valid for at least three
435 years, to give any third party, for a charge no more than your
436 cost of physically performing source distribution, a complete
437 machine-readable copy of the corresponding source code, to be
438 distributed under the terms of Sections 1 and 2 above on a medium
439 customarily used for software interchange; or,
442 Accompany it with the information you received as to the offer
443 to distribute corresponding source code. (This alternative is
444 allowed only for noncommercial distribution and only if you
445 received the program in object code or executable form with such
446 an offer, in accord with Subsection b above.)
449 The source code for a work means the preferred form of the work for
450 making modifications to it. For an executable work, complete source
451 code means all the source code for all modules it contains, plus any
452 associated interface definition files, plus the scripts used to
453 control compilation and installation of the executable. However, as a
454 special exception, the source code distributed need not include
455 anything that is normally distributed (in either source or binary
456 form) with the major components (compiler, kernel, and so on) of the
457 operating system on which the executable runs, unless that component
458 itself accompanies the executable.
460 If distribution of executable or object code is made by offering
461 access to copy from a designated place, then offering equivalent
462 access to copy the source code from the same place counts as
463 distribution of the source code, even though third parties are not
464 compelled to copy the source along with the object code.
467 You may not copy, modify, sublicense, or distribute the Program
468 except as expressly provided under this License. Any attempt
469 otherwise to copy, modify, sublicense or distribute the Program is
470 void, and will automatically terminate your rights under this License.
471 However, parties who have received copies, or rights, from you under
472 this License will not have their licenses terminated so long as such
473 parties remain in full compliance.
476 You are not required to accept this License, since you have not
477 signed it. However, nothing else grants you permission to modify or
478 distribute the Program or its derivative works. These actions are
479 prohibited by law if you do not accept this License. Therefore, by
480 modifying or distributing the Program (or any work based on the
481 Program), you indicate your acceptance of this License to do so, and
482 all its terms and conditions for copying, distributing or modifying
483 the Program or works based on it.
486 Each time you redistribute the Program (or any work based on the
487 Program), the recipient automatically receives a license from the
488 original licensor to copy, distribute or modify the Program subject to
489 these terms and conditions. You may not impose any further
490 restrictions on the recipients' exercise of the rights granted herein.
491 You are not responsible for enforcing compliance by third parties to
495 If, as a consequence of a court judgment or allegation of patent
496 infringement or for any other reason (not limited to patent issues),
497 conditions are imposed on you (whether by court order, agreement or
498 otherwise) that contradict the conditions of this License, they do not
499 excuse you from the conditions of this License. If you cannot
500 distribute so as to satisfy simultaneously your obligations under this
501 License and any other pertinent obligations, then as a consequence you
502 may not distribute the Program at all. For example, if a patent
503 license would not permit royalty-free redistribution of the Program by
504 all those who receive copies directly or indirectly through you, then
505 the only way you could satisfy both it and this License would be to
506 refrain entirely from distribution of the Program.
508 If any portion of this section is held invalid or unenforceable under
509 any particular circumstance, the balance of the section is intended to
510 apply and the section as a whole is intended to apply in other
513 It is not the purpose of this section to induce you to infringe any
514 patents or other property right claims or to contest validity of any
515 such claims; this section has the sole purpose of protecting the
516 integrity of the free software distribution system, which is
517 implemented by public license practices. Many people have made
518 generous contributions to the wide range of software distributed
519 through that system in reliance on consistent application of that
520 system; it is up to the author/donor to decide if he or she is willing
521 to distribute software through any other system and a licensee cannot
524 This section is intended to make thoroughly clear what is believed to
525 be a consequence of the rest of this License.
528 If the distribution and/or use of the Program is restricted in
529 certain countries either by patents or by copyrighted interfaces, the
530 original copyright holder who places the Program under this License
531 may add an explicit geographical distribution limitation excluding
532 those countries, so that distribution is permitted only in or among
533 countries not thus excluded. In such case, this License incorporates
534 the limitation as if written in the body of this License.
537 The Free Software Foundation may publish revised and/or new versions
538 of the General Public License from time to time. Such new versions will
539 be similar in spirit to the present version, but may differ in detail to
540 address new problems or concerns.
542 Each version is given a distinguishing version number. If the Program
543 specifies a version number of this License which applies to it and ``any
544 later version'', you have the option of following the terms and conditions
545 either of that version or of any later version published by the Free
546 Software Foundation. If the Program does not specify a version number of
547 this License, you may choose any version ever published by the Free Software
551 If you wish to incorporate parts of the Program into other free
552 programs whose distribution conditions are different, write to the author
553 to ask for permission. For software which is copyrighted by the Free
554 Software Foundation, write to the Free Software Foundation; we sometimes
555 make exceptions for this. Our decision will be guided by the two goals
556 of preserving the free status of all derivatives of our free software and
557 of promoting the sharing and reuse of software generally.
567 BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY
568 FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN
569 OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES
570 PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED
571 OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
572 MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS
573 TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE
574 PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING,
575 REPAIR OR CORRECTION.
578 IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
579 WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR
580 REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
581 INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING
582 OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED
583 TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY
584 YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
585 PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE
586 POSSIBILITY OF SUCH DAMAGES.
590 @heading END OF TERMS AND CONDITIONS
593 @center END OF TERMS AND CONDITIONS
597 @unnumberedsec How to Apply These Terms to Your New Programs
599 If you develop a new program, and you want it to be of the greatest
600 possible use to the public, the best way to achieve this is to make it
601 free software which everyone can redistribute and change under these terms.
603 To do so, attach the following notices to the program. It is safest
604 to attach them to the start of each source file to most effectively
605 convey the exclusion of warranty; and each file should have at least
606 the ``copyright'' line and a pointer to where the full notice is found.
609 @var{one line to give the program's name and a brief idea of what it does.}
610 Copyright (C) 19@var{yy} @var{name of author}
612 This program is free software; you can redistribute it and/or modify
613 it under the terms of the GNU General Public License as published by
614 the Free Software Foundation; either version 2 of the License, or
615 (at your option) any later version.
617 This program is distributed in the hope that it will be useful,
618 but WITHOUT ANY WARRANTY; without even the implied warranty of
619 MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
620 GNU General Public License for more details.
622 You should have received a copy of the GNU General Public License
623 along with this program; if not, write to the Free Software
624 Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
627 Also add information on how to contact you by electronic and paper mail.
629 If the program is interactive, make it output a short notice like this
630 when it starts in an interactive mode:
633 Gnomovision version 69, Copyright (C) 19@var{yy} @var{name of author}
634 Gnomovision comes with ABSOLUTELY NO WARRANTY; for details
636 This is free software, and you are welcome to redistribute it
637 under certain conditions; type `show c' for details.
640 The hypothetical commands @samp{show w} and @samp{show c} should show
641 the appropriate parts of the General Public License. Of course, the
642 commands you use may be called something other than @samp{show w} and
643 @samp{show c}; they could even be mouse-clicks or menu items---whatever
646 You should also get your employer (if you work as a programmer) or your
647 school, if any, to sign a ``copyright disclaimer'' for the program, if
648 necessary. Here is a sample; alter the names:
651 Yoyodyne, Inc., hereby disclaims all copyright interest in the program
652 `Gnomovision' (which makes passes at compilers) written by James Hacker.
654 @var{signature of Ty Coon}, 1 April 1989
655 Ty Coon, President of Vice
658 This General Public License does not permit incorporating your program into
659 proprietary programs. If your program is a subroutine library, you may
660 consider it more useful to permit linking proprietary applications with the
661 library. If this is what you want to do, use the GNU Library General
662 Public License instead of this License.
665 @unnumbered Contributors to GNU Fortran
669 In addition to James Craig Burley, who wrote the front end,
670 many people have helped create and improve GNU Fortran.
674 The packaging and compiler portions of GNU Fortran are based largely
675 on the GNU CC compiler.
676 @xref{Contributors,,Contributors to GNU CC,gcc,Using and Porting GNU CC},
677 for more information.
680 The run-time library used by GNU Fortran is a repackaged version
681 of the @code{libf2c} library (combined from the @code{libF77} and
682 @code{libI77} libraries) provided as part of @code{f2c}, available for
683 free from @code{netlib} sites on the Internet.
686 Cygnus Support and The Free Software Foundation contributed
687 significant money and/or equipment to Craig's efforts.
690 The following individuals served as alpha testers prior to @code{g77}'s
691 public release. This work consisted of testing, researching, sometimes
692 debugging, and occasionally providing small amounts of code and fixes
693 for @code{g77}, plus offering plenty of helpful advice to Craig:
699 Dr.@: Mark Fernyhough
701 Takafumi Hayashi (The University of Aizu)---@email{takafumi@@u-aizu.ac.jp}
705 Michel Kern (INRIA and Rice University)---@email{Michel.Kern@@inria.fr}
707 Dr.@: A. O. V. Le Blanc
729 Scott Snyder (@email{snyder@@d0sgif.fnal.gov})
730 provided the patch to add rudimentary support
731 for @code{INTEGER*1}, @code{INTEGER*2}, and
733 This inspired Craig to add further support,
734 even though the resulting support
735 would still be incomplete, because version 0.6 is still
739 David Ronis (@email{ronis@@onsager.chem.mcgill.ca}) inspired
740 and encouraged Craig to rewrite the documentation in texinfo
741 format by contributing a first pass at a translation of the
742 old @file{g77-0.5.16/f/DOC} file.
745 Toon Moene (@email{toon@@moene.indiv.nluug.nl}) performed
746 some analysis of generated code as part of an overall project
747 to improve @code{g77} code generation to at least be as good
748 as @code{f2c} used in conjunction with @code{gcc}.
749 So far, this has resulted in the three, somewhat
750 experimental, options added by @code{g77} to the @code{gcc}
751 compiler and its back end.
753 (These, in turn, have made their way into the @code{egcs}
754 version of the compiler, and do not exist in @code{gcc}
755 version 2.8 or versions of @code{g77} based on that version
759 John Carr (@email{jfc@@mit.edu}) wrote the alias analysis improvements.
762 Thanks to Mary Cortani and the staff at Craftwork Solutions
763 (@email{support@@craftwork.com}) for all of their support.
766 Many other individuals have helped debug, test, and improve @code{g77}
767 over the past several years, and undoubtedly more people
768 will be doing so in the future.
769 If you have done so, and would like
770 to see your name listed in the above list, please ask!
771 The default is that people wish to remain anonymous.
775 @chapter Funding Free Software
777 If you want to have more free software a few years from now, it makes
778 sense for you to help encourage people to contribute funds for its
779 development. The most effective approach known is to encourage
780 commercial redistributors to donate.
782 Users of free software systems can boost the pace of development by
783 encouraging for-a-fee distributors to donate part of their selling price
784 to free software developers---the Free Software Foundation, and others.
786 The way to convince distributors to do this is to demand it and expect
787 it from them. So when you compare distributors, judge them partly by
788 how much they give to free software development. Show distributors
789 they must compete to be the one who gives the most.
791 To make this approach work, you must insist on numbers that you can
792 compare, such as, ``We will donate ten dollars to the Frobnitz project
793 for each disk sold.'' Don't be satisfied with a vague promise, such as
794 ``A portion of the profits are donated,'' since it doesn't give a basis
797 Even a precise fraction ``of the profits from this disk'' is not very
798 meaningful, since creative accounting and unrelated business decisions
799 can greatly alter what fraction of the sales price counts as profit.
800 If the price you pay is $50, ten percent of the profit is probably
801 less than a dollar; it might be a few cents, or nothing at all.
803 Some redistributors do development work themselves. This is useful too;
804 but to keep everyone honest, you need to inquire how much they do, and
805 what kind. Some kinds of development make much more long-term
806 difference than others. For example, maintaining a separate version of
807 a program contributes very little; maintaining the standard version of a
808 program for the whole community contributes much. Easy new ports
809 contribute little, since someone else would surely do them; difficult
810 ports such as adding a new CPU to the GNU C compiler contribute more;
811 major new features or packages contribute the most.
813 By establishing the idea that supporting further development is ``the
814 proper thing to do'' when distributing free software for a fee, we can
815 assure a steady flow of resources into making more free software.
818 Copyright (C) 1994 Free Software Foundation, Inc.
819 Verbatim copying and redistribution of this section is permitted
820 without royalty; alteration is not permitted.
823 @node Funding GNU Fortran
824 @chapter Funding GNU Fortran
825 @cindex funding improvements
826 @cindex improvements, funding
828 Work on GNU Fortran is still being done mostly by its author,
829 James Craig Burley (@email{@value{email-burley}}), who is a volunteer
830 for, not an employee of, the Free Software Foundation (FSF).
831 (He has a web page at @uref{@value{www-burley}}.)
833 As with other GNU software, funding is important because it can pay for
834 needed equipment, personnel, and so on.
836 @cindex FSF, funding the
837 @cindex funding the FSF
838 The FSF provides information on the best way to fund ongoing
839 development of GNU software (such as GNU Fortran) in documents
840 such as the ``GNUS Bulletin''.
841 Email @email{gnu@@gnu.org} for information on funding the FSF.
843 To fund specific GNU Fortran work in particular, the FSF might
844 provide a means for that, but the FSF does not provide direct funding
845 to the author of GNU Fortran to continue his work. The FSF has
846 employee salary restrictions that can be incompatible with the
847 financial needs of some volunteers, who therefore choose to
848 remain volunteers and thus be able to be free to do contract work
849 and otherwise make their own schedules for doing GNU work.
851 Still, funding the FSF at least indirectly benefits work
852 on specific projects like GNU Fortran because it ensures the
853 continuing operation of the FSF offices, their workstations, their
854 network connections, and so on, which are invaluable to volunteers.
855 (Similarly, hiring Cygnus Support can help a project like GNU
856 Fortran---Cygnus has been a long-time donor of equipment usage to the author
857 of GNU Fortran, and this too has been invaluable---@xref{Contributors}.)
859 Currently, the only way to directly fund the author of GNU Fortran
860 in his work on that project is to hire him for the work you want
861 him to do, or donate money to him.
862 Several people have done this
863 already, with the result that he has not needed to immediately find
864 contract work on a few occasions.
865 If more people did this, he
866 would be able to plan on not doing contract work for many months and
867 could thus devote that time to work on projects (such as the planned
868 changes for 0.6) that require longer timeframes to complete.
869 For the latest information on the status of the author, do
870 @kbd{finger -l burley@@gnu.org} on a UNIX system
871 (or any system with a command like UNIX @code{finger}).
873 Another important way to support work on GNU Fortran is to volunteer
875 Work is needed on documentation, testing, porting
876 to various machines, and in some cases, coding (although major
877 changes planned for version 0.6 make it difficult to add manpower to this
879 Email @email{@value{email-general}} to volunteer for this work.
881 @xref{Funding,,Funding Free Software}, for more information.
884 @chapter Protect Your Freedom---Fight ``Look And Feel''
885 @c the above chapter heading overflows onto the next line. --mew 1/26/93
887 To preserve the ability to write free software, including replacements
888 for proprietary software, authors must be free to replicate the
889 user interface to which users of existing software have become
892 @xref{Look and Feel,,Protect Your Freedom---Fight ``Look And Feel'',
893 gcc,Using and Porting GNU CC}, for more information.
895 @node Getting Started
896 @chapter Getting Started
897 @cindex getting started
902 If you don't need help getting started reading the portions
903 of this manual that are most important to you, you should skip
904 this portion of the manual.
906 If you are new to compilers, especially Fortran compilers, or
907 new to how compilers are structured under UNIX and UNIX-like
908 systems, you'll want to see @ref{What is GNU Fortran?}.
910 If you are new to GNU compilers, or have used only one GNU
911 compiler in the past and not had to delve into how it lets
912 you manage various versions and configurations of @code{gcc},
913 you should see @ref{G77 and GCC}.
915 Everyone except experienced @code{g77} users should
916 see @ref{Invoking G77}.
918 If you're acquainted with previous versions of @code{g77},
919 you should see @ref{News,,News About GNU Fortran}.
920 Further, if you've actually used previous versions of @code{g77},
921 especially if you've written or modified Fortran code to
922 be compiled by previous versions of @code{g77}, you
923 should see @ref{Changes}.
925 If you intend to write or otherwise compile code that is
926 not already strictly conforming ANSI FORTRAN 77---and this
927 is probably everyone---you should see @ref{Language}.
929 If you don't already have @code{g77} installed on your
930 system, you must see @ref{Installation}.
932 If you run into trouble getting Fortran code to compile,
933 link, run, or work properly, you might find answers
934 if you see @ref{Debugging and Interfacing},
935 see @ref{Collected Fortran Wisdom},
936 and see @ref{Trouble}.
937 You might also find that the problems you are encountering
938 are bugs in @code{g77}---see @ref{Bugs}, for information on
939 reporting them, after reading the other material.
941 If you need further help with @code{g77}, or with
942 freely redistributable software in general,
945 If you would like to help the @code{g77} project,
946 see @ref{Funding GNU Fortran}, for information on
947 helping financially, and see @ref{Projects}, for information
948 on helping in other ways.
950 If you're generally curious about the future of
951 @code{g77}, see @ref{Projects}.
952 If you're curious about its past,
953 see @ref{Contributors},
954 and see @ref{Funding GNU Fortran}.
956 To see a few of the questions maintainers of @code{g77} have,
957 and that you might be able to answer,
958 see @ref{Open Questions}.
961 @node What is GNU Fortran?
962 @chapter What is GNU Fortran?
963 @cindex concepts, basic
964 @cindex basic concepts
966 GNU Fortran, or @code{g77}, is designed initially as a free replacement
967 for, or alternative to, the UNIX @code{f77} command.
968 (Similarly, @code{gcc} is designed as a replacement
969 for the UNIX @code{cc} command.)
971 @code{g77} also is designed to fit in well with the other
972 fine GNU compilers and tools.
974 Sometimes these design goals conflict---in such cases, resolution
975 often is made in favor of fitting in well with Project GNU.
976 These cases are usually identified in the appropriate
977 sections of this manual.
980 As compilers, @code{g77}, @code{gcc}, and @code{f77}
981 share the following characteristics:
989 They read a user's program, stored in a file and
990 containing instructions written in the appropriate
991 language (Fortran, C, and so on).
992 This file contains @dfn{source code}.
994 @cindex translation of user programs
996 @cindex code, machine
999 They translate the user's program into instructions
1000 a computer can carry out more quickly than it takes
1001 to translate the instructions in the first place.
1002 These instructions are called @dfn{machine code}---code
1003 designed to be efficiently translated and processed
1004 by a machine such as a computer.
1005 Humans usually aren't as good writing machine code
1006 as they are at writing Fortran or C, because
1007 it is easy to make tiny mistakes writing machine code.
1008 When writing Fortran or C, it is easy
1009 to make big mistakes.
1012 @cindex bugs, finding
1013 @cindex @code{gdb}, command
1014 @cindex commands, @code{gdb}
1016 They provide information in the generated machine code
1017 that can make it easier to find bugs in the program
1018 (using a debugging tool, called a @dfn{debugger},
1019 such as @code{gdb}).
1023 @cindex @code{ld} command
1024 @cindex commands, @code{ld}
1026 They locate and gather machine code already generated
1027 to perform actions requested by statements in
1029 This machine code is organized
1030 into @dfn{libraries} and is located and gathered
1031 during the @dfn{link} phase of the compilation
1033 (Linking often is thought of as a separate
1034 step, because it can be directly invoked via the
1036 However, the @code{g77} and @code{gcc}
1037 commands, as with most compiler commands, automatically
1038 perform the linking step by calling on @code{ld}
1039 directly, unless asked to not do so by the user.)
1041 @cindex language, incorrect use of
1042 @cindex incorrect use of language
1044 They attempt to diagnose cases where the user's
1045 program contains incorrect usages of the language.
1046 The @dfn{diagnostics} produced by the compiler
1047 indicate the problem and the location in the user's
1048 source file where the problem was first noticed.
1049 The user can use this information to locate and
1051 @cindex diagnostics, incorrect
1052 @cindex incorrect diagnostics
1053 @cindex error messages, incorrect
1054 @cindex incorrect error messages
1055 (Sometimes an incorrect usage
1056 of the language leads to a situation where the
1057 compiler can no longer make any sense of what
1058 follows---while a human might be able to---and
1059 thus ends up complaining about many ``problems''
1060 it encounters that, in fact, stem from just one
1061 problem, usually the first one reported.)
1064 @cindex questionable instructions
1066 They attempt to diagnose cases where the user's
1067 program contains a correct usage of the language,
1068 but instructs the computer to do something questionable.
1069 These diagnostics often are in the form of @dfn{warnings},
1070 instead of the @dfn{errors} that indicate incorrect
1071 usage of the language.
1074 How these actions are performed is generally under the
1075 control of the user.
1076 Using command-line options, the user can specify
1077 how persnickety the compiler is to be regarding
1078 the program (whether to diagnose questionable usage
1079 of the language), how much time to spend making
1080 the generated machine code run faster, and so on.
1082 @cindex components of g77
1083 @cindex @code{g77}, components of
1084 @code{g77} consists of several components:
1086 @cindex @code{gcc}, command
1087 @cindex commands, @code{gcc}
1090 A modified version of the @code{gcc} command, which also might be
1091 installed as the system's @code{cc} command.
1092 (In many cases, @code{cc} refers to the
1093 system's ``native'' C compiler, which
1094 might be a non-GNU compiler, or an older version
1095 of @code{gcc} considered more stable or that is
1096 used to build the operating system kernel.)
1098 @cindex @code{g77}, command
1099 @cindex commands, @code{g77}
1101 The @code{g77} command itself, which also might be installed as the
1102 system's @code{f77} command.
1104 @cindex libg2c library
1105 @cindex libf2c library
1106 @cindex libraries, libf2c
1107 @cindex libraries, libg2c
1108 @cindex run-time, library
1110 The @code{libg2c} run-time library.
1111 This library contains the machine code needed to support
1112 capabilities of the Fortran language that are not directly
1113 provided by the machine code generated by the @code{g77}
1116 @code{libg2c} is just the unique name @code{g77} gives
1117 to its version of @code{libf2c} to distinguish it from
1118 any copy of @code{libf2c} installed from @code{f2c}
1119 (or versions of @code{g77} that built @code{libf2c} under
1123 The maintainer of @code{libf2c} currently is
1124 @email{dmg@@bell-labs.com}.
1126 @cindex @code{f771}, program
1127 @cindex programs, @code{f771}
1129 @cindex @code{as} command
1130 @cindex commands, @code{as}
1131 @cindex assembly code
1132 @cindex code, assembly
1134 The compiler itself, internally named @code{f771}.
1136 Note that @code{f771} does not generate machine code directly---it
1137 generates @dfn{assembly code} that is a more readable form
1138 of machine code, leaving the conversion to actual machine code
1139 to an @dfn{assembler}, usually named @code{as}.
1142 @code{gcc} is often thought of as ``the C compiler'' only,
1143 but it does more than that.
1144 Based on command-line options and the names given for files
1145 on the command line, @code{gcc} determines which actions to perform, including
1146 preprocessing, compiling (in a variety of possible languages), assembling,
1149 @cindex driver, gcc command as
1150 @cindex @code{gcc}, command as driver
1151 @cindex executable file
1152 @cindex files, executable
1154 @cindex programs, cc1
1155 @cindex preprocessor
1157 @cindex programs, cpp
1158 For example, the command @samp{gcc foo.c} @dfn{drives} the file
1159 @file{foo.c} through the preprocessor @code{cpp}, then
1160 the C compiler (internally named
1161 @code{cc1}), then the assembler (usually @code{as}), then the linker
1162 (@code{ld}), producing an executable program named @file{a.out} (on
1165 @cindex cc1plus program
1166 @cindex programs, cc1plus
1167 As another example, the command @samp{gcc foo.cc} would do much the same as
1168 @samp{gcc foo.c}, but instead of using the C compiler named @code{cc1},
1169 @code{gcc} would use the C++ compiler (named @code{cc1plus}).
1171 @cindex @code{f771}, program
1172 @cindex programs, @code{f771}
1173 In a GNU Fortran installation, @code{gcc} recognizes Fortran source
1174 files by name just like it does C and C++ source files.
1175 It knows to use the Fortran compiler named @code{f771}, instead of
1176 @code{cc1} or @code{cc1plus}, to compile Fortran files.
1178 @cindex @code{gcc}, not recognizing Fortran source
1179 @cindex unrecognized file format
1180 @cindex file format not recognized
1181 Non-Fortran-related operation of @code{gcc} is generally
1182 unaffected by installing the GNU Fortran version of @code{gcc}.
1183 However, without the installed version of @code{gcc} being the
1184 GNU Fortran version, @code{gcc} will not be able to compile
1185 and link Fortran programs---and since @code{g77} uses @code{gcc}
1186 to do most of the actual work, neither will @code{g77}!
1188 @cindex @code{g77}, command
1189 @cindex commands, @code{g77}
1190 The @code{g77} command is essentially just a front-end for
1191 the @code{gcc} command.
1192 Fortran users will normally use @code{g77} instead of @code{gcc},
1194 knows how to specify the libraries needed to link with Fortran programs
1195 (@code{libg2c} and @code{lm}).
1196 @code{g77} can still compile and link programs and
1197 source files written in other languages, just like @code{gcc}.
1199 @cindex printing version information
1200 @cindex version information, printing
1201 The command @samp{g77 -v} is a quick
1202 way to display lots of version information for the various programs
1203 used to compile a typical preprocessed Fortran source file---this
1204 produces much more output than @samp{gcc -v} currently does.
1205 (If it produces an error message near the end of the output---diagnostics
1206 from the linker, usually @code{ld}---you might
1207 have an out-of-date @code{libf2c} that improperly handles
1208 complex arithmetic.)
1209 In the output of this command, the line beginning @samp{GNU Fortran Front
1210 End} identifies the version number of GNU Fortran; immediately
1211 preceding that line is a line identifying the version of @code{gcc}
1212 with which that version of @code{g77} was built.
1214 @cindex libf2c library
1215 @cindex libraries, libf2c
1216 The @code{libf2c} library is distributed with GNU Fortran for
1217 the convenience of its users, but is not part of GNU Fortran.
1218 It contains the procedures
1219 needed by Fortran programs while they are running.
1221 @cindex in-line code
1222 @cindex code, in-line
1223 For example, while code generated by @code{g77} is likely
1224 to do additions, subtractions, and multiplications @dfn{in line}---in
1225 the actual compiled code---it is not likely to do trigonometric
1228 Instead, operations like trigonometric
1229 functions are compiled by the @code{f771} compiler
1230 (invoked by @code{g77} when compiling Fortran code) into machine
1231 code that, when run, calls on functions in @code{libg2c}, so
1232 @code{libg2c} must be linked with almost every useful program
1233 having any component compiled by GNU Fortran.
1234 (As mentioned above, the @code{g77} command takes
1235 care of all this for you.)
1237 The @code{f771} program represents most of what is unique to GNU Fortran.
1238 While much of the @code{libg2c} component comes from
1239 the @code{libf2c} component of @code{f2c},
1240 a free Fortran-to-C converter distributed by Bellcore (AT&T),
1241 plus @code{libU77}, provided by Dave Love,
1242 and the @code{g77} command is just a small front-end to @code{gcc},
1243 @code{f771} is a combination of two rather
1244 large chunks of code.
1246 @cindex GNU Back End (GBE)
1248 @cindex @code{gcc}, back end
1249 @cindex back end, gcc
1250 @cindex code generator
1251 One chunk is the so-called @dfn{GNU Back End}, or GBE,
1252 which knows how to generate fast code for a wide variety of processors.
1253 The same GBE is used by the C, C++, and Fortran compiler programs @code{cc1},
1254 @code{cc1plus}, and @code{f771}, plus others.
1255 Often the GBE is referred to as the ``gcc back end'' or
1256 even just ``gcc''---in this manual, the term GBE is used
1257 whenever the distinction is important.
1259 @cindex GNU Fortran Front End (FFE)
1261 @cindex @code{g77}, front end
1262 @cindex front end, g77
1263 The other chunk of @code{f771} is the
1264 majority of what is unique about GNU Fortran---the code that knows how
1265 to interpret Fortran programs to determine what they are intending to
1266 do, and then communicate that knowledge to the GBE for actual compilation
1268 This chunk is called the @dfn{Fortran Front End} (FFE).
1269 The @code{cc1} and @code{cc1plus} programs have their own front ends,
1270 for the C and C++ languages, respectively.
1271 These fronts ends are responsible for diagnosing
1272 incorrect usage of their respective languages by the
1273 programs the process, and are responsible for most of
1274 the warnings about questionable constructs as well.
1275 (The GBE handles producing some warnings, like those
1276 concerning possible references to undefined variables.)
1278 Because so much is shared among the compilers for various languages,
1279 much of the behavior and many of the user-selectable options for these
1280 compilers are similar.
1281 For example, diagnostics (error messages and
1282 warnings) are similar in appearance; command-line
1283 options like @samp{-Wall} have generally similar effects; and the quality
1284 of generated code (in terms of speed and size) is roughly similar
1285 (since that work is done by the shared GBE).
1288 @chapter Compile Fortran, C, or Other Programs
1289 @cindex compiling programs
1290 @cindex programs, compiling
1292 @cindex @code{gcc}, command
1293 @cindex commands, @code{gcc}
1294 A GNU Fortran installation includes a modified version of the @code{gcc}
1297 In a non-Fortran installation, @code{gcc} recognizes C, C++,
1298 and Objective-C source files.
1300 In a GNU Fortran installation, @code{gcc} also recognizes Fortran source
1301 files and accepts Fortran-specific command-line options, plus some
1302 command-line options that are designed to cater to Fortran users
1303 but apply to other languages as well.
1305 @xref{G++ and GCC,,Compile C; C++; or Objective-C,gcc,Using and Porting GNU CC},
1306 for information on the way different languages are handled
1307 by the GNU CC compiler (@code{gcc}).
1309 @cindex @code{g77}, command
1310 @cindex commands, @code{g77}
1311 Also provided as part of GNU Fortran is the @code{g77} command.
1312 The @code{g77} command is designed to make compiling and linking Fortran
1313 programs somewhat easier than when using the @code{gcc} command for
1315 It does this by analyzing the command line somewhat and changing it
1316 appropriately before submitting it to the @code{gcc} command.
1319 @cindex @code{g77} options, -v
1321 Use the @samp{-v} option with @code{g77}
1322 to see what is going on---the first line of output is the invocation
1323 of the @code{gcc} command.
1326 @chapter GNU Fortran Command Options
1327 @cindex GNU Fortran command options
1328 @cindex command options
1329 @cindex options, GNU Fortran command
1331 The @code{g77} command supports all the options supported by the
1333 @xref{Invoking GCC,,GNU CC Command Options,gcc,Using and Porting GNU CC},
1335 on the non-Fortran-specific aspects of the @code{gcc} command (and,
1336 therefore, the @code{g77} command).
1338 @cindex options, negative forms
1339 @cindex negative forms of options
1340 All @code{gcc} and @code{g77} options
1341 are accepted both by @code{g77} and by @code{gcc}
1342 (as well as any other drivers built at the same time,
1343 such as @code{g++}),
1344 since adding @code{g77} to the @code{gcc} distribution
1345 enables acceptance of @code{g77}-specific options
1346 by all of the relevant drivers.
1348 In some cases, options have positive and negative forms;
1349 the negative form of @samp{-ffoo} would be @samp{-fno-foo}.
1350 This manual documents only one of these two forms, whichever
1351 one is not the default.
1354 * Option Summary:: Brief list of all @code{g77} options,
1355 without explanations.
1356 * Overall Options:: Controlling the kind of output:
1357 an executable, object files, assembler files,
1358 or preprocessed source.
1359 * Shorthand Options:: Options that are shorthand for other options.
1360 * Fortran Dialect Options:: Controlling the variant of Fortran language
1362 * Warning Options:: How picky should the compiler be?
1363 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1364 * Optimize Options:: How much optimization?
1365 * Preprocessor Options:: Controlling header files and macro definitions.
1366 Also, getting dependency information for Make.
1367 * Directory Options:: Where to find header files and libraries.
1368 Where to find the compiler executable files.
1369 * Code Gen Options:: Specifying conventions for function calls, data layout
1371 * Environment Variables:: Env vars that affect GNU Fortran.
1374 @node Option Summary
1375 @section Option Summary
1377 Here is a summary of all the options specific to GNU Fortran, grouped
1378 by type. Explanations are in the following sections.
1381 @item Overall Options
1382 @xref{Overall Options,,Options Controlling the Kind of Output}.
1384 -fversion -fset-g77-defaults -fno-silent
1387 @item Shorthand Options
1388 @xref{Shorthand Options}.
1390 -ff66 -fno-f66 -ff77 -fno-f77 -fugly -fno-ugly
1393 @item Fortran Language Options
1394 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect}.
1396 -ffree-form -fno-fixed-form -ff90
1397 -fvxt -fdollar-ok -fno-backslash
1398 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1399 -fugly-comma -fugly-complex -fugly-init -fugly-logint
1400 -fonetrip -ftypeless-boz
1401 -fintrin-case-initcap -fintrin-case-upper
1402 -fintrin-case-lower -fintrin-case-any
1403 -fmatch-case-initcap -fmatch-case-upper
1404 -fmatch-case-lower -fmatch-case-any
1405 -fsource-case-upper -fsource-case-lower -fsource-case-preserve
1406 -fsymbol-case-initcap -fsymbol-case-upper
1407 -fsymbol-case-lower -fsymbol-case-any
1408 -fcase-strict-upper -fcase-strict-lower
1409 -fcase-initcap -fcase-upper -fcase-lower -fcase-preserve
1410 -ff2c-intrinsics-delete -ff2c-intrinsics-hide
1411 -ff2c-intrinsics-disable -ff2c-intrinsics-enable
1412 -fbadu77-intrinsics-delete -fbadu77-intrinsics-hide
1413 -fbadu77-intrinsics-disable -fbadu77-intrinsics-enable
1414 -ff90-intrinsics-delete -ff90-intrinsics-hide
1415 -ff90-intrinsics-disable -ff90-intrinsics-enable
1416 -fgnu-intrinsics-delete -fgnu-intrinsics-hide
1417 -fgnu-intrinsics-disable -fgnu-intrinsics-enable
1418 -fmil-intrinsics-delete -fmil-intrinsics-hide
1419 -fmil-intrinsics-disable -fmil-intrinsics-enable
1420 -funix-intrinsics-delete -funix-intrinsics-hide
1421 -funix-intrinsics-disable -funix-intrinsics-enable
1422 -fvxt-intrinsics-delete -fvxt-intrinsics-hide
1423 -fvxt-intrinsics-disable -fvxt-intrinsics-enable
1424 -ffixed-line-length-@var{n} -ffixed-line-length-none
1427 @item Warning Options
1428 @xref{Warning Options,,Options to Request or Suppress Warnings}.
1430 -fsyntax-only -pedantic -pedantic-errors -fpedantic
1431 -w -Wno-globals -Wimplicit -Wunused -Wuninitialized
1436 @item Debugging Options
1437 @xref{Debugging Options,,Options for Debugging Your Program or GCC}.
1442 @item Optimization Options
1443 @xref{Optimize Options,,Options that Control Optimization}.
1446 -ffloat-store -fforce-mem -fforce-addr -fno-inline
1447 -ffast-math -fstrength-reduce -frerun-cse-after-loop
1448 -fexpensive-optimizations -fdelayed-branch
1449 -fschedule-insns -fschedule-insn2 -fcaller-saves
1450 -funroll-loops -funroll-all-loops
1451 -fno-move-all-movables -fno-reduce-all-givs
1455 @item Directory Options
1456 @xref{Directory Options,,Options for Directory Search}.
1461 @item Code Generation Options
1462 @xref{Code Gen Options,,Options for Code Generation Conventions}.
1464 -fno-automatic -finit-local-zero -fno-f2c
1465 -ff2c-library -fno-underscoring -fno-ident
1466 -fpcc-struct-return -freg-struct-return
1467 -fshort-double -fno-common -fpack-struct
1468 -fzeros -fno-second-underscore
1469 -fdebug-kludge -femulate-complex
1470 -falias-check -fargument-alias
1471 -fargument-noalias -fno-argument-noalias-global
1477 * Overall Options:: Controlling the kind of output:
1478 an executable, object files, assembler files,
1479 or preprocessed source.
1480 * Shorthand Options:: Options that are shorthand for other options.
1481 * Fortran Dialect Options:: Controlling the variant of Fortran language
1483 * Warning Options:: How picky should the compiler be?
1484 * Debugging Options:: Symbol tables, measurements, and debugging dumps.
1485 * Optimize Options:: How much optimization?
1486 * Preprocessor Options:: Controlling header files and macro definitions.
1487 Also, getting dependency information for Make.
1488 * Directory Options:: Where to find header files and libraries.
1489 Where to find the compiler executable files.
1490 * Code Gen Options:: Specifying conventions for function calls, data layout
1494 @node Overall Options
1495 @section Options Controlling the Kind of Output
1496 @cindex overall options
1497 @cindex options, overall
1499 Compilation can involve as many as four stages: preprocessing, code
1500 generation (often what is really meant by the term ``compilation''),
1501 assembly, and linking, always in that order. The first three
1502 stages apply to an individual source file, and end by producing an
1503 object file; linking combines all the object files (those newly
1504 compiled, and those specified as input) into an executable file.
1506 @cindex file name suffix
1507 @cindex suffixes, file name
1508 @cindex file name extension
1509 @cindex extensions, file name
1512 For any given input file, the file name suffix determines what kind of
1513 program is contained in the file---that is, the language in which the
1514 program is written is generally indicated by the suffix.
1515 Suffixes specific to GNU Fortran are listed below.
1516 @xref{Overall Options,,gcc,Using and Porting GNU CC}, for
1517 information on suffixes recognized by GNU CC.
1520 @cindex .f filename suffix
1521 @cindex .for filename suffix
1522 @cindex .FOR filename suffix
1524 @item @var{file}.for
1525 @item @var{file}.FOR
1526 Fortran source code that should not be preprocessed.
1528 Such source code cannot contain any preprocessor directives, such
1529 as @code{#include}, @code{#define}, @code{#if}, and so on.
1531 You can force @samp{.f} files to be preprocessed by @samp{cpp} by using
1532 @samp{-x f77-cpp-input}.
1535 @cindex preprocessor
1536 @cindex C preprocessor
1537 @cindex cpp preprocessor
1538 @cindex Fortran preprocessor
1540 @cindex programs, cpp
1541 @cindex .F filename suffix
1542 @cindex .fpp filename suffix
1543 @cindex .FPP filename suffix
1545 @item @var{file}.fpp
1546 @item @var{file}.FPP
1547 Fortran source code that must be preprocessed (by the C preprocessor
1548 @code{cpp}, which is part of GNU CC).
1550 Note that preprocessing is not extended to the contents of
1551 files included by the @code{INCLUDE} directive---the @code{#include}
1552 preprocessor directive must be used instead.
1554 @cindex Ratfor preprocessor
1555 @cindex programs, @code{ratfor}
1556 @cindex @samp{.r} filename suffix
1557 @cindex @code{ratfor}
1559 Ratfor source code, which must be preprocessed by the @code{ratfor}
1560 command, which is available separately (as it is not yet part of the GNU
1561 Fortran distribution).
1562 One version in Fortran, adapted for use with @code{g77}, is at
1563 @uref{ftp://members.aol.com/n8tm/rat7.uue} (of uncertain copyright
1564 status). Another, public domain version in C is at
1565 @uref{http://sepwww.stanford.edu/sep/prof/ratfor.shar.2}.
1568 UNIX users typically use the @file{@var{file}.f} and @file{@var{file}.F}
1570 Users of other operating systems, especially those that cannot
1571 distinguish upper-case
1572 letters from lower-case letters in their file names, typically use
1573 the @file{@var{file}.for} and @file{@var{file}.fpp} nomenclature.
1578 Use of the preprocessor @code{cpp} allows use of C-like
1579 constructs such as @code{#define} and @code{#include}, but can
1580 lead to unexpected, even mistaken, results due to Fortran's source file
1582 It is recommended that use of the C preprocessor
1583 be limited to @code{#include} and, in
1584 conjunction with @code{#define}, only @code{#if} and related directives,
1585 thus avoiding in-line macro expansion entirely.
1586 This recommendation applies especially
1587 when using the traditional fixed source form.
1588 With free source form,
1589 fewer unexpected transformations are likely to happen, but use of
1590 constructs such as Hollerith and character constants can nevertheless
1591 present problems, especially when these are continued across multiple
1593 These problems result, primarily, from differences between the way
1594 such constants are interpreted by the C preprocessor and by a Fortran
1597 Another example of a problem that results from using the C preprocessor
1598 is that a Fortran comment line that happens to contain any
1599 characters ``interesting'' to the C preprocessor,
1600 such as a backslash at the end of the line,
1601 is not recognized by the preprocessor as a comment line,
1602 so instead of being passed through ``raw'',
1603 the line is edited according to the rules for the preprocessor.
1604 For example, the backslash at the end of the line is removed,
1605 along with the subsequent newline, resulting in the next
1606 line being effectively commented out---unfortunate if that
1607 line is a non-comment line of important code!
1609 @emph{Note:} The @samp{-traditional} and @samp{-undef} flags are supplied
1610 to @code{cpp} by default, to help avoid unpleasant surprises.
1611 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
1612 gcc,Using and Porting GNU CC}.
1613 This means that ANSI C preprocessor features (such as the @samp{#}
1614 operator) aren't available, and only variables in the C reserved
1615 namespace (generally, names with a leading underscore) are liable to
1616 substitution by C predefines.
1617 Thus, if you want to do system-specific
1618 tests, use, for example, @samp{#ifdef __linux__} rather than @samp{#ifdef linux}.
1619 Use the @samp{-v} option to see exactly how the preprocessor is invoked.
1622 Unfortunately, the @samp{-traditional} flag will not avoid an error from
1623 anything that @code{cpp} sees as an unterminated C comment, such as:
1625 C Some Fortran compilers accept /* as starting
1626 C an inline comment.
1628 @xref{Trailing Comment}.
1630 The following options that affect overall processing are recognized
1631 by the @code{g77} and @code{gcc} commands in a GNU Fortran installation:
1634 @cindex -fversion option
1635 @cindex options, -fversion
1636 @cindex printing version information
1637 @cindex version information, printing
1638 @cindex consistency checks
1639 @cindex internal consistency checks
1640 @cindex checks, of internal consistency
1642 Ensure that the @code{g77}-specific version of the compiler phase is reported,
1644 and, starting in @code{egcs} version 1.1,
1645 that internal consistency checks in the @file{f771} program are run.
1647 This option is supplied automatically when @samp{-v} or @samp{--verbose}
1648 is specified as a command-line option for @code{g77} or @code{gcc}
1649 and when the resulting commands compile Fortran source files.
1651 @cindex -fset-g77-defaults option
1652 @cindex options, -fset-g77-defaults
1653 @item -fset-g77-defaults
1654 @emph{Version info:}
1655 This option is obsolete in @code{egcs}
1657 The effect is instead achieved
1658 by the @samp{lang_init_options} routine
1659 in @file{egcs/gcc/f/com.c}.
1661 @cindex consistency checks
1662 @cindex internal consistency checks
1663 @cindex checks, of internal consistency
1664 Set up whatever @code{gcc} options are to apply to Fortran
1665 compilations, and avoid running internal consistency checks
1666 that might take some time.
1668 This option is supplied automatically when compiling Fortran code
1669 via the @code{g77} or @code{gcc} command.
1670 The description of this option is provided so that users seeing
1671 it in the output of, say, @samp{g77 -v} understand why it is
1674 @cindex modifying g77
1675 @cindex code, modifying
1676 Also, developers who run @code{f771} directly might want to specify it
1677 by hand to get the same defaults as they would running @code{f771}
1678 via @code{g77} or @code{gcc}.
1679 However, such developers should, after linking a new @code{f771}
1680 executable, invoke it without this option once,
1681 e.g. via @kbd{./f771 -quiet < /dev/null},
1682 to ensure that they have not introduced any
1683 internal inconsistencies (such as in the table of
1684 intrinsics) before proceeding---@code{g77} will crash
1685 with a diagnostic if it detects an inconsistency.
1687 @cindex -fno-silent option
1688 @cindex options, -fno-silent
1689 @cindex f2c compatibility
1690 @cindex compatibility, f2c
1691 @cindex status, compilation
1692 @cindex compilation, status
1693 @cindex reporting compilation status
1694 @cindex printing compilation status
1696 Print (to @code{stderr}) the names of the program units as
1697 they are compiled, in a form similar to that used by popular
1698 UNIX @code{f77} implementations and @code{f2c}.
1701 @xref{Overall Options,,Options Controlling the Kind of Output,
1702 gcc,Using and Porting GNU CC}, for information
1703 on more options that control the overall operation of the @code{gcc} command
1704 (and, by extension, the @code{g77} command).
1706 @node Shorthand Options
1707 @section Shorthand Options
1708 @cindex shorthand options
1709 @cindex options, shorthand
1710 @cindex macro options
1711 @cindex options, macro
1713 The following options serve as ``shorthand''
1714 for other options accepted by the compiler:
1717 @cindex -fugly option
1718 @cindex options, -fugly
1720 @cindex ugly features
1721 @cindex features, ugly
1722 Specify that certain ``ugly'' constructs are to be quietly accepted.
1726 -fugly-args -fugly-assign -fugly-assumed
1727 -fugly-comma -fugly-complex -fugly-init
1731 These constructs are considered inappropriate to use in new
1732 or well-maintained portable Fortran code, but widely used
1734 @xref{Distensions}, for more information.
1736 @emph{Note:} The @samp{-fugly} option is likely to
1737 be removed in a future version.
1738 Implicitly enabling all the @samp{-fugly-*} options
1739 is unlikely to be feasible, or sensible, in the future,
1740 so users should learn to specify only those
1741 @samp{-fugly-*} options they really need for a
1742 particular source file.
1744 @cindex -fno-ugly option
1745 @cindex options, -fno-ugly
1747 @cindex ugly features
1748 @cindex features, ugly
1749 Specify that all ``ugly'' constructs are to be noisily rejected.
1753 -fno-ugly-args -fno-ugly-assign -fno-ugly-assumed
1754 -fno-ugly-comma -fno-ugly-complex -fno-ugly-init
1758 @xref{Distensions}, for more information.
1760 @cindex -ff66 option
1761 @cindex options, -ff66
1764 @cindex compatibility, FORTRAN 66
1765 Specify that the program is written in idiomatic FORTRAN 66.
1766 Same as @samp{-fonetrip -fugly-assumed}.
1768 The @samp{-fno-f66} option is the inverse of @samp{-ff66}.
1769 As such, it is the same as @samp{-fno-onetrip -fno-ugly-assumed}.
1771 The meaning of this option is likely to be refined as future
1772 versions of @code{g77} provide more compatibility with other
1773 existing and obsolete Fortran implementations.
1775 @cindex -ff77 option
1776 @cindex options, -ff77
1779 @cindex f2c compatibility
1780 @cindex compatibility, f2c
1781 @cindex f77 compatibility
1782 @cindex compatibility, f77
1783 Specify that the program is written in idiomatic UNIX FORTRAN 77
1784 and/or the dialect accepted by the @code{f2c} product.
1785 Same as @samp{-fbackslash -fno-typeless-boz}.
1787 The meaning of this option is likely to be refined as future
1788 versions of @code{g77} provide more compatibility with other
1789 existing and obsolete Fortran implementations.
1791 @cindex -fno-f77 option
1792 @cindex options, -fno-f77
1795 The @samp{-fno-f77} option is @emph{not} the inverse
1797 It specifies that the program is not written in idiomatic UNIX
1798 FORTRAN 77 or @code{f2c}, but in a more widely portable dialect.
1799 @samp{-fno-f77} is the same as @samp{-fno-backslash}.
1801 The meaning of this option is likely to be refined as future
1802 versions of @code{g77} provide more compatibility with other
1803 existing and obsolete Fortran implementations.
1806 @node Fortran Dialect Options
1807 @section Options Controlling Fortran Dialect
1808 @cindex dialect options
1809 @cindex language, dialect options
1810 @cindex options, dialect
1812 The following options control the dialect of Fortran
1813 that the compiler accepts:
1816 @cindex -ffree-form option
1817 @cindex options, -ffree-form
1818 @cindex -fno-fixed-form option
1819 @cindex options, -fno-fixed-form
1820 @cindex source file format
1823 @cindex Fortran 90, features
1825 @item -fno-fixed-form
1826 Specify that the source file is written in free form
1827 (introduced in Fortran 90) instead of the more-traditional fixed form.
1829 @cindex -ff90 option
1830 @cindex options, -ff90
1831 @cindex Fortran 90, features
1833 Allow certain Fortran-90 constructs.
1835 This option controls whether certain
1836 Fortran 90 constructs are recognized.
1837 (Other Fortran 90 constructs
1838 might or might not be recognized depending on other options such as
1839 @samp{-fvxt}, @samp{-ff90-intrinsics-enable}, and the
1840 current level of support for Fortran 90.)
1842 @xref{Fortran 90}, for more information.
1844 @cindex -fvxt option
1845 @cindex options, -fvxt
1847 @cindex Fortran 90, features
1848 @cindex VXT extensions
1849 Specify the treatment of certain constructs that have different
1850 meanings depending on whether the code is written in
1851 GNU Fortran (based on FORTRAN 77 and akin to Fortran 90)
1852 or VXT Fortran (more like VAX FORTRAN).
1854 The default is @samp{-fno-vxt}.
1855 @samp{-fvxt} specifies that the VXT Fortran interpretations
1856 for those constructs are to be chosen.
1858 @xref{VXT Fortran}, for more information.
1860 @cindex -fdollar-ok option
1861 @cindex options, -fdollar-ok
1864 @cindex symbol names
1865 @cindex character set
1866 Allow @samp{$} as a valid character in a symbol name.
1868 @cindex -fno-backslash option
1869 @cindex options, -fno-backslash
1870 @item -fno-backslash
1872 @cindex character constants
1873 @cindex Hollerith constants
1874 Specify that @samp{\} is not to be specially interpreted in character
1875 and Hollerith constants a la C and many UNIX Fortran compilers.
1877 For example, with @samp{-fbackslash} in effect, @samp{A\nB} specifies
1878 three characters, with the second one being newline.
1879 With @samp{-fno-backslash}, it specifies four characters,
1880 @samp{A}, @samp{\}, @samp{n}, and @samp{B}.
1882 Note that @code{g77} implements a fairly general form of backslash
1883 processing that is incompatible with the narrower forms supported
1884 by some other compilers.
1885 For example, @samp{'A\003B'} is a three-character string in @code{g77},
1886 whereas other compilers that support backslash might not support
1887 the three-octal-digit form, and thus treat that string as longer
1888 than three characters.
1890 @xref{Backslash in Constants}, for
1891 information on why @samp{-fbackslash} is the default
1892 instead of @samp{-fno-backslash}.
1894 @cindex -fno-ugly-args option
1895 @cindex options, -fno-ugly-args
1896 @item -fno-ugly-args
1897 Disallow passing Hollerith and typeless constants as actual
1898 arguments (for example, @samp{CALL FOO(4HABCD)}).
1900 @xref{Ugly Implicit Argument Conversion}, for more information.
1902 @cindex -fugly-assign option
1903 @cindex options, -fugly-assign
1905 Use the same storage for a given variable regardless of
1906 whether it is used to hold an assigned-statement label
1907 (as in @samp{ASSIGN 10 TO I}) or used to hold numeric data
1908 (as in @samp{I = 3}).
1910 @xref{Ugly Assigned Labels}, for more information.
1912 @cindex -fugly-assumed option
1913 @cindex options, -fugly-assumed
1914 @item -fugly-assumed
1915 Assume any dummy array with a final dimension specified as @samp{1}
1916 is really an assumed-size array, as if @samp{*} had been specified
1917 for the final dimension instead of @samp{1}.
1919 For example, @samp{DIMENSION X(1)} is treated as if it
1920 had read @samp{DIMENSION X(*)}.
1922 @xref{Ugly Assumed-Size Arrays}, for more information.
1924 @cindex -fugly-comma option
1925 @cindex options, -fugly-comma
1927 In an external-procedure invocation,
1928 treat a trailing comma in the argument list
1929 as specification of a trailing null argument,
1930 and treat an empty argument list
1931 as specification of a single null argument.
1933 For example, @samp{CALL FOO(,)} is treated as
1934 @samp{CALL FOO(%VAL(0), %VAL(0))}.
1935 That is, @emph{two} null arguments are specified
1936 by the procedure call when @samp{-fugly-comma} is in force.
1937 And @samp{F = FUNC()} is treated as @samp{F = FUNC(%VAL(0))}.
1939 The default behavior, @samp{-fno-ugly-comma}, is to ignore
1940 a single trailing comma in an argument list.
1941 So, by default, @samp{CALL FOO(X,)} is treated
1942 exactly the same as @samp{CALL FOO(X)}.
1944 @xref{Ugly Null Arguments}, for more information.
1946 @cindex -fugly-complex option
1947 @cindex options, -fugly-complex
1948 @item -fugly-complex
1949 Do not complain about @samp{REAL(@var{expr})} or
1950 @samp{AIMAG(@var{expr})} when @var{expr} is a @code{COMPLEX}
1951 type other than @code{COMPLEX(KIND=1)}---usually
1952 this is used to permit @code{COMPLEX(KIND=2)}
1953 (@code{DOUBLE COMPLEX}) operands.
1955 The @samp{-ff90} option controls the interpretation
1958 @xref{Ugly Complex Part Extraction}, for more information.
1960 @cindex -fno-ugly-init option
1961 @cindex options, -fno-ugly-init
1962 @item -fno-ugly-init
1963 Disallow use of Hollerith and typeless constants as initial
1964 values (in @code{PARAMETER} and @code{DATA} statements), and
1965 use of character constants to
1966 initialize numeric types and vice versa.
1968 For example, @samp{DATA I/'F'/, CHRVAR/65/, J/4HABCD/} is disallowed by
1969 @samp{-fno-ugly-init}.
1971 @xref{Ugly Conversion of Initializers}, for more information.
1973 @cindex -fugly-logint option
1974 @cindex options, -fugly-logint
1976 Treat @code{INTEGER} and @code{LOGICAL} variables and
1977 expressions as potential stand-ins for each other.
1979 For example, automatic conversion between @code{INTEGER} and
1980 @code{LOGICAL} is enabled, for many contexts, via this option.
1982 @xref{Ugly Integer Conversions}, for more information.
1984 @cindex -fonetrip option
1985 @cindex options, -fonetrip
1988 @cindex @code{DO} loops, one-trip
1989 @cindex one-trip @code{DO} loops
1990 @cindex @code{DO} loops, zero-trip
1991 @cindex zero-trip @code{DO} loops
1992 @cindex compatibility, FORTRAN 66
1993 Executable iterative @code{DO} loops are to be executed at
1994 least once each time they are reached.
1996 ANSI FORTRAN 77 and more recent versions of the Fortran standard
1997 specify that the body of an iterative @code{DO} loop is not executed
1998 if the number of iterations calculated from the parameters of the
1999 loop is less than 1.
2000 (For example, @samp{DO 10 I = 1, 0}.)
2001 Such a loop is called a @dfn{zero-trip loop}.
2003 Prior to ANSI FORTRAN 77, many compilers implemented @code{DO} loops
2004 such that the body of a loop would be executed at least once, even
2005 if the iteration count was zero.
2006 Fortran code written assuming this behavior is said to require
2007 @dfn{one-trip loops}.
2008 For example, some code written to the FORTRAN 66 standard
2009 expects this behavior from its @code{DO} loops, although that
2010 standard did not specify this behavior.
2012 The @samp{-fonetrip} option specifies that the source file(s) being
2013 compiled require one-trip loops.
2015 This option affects only those loops specified by the (iterative) @code{DO}
2016 statement and by implied-@code{DO} lists in I/O statements.
2017 Loops specified by implied-@code{DO} lists in @code{DATA} and
2018 specification (non-executable) statements are not affected.
2020 @cindex -ftypeless-boz option
2021 @cindex options, -ftypeless-boz
2022 @cindex prefix-radix constants
2023 @cindex constants, prefix-radix
2024 @cindex constants, types
2025 @cindex types, constants
2026 @item -ftypeless-boz
2027 Specifies that prefix-radix non-decimal constants, such as
2028 @samp{Z'ABCD'}, are typeless instead of @code{INTEGER(KIND=1)}.
2030 You can test for yourself whether a particular compiler treats
2031 the prefix form as @code{INTEGER(KIND=1)} or typeless by running the
2038 IF (J .EQ. I) PRINT *, 'Prefix form is TYPELESS'
2039 IF (J .NE. I) PRINT *, 'Prefix form is INTEGER'
2043 Reports indicate that many compilers process this form as
2044 @code{INTEGER(KIND=1)}, though a few as typeless, and at least one
2045 based on a command-line option specifying some kind of
2048 @cindex -fintrin-case-initcap option
2049 @cindex options, -fintrin-case-initcap
2050 @item -fintrin-case-initcap
2051 @cindex -fintrin-case-upper option
2052 @cindex options, -fintrin-case-upper
2053 @item -fintrin-case-upper
2054 @cindex -fintrin-case-lower option
2055 @cindex options, -fintrin-case-lower
2056 @item -fintrin-case-lower
2057 @cindex -fintrin-case-any option
2058 @cindex options, -fintrin-case-any
2059 @item -fintrin-case-any
2060 Specify expected case for intrinsic names.
2061 @samp{-fintrin-case-lower} is the default.
2063 @cindex -fmatch-case-initcap option
2064 @cindex options, -fmatch-case-initcap
2065 @item -fmatch-case-initcap
2066 @cindex -fmatch-case-upper option
2067 @cindex options, -fmatch-case-upper
2068 @item -fmatch-case-upper
2069 @cindex -fmatch-case-lower option
2070 @cindex options, -fmatch-case-lower
2071 @item -fmatch-case-lower
2072 @cindex -fmatch-case-any option
2073 @cindex options, -fmatch-case-any
2074 @item -fmatch-case-any
2075 Specify expected case for keywords.
2076 @samp{-fmatch-case-lower} is the default.
2078 @cindex -fsource-case-upper option
2079 @cindex options, -fsource-case-upper
2080 @item -fsource-case-upper
2081 @cindex -fsource-case-lower option
2082 @cindex options, -fsource-case-lower
2083 @item -fsource-case-lower
2084 @cindex -fsource-case-preserve option
2085 @cindex options, -fsource-case-preserve
2086 @item -fsource-case-preserve
2087 Specify whether source text other than character and Hollerith constants
2088 is to be translated to uppercase, to lowercase, or preserved as is.
2089 @samp{-fsource-case-lower} is the default.
2091 @cindex -fsymbol-case-initcap option
2092 @cindex options, -fsymbol-case-initcap
2093 @item -fsymbol-case-initcap
2094 @cindex -fsymbol-case-upper option
2095 @cindex options, -fsymbol-case-upper
2096 @item -fsymbol-case-upper
2097 @cindex -fsymbol-case-lower option
2098 @cindex options, -fsymbol-case-lower
2099 @item -fsymbol-case-lower
2100 @cindex -fsymbol-case-any option
2101 @cindex options, -fsymbol-case-any
2102 @item -fsymbol-case-any
2103 Specify valid cases for user-defined symbol names.
2104 @samp{-fsymbol-case-any} is the default.
2106 @cindex -fcase-strict-upper option
2107 @cindex options, -fcase-strict-upper
2108 @item -fcase-strict-upper
2109 Same as @samp{-fintrin-case-upper -fmatch-case-upper -fsource-case-preserve
2110 -fsymbol-case-upper}.
2111 (Requires all pertinent source to be in uppercase.)
2113 @cindex -fcase-strict-lower option
2114 @cindex options, -fcase-strict-lower
2115 @item -fcase-strict-lower
2116 Same as @samp{-fintrin-case-lower -fmatch-case-lower -fsource-case-preserve
2117 -fsymbol-case-lower}.
2118 (Requires all pertinent source to be in lowercase.)
2120 @cindex -fcase-initcap option
2121 @cindex options, -fcase-initcap
2122 @item -fcase-initcap
2123 Same as @samp{-fintrin-case-initcap -fmatch-case-initcap -fsource-case-preserve
2124 -fsymbol-case-initcap}.
2125 (Requires all pertinent source to be in initial capitals,
2126 as in @samp{Print *,SqRt(Value)}.)
2128 @cindex -fcase-upper option
2129 @cindex options, -fcase-upper
2131 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-upper
2133 (Maps all pertinent source to uppercase.)
2135 @cindex -fcase-lower option
2136 @cindex options, -fcase-lower
2138 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-lower
2140 (Maps all pertinent source to lowercase.)
2142 @cindex -fcase-preserve option
2143 @cindex options, -fcase-preserve
2144 @item -fcase-preserve
2145 Same as @samp{-fintrin-case-any -fmatch-case-any -fsource-case-preserve
2147 (Preserves all case in user-defined symbols,
2148 while allowing any-case matching of intrinsics and keywords.
2149 For example, @samp{call Foo(i,I)} would pass two @emph{different}
2150 variables named @samp{i} and @samp{I} to a procedure named @samp{Foo}.)
2152 @cindex -fbadu77-intrinsics-delete option
2153 @cindex options, -fbadu77-intrinsics-delete
2154 @item -fbadu77-intrinsics-delete
2155 @cindex -fbadu77-intrinsics-hide option
2156 @cindex options, -fbadu77-intrinsics-hide
2157 @item -fbadu77-intrinsics-hide
2158 @cindex -fbadu77-intrinsics-disable option
2159 @cindex options, -fbadu77-intrinsics-disable
2160 @item -fbadu77-intrinsics-disable
2161 @cindex -fbadu77-intrinsics-enable option
2162 @cindex options, -fbadu77-intrinsics-enable
2163 @item -fbadu77-intrinsics-enable
2164 @cindex @code{badu77} intrinsics
2165 @cindex intrinsics, @code{badu77}
2166 Specify status of UNIX intrinsics having inappropriate forms.
2167 @samp{-fbadu77-intrinsics-enable} is the default.
2168 @xref{Intrinsic Groups}.
2170 @cindex -ff2c-intrinsics-delete option
2171 @cindex options, -ff2c-intrinsics-delete
2172 @item -ff2c-intrinsics-delete
2173 @cindex -ff2c-intrinsics-hide option
2174 @cindex options, -ff2c-intrinsics-hide
2175 @item -ff2c-intrinsics-hide
2176 @cindex -ff2c-intrinsics-disable option
2177 @cindex options, -ff2c-intrinsics-disable
2178 @item -ff2c-intrinsics-disable
2179 @cindex -ff2c-intrinsics-enable option
2180 @cindex options, -ff2c-intrinsics-enable
2181 @item -ff2c-intrinsics-enable
2182 @cindex @code{f2c} intrinsics
2183 @cindex intrinsics, @code{f2c}
2184 Specify status of f2c-specific intrinsics.
2185 @samp{-ff2c-intrinsics-enable} is the default.
2186 @xref{Intrinsic Groups}.
2188 @cindex -ff90-intrinsics-delete option
2189 @cindex options, -ff90-intrinsics-delete
2190 @item -ff90-intrinsics-delete
2191 @cindex -ff90-intrinsics-hide option
2192 @cindex options, -ff90-intrinsics-hide
2193 @item -ff90-intrinsics-hide
2194 @cindex -ff90-intrinsics-disable option
2195 @cindex options, -ff90-intrinsics-disable
2196 @item -ff90-intrinsics-disable
2197 @cindex -ff90-intrinsics-enable option
2198 @cindex options, -ff90-intrinsics-enable
2199 @item -ff90-intrinsics-enable
2200 @cindex Fortran 90, intrinsics
2201 @cindex intrinsics, Fortran 90
2202 Specify status of F90-specific intrinsics.
2203 @samp{-ff90-intrinsics-enable} is the default.
2204 @xref{Intrinsic Groups}.
2206 @cindex -fgnu-intrinsics-delete option
2207 @cindex options, -fgnu-intrinsics-delete
2208 @item -fgnu-intrinsics-delete
2209 @cindex -fgnu-intrinsics-hide option
2210 @cindex options, -fgnu-intrinsics-hide
2211 @item -fgnu-intrinsics-hide
2212 @cindex -fgnu-intrinsics-disable option
2213 @cindex options, -fgnu-intrinsics-disable
2214 @item -fgnu-intrinsics-disable
2215 @cindex -fgnu-intrinsics-enable option
2216 @cindex options, -fgnu-intrinsics-enable
2217 @item -fgnu-intrinsics-enable
2218 @cindex Digital Fortran features
2219 @cindex @code{COMPLEX} intrinsics
2220 @cindex intrinsics, @code{COMPLEX}
2221 Specify status of Digital's COMPLEX-related intrinsics.
2222 @samp{-fgnu-intrinsics-enable} is the default.
2223 @xref{Intrinsic Groups}.
2225 @cindex -fmil-intrinsics-delete option
2226 @cindex options, -fmil-intrinsics-delete
2227 @item -fmil-intrinsics-delete
2228 @cindex -fmil-intrinsics-hide option
2229 @cindex options, -fmil-intrinsics-hide
2230 @item -fmil-intrinsics-hide
2231 @cindex -fmil-intrinsics-disable option
2232 @cindex options, -fmil-intrinsics-disable
2233 @item -fmil-intrinsics-disable
2234 @cindex -fmil-intrinsics-enable option
2235 @cindex options, -fmil-intrinsics-enable
2236 @item -fmil-intrinsics-enable
2237 @cindex MIL-STD 1753
2238 @cindex intrinsics, MIL-STD 1753
2239 Specify status of MIL-STD-1753-specific intrinsics.
2240 @samp{-fmil-intrinsics-enable} is the default.
2241 @xref{Intrinsic Groups}.
2243 @cindex -funix-intrinsics-delete option
2244 @cindex options, -funix-intrinsics-delete
2245 @item -funix-intrinsics-delete
2246 @cindex -funix-intrinsics-hide option
2247 @cindex options, -funix-intrinsics-hide
2248 @item -funix-intrinsics-hide
2249 @cindex -funix-intrinsics-disable option
2250 @cindex options, -funix-intrinsics-disable
2251 @item -funix-intrinsics-disable
2252 @cindex -funix-intrinsics-enable option
2253 @cindex options, -funix-intrinsics-enable
2254 @item -funix-intrinsics-enable
2255 @cindex UNIX intrinsics
2256 @cindex intrinsics, UNIX
2257 Specify status of UNIX intrinsics.
2258 @samp{-funix-intrinsics-enable} is the default.
2259 @xref{Intrinsic Groups}.
2261 @cindex -fvxt-intrinsics-delete option
2262 @cindex options, -fvxt-intrinsics-delete
2263 @item -fvxt-intrinsics-delete
2264 @cindex -fvxt-intrinsics-hide option
2265 @cindex options, -fvxt-intrinsics-hide
2266 @item -fvxt-intrinsics-hide
2267 @cindex -fvxt-intrinsics-disable option
2268 @cindex options, -fvxt-intrinsics-disable
2269 @item -fvxt-intrinsics-disable
2270 @cindex -fvxt-intrinsics-enable option
2271 @cindex options, -fvxt-intrinsics-enable
2272 @item -fvxt-intrinsics-enable
2273 @cindex VXT intrinsics
2274 @cindex intrinsics, VXT
2275 Specify status of VXT intrinsics.
2276 @samp{-fvxt-intrinsics-enable} is the default.
2277 @xref{Intrinsic Groups}.
2279 @cindex -ffixed-line-length-@var{n} option
2280 @cindex options, -ffixed-line-length-@var{n}
2281 @item -ffixed-line-length-@var{n}
2282 @cindex source file format
2283 @cindex lines, length
2284 @cindex length of source lines
2286 @cindex limits, lengths of source lines
2287 Set column after which characters are ignored in typical fixed-form
2288 lines in the source file, and through which spaces are assumed (as
2289 if padded to that length) after the ends of short fixed-form lines.
2292 @cindex extended-source option
2293 Popular values for @var{n} include 72 (the
2294 standard and the default), 80 (card image), and 132 (corresponds
2295 to ``extended-source'' options in some popular compilers).
2296 @var{n} may be @samp{none}, meaning that the entire line is meaningful
2297 and that continued character constants never have implicit spaces appended
2298 to them to fill out the line.
2299 @samp{-ffixed-line-length-0} means the same thing as
2300 @samp{-ffixed-line-length-none}.
2302 @xref{Source Form}, for more information.
2305 @node Warning Options
2306 @section Options to Request or Suppress Warnings
2307 @cindex options, warnings
2308 @cindex warnings, suppressing
2309 @cindex messages, warning
2310 @cindex suppressing warnings
2312 Warnings are diagnostic messages that report constructions which
2313 are not inherently erroneous but which are risky or suggest there
2314 might have been an error.
2316 You can request many specific warnings with options beginning @samp{-W},
2317 for example @samp{-Wimplicit} to request warnings on implicit
2318 declarations. Each of these specific warning options also has a
2319 negative form beginning @samp{-Wno-} to turn off warnings;
2320 for example, @samp{-Wno-implicit}. This manual lists only one of the
2321 two forms, whichever is not the default.
2323 These options control the amount and kinds of warnings produced by GNU
2327 @cindex syntax checking
2328 @cindex -fsyntax-only option
2329 @cindex options, -fsyntax-only
2331 Check the code for syntax errors, but don't do anything beyond that.
2333 @cindex -pedantic option
2334 @cindex options, -pedantic
2336 Issue warnings for uses of extensions to ANSI FORTRAN 77.
2337 @samp{-pedantic} also applies to C-language constructs where they
2338 occur in GNU Fortran source files, such as use of @samp{\e} in a
2339 character constant within a directive like @samp{#include}.
2341 Valid ANSI FORTRAN 77 programs should compile properly with or without
2343 However, without this option, certain GNU extensions and traditional
2344 Fortran features are supported as well.
2345 With this option, many of them are rejected.
2347 Some users try to use @samp{-pedantic} to check programs for strict ANSI
2349 They soon find that it does not do quite what they want---it finds some
2350 non-ANSI practices, but not all.
2351 However, improvements to @code{g77} in this area are welcome.
2353 @cindex -pedantic-errors option
2354 @cindex options, -pedantic-errors
2355 @item -pedantic-errors
2356 Like @samp{-pedantic}, except that errors are produced rather than
2359 @cindex -fpedantic option
2360 @cindex options, -fpedantic
2362 Like @samp{-pedantic}, but applies only to Fortran constructs.
2367 Inhibit all warning messages.
2369 @cindex -Wno-globals option
2370 @cindex options, -Wno-globals
2372 @cindex global names, warning
2373 @cindex warnings, global names
2374 Inhibit warnings about use of a name as both a global name
2375 (a subroutine, function, or block data program unit, or a
2376 common block) and implicitly as the name of an intrinsic
2379 Also inhibit warnings about inconsistent invocations and/or
2380 definitions of global procedures (function and subroutines).
2381 Such inconsistencies include different numbers of arguments
2382 and different types of arguments.
2384 @cindex -Wimplicit option
2385 @cindex options, -Wimplicit
2387 @cindex implicit declaration, warning
2388 @cindex warnings, implicit declaration
2390 @cindex /WARNINGS=DECLARATIONS switch
2391 @cindex IMPLICIT NONE, similar effect
2392 @cindex effecting IMPLICIT NONE
2393 Warn whenever a variable, array, or function is implicitly
2395 Has an effect similar to using the @code{IMPLICIT NONE} statement
2396 in every program unit.
2397 (Some Fortran compilers provide this feature by an option
2398 named @samp{-u} or @samp{/WARNINGS=DECLARATIONS}.)
2400 @cindex -Wunused option
2401 @cindex options, -Wunused
2403 @cindex unused variables
2404 @cindex variables, unused
2405 Warn whenever a variable is unused aside from its declaration.
2407 @cindex -Wuninitialized option
2408 @cindex options, -Wuninitialized
2409 @item -Wuninitialized
2410 @cindex uninitialized variables
2411 @cindex variables, uninitialized
2412 Warn whenever an automatic variable is used without first being initialized.
2414 These warnings are possible only in optimizing compilation,
2415 because they require data-flow information that is computed only
2416 when optimizing. If you don't specify @samp{-O}, you simply won't
2419 These warnings occur only for variables that are candidates for
2420 register allocation. Therefore, they do not occur for a variable
2421 @c that is declared @code{VOLATILE}, or
2422 whose address is taken, or whose size
2423 is other than 1, 2, 4 or 8 bytes. Also, they do not occur for
2424 arrays, even when they are in registers.
2426 Note that there might be no warning about a variable that is used only
2427 to compute a value that itself is never used, because such
2428 computations may be deleted by data-flow analysis before the warnings
2431 These warnings are made optional because GNU Fortran is not smart
2432 enough to see all the reasons why the code might be correct
2433 despite appearing to have an error. Here is one example of how
2437 SUBROUTINE DISPAT(J)
2446 If the value of @code{J} is always 1, 2 or 3, then @code{I} is
2447 always initialized, but GNU Fortran doesn't know this. Here is
2448 another common case:
2451 SUBROUTINE MAYBE(FLAG)
2453 IF (FLAG) VALUE = 9.4
2455 IF (FLAG) PRINT *, VALUE
2460 This has no bug because @code{VALUE} is used only if it is set.
2462 @cindex -Wall option
2463 @cindex options, -Wall
2465 @cindex all warnings
2466 @cindex warnings, all
2467 The @samp{-Wunused} and @samp{-Wuninitialized} options combined.
2469 options which pertain to usage that we recommend avoiding and that we
2470 believe is easy to avoid.
2471 (As more warnings are added to @code{g77}, some might
2472 be added to the list enabled by @samp{-Wall}.)
2475 The remaining @samp{-W@dots{}} options are not implied by @samp{-Wall}
2476 because they warn about constructions that we consider reasonable to
2477 use, on occasion, in clean programs.
2481 @c Print extra warning messages for these events:
2485 @c If @samp{-Wall} or @samp{-Wunused} is also specified, warn about unused
2490 @cindex -Wsurprising option
2491 @cindex options, -Wsurprising
2493 Warn about ``suspicious'' constructs that are interpreted
2494 by the compiler in a way that might well be surprising to
2495 someone reading the code.
2496 These differences can result in subtle, compiler-dependent
2497 (even machine-dependent) behavioral differences.
2498 The constructs warned about include:
2502 Expressions having two arithmetic operators in a row, such
2504 Such a construct is nonstandard, and can produce
2505 unexpected results in more complicated situations such
2507 @code{g77}, along with many other compilers, interprets
2508 this example differently than many programmers, and a few
2510 Specifically, @code{g77} interprets @samp{X**-Y*Z} as
2511 @samp{(X**(-Y))*Z}, while others might think it should
2512 be interpreted as @samp{X**(-(Y*Z))}.
2514 A revealing example is the constant expression @samp{2**-2*1.},
2515 which @code{g77} evaluates to .25, while others might evaluate
2516 it to 0., the difference resulting from the way precedence affects
2519 (The @samp{-fpedantic} option also warns about expressions
2520 having two arithmetic operators in a row.)
2523 Expressions with a unary minus followed by an operand and then
2524 a binary operator other than plus or minus.
2525 For example, @samp{-2**2} produces a warning, because
2526 the precedence is @samp{-(2**2)}, yielding -4, not
2527 @samp{(-2)**2}, which yields 4, and which might represent
2528 what a programmer expects.
2530 An example of an expression producing different results
2531 in a surprising way is @samp{-I*S}, where @var{I} holds
2532 the value @samp{-2147483648} and @var{S} holds @samp{0.5}.
2533 On many systems, negating @var{I} results in the same
2534 value, not a positive number, because it is already the
2535 lower bound of what an @code{INTEGER(KIND=1)} variable can hold.
2536 So, the expression evaluates to a positive number, while
2537 the ``expected'' interpretation, @samp{(-I)*S}, would
2538 evaluate to a negative number.
2540 Even cases such as @samp{-I*J} produce warnings,
2541 even though, in most configurations and situations,
2542 there is no computational difference between the
2543 results of the two interpretations---the purpose
2544 of this warning is to warn about differing interpretations
2545 and encourage a better style of coding, not to identify
2546 only those places where bugs might exist in the user's
2549 @cindex DO statement
2550 @cindex statements, DO
2552 @code{DO} loops with @code{DO} variables that are not
2553 of integral type---that is, using @code{REAL}
2554 variables as loop control variables.
2555 Although such loops can be written to work in the
2556 ``obvious'' way, the way @code{g77} is required by the
2557 Fortran standard to interpret such code is likely to
2558 be quite different from the way many programmers expect.
2559 (This is true of all @code{DO} loops, but the differences
2560 are pronounced for non-integral loop control variables.)
2562 @xref{Loops}, for more information.
2565 @cindex -Werror option
2566 @cindex options, -Werror
2568 Make all warnings into errors.
2573 @cindex extra warnings
2574 @cindex warnings, extra
2575 Turns on ``extra warnings'' and, if optimization is specified
2576 via @samp{-O}, the @samp{-Wuninitialized} option.
2577 (This might change in future versions of @code{g77}.)
2579 ``Extra warnings'' are issued for:
2583 @cindex unused parameters
2584 @cindex parameters, unused
2585 @cindex unused arguments
2586 @cindex arguments, unused
2587 @cindex unused dummies
2588 @cindex dummies, unused
2589 Unused parameters to a procedure (when @samp{-Wunused} also is
2594 Overflows involving floating-point constants (not available
2595 for certain configurations).
2599 @xref{Warning Options,,Options to Request or Suppress Warnings,
2600 gcc,Using and Porting GNU CC}, for information on more options offered
2601 by the GBE shared by @code{g77}, @code{gcc}, and other GNU compilers.
2603 Some of these have no effect when compiling programs written in Fortran:
2606 @cindex -Wcomment option
2607 @cindex options, -Wcomment
2609 @cindex -Wformat option
2610 @cindex options, -Wformat
2612 @cindex -Wparentheses option
2613 @cindex options, -Wparentheses
2615 @cindex -Wswitch option
2616 @cindex options, -Wswitch
2618 @cindex -Wtraditional option
2619 @cindex options, -Wtraditional
2621 @cindex -Wshadow option
2622 @cindex options, -Wshadow
2624 @cindex -Wid-clash-@var{len} option
2625 @cindex options, -Wid-clash-@var{len}
2626 @item -Wid-clash-@var{len}
2627 @cindex -Wlarger-than-@var{len} option
2628 @cindex options, -Wlarger-than-@var{len}
2629 @item -Wlarger-than-@var{len}
2630 @cindex -Wconversion option
2631 @cindex options, -Wconversion
2633 @cindex -Waggregate-return option
2634 @cindex options, -Waggregate-return
2635 @item -Waggregate-return
2636 @cindex -Wredundant-decls option
2637 @cindex options, -Wredundant-decls
2638 @item -Wredundant-decls
2639 @cindex unsupported warnings
2640 @cindex warnings, unsupported
2641 These options all could have some relevant meaning for
2642 GNU Fortran programs, but are not yet supported.
2645 @node Debugging Options
2646 @section Options for Debugging Your Program or GNU Fortran
2647 @cindex options, debugging
2648 @cindex debugging information options
2650 GNU Fortran has various special options that are used for debugging
2651 either your program or @code{g77}.
2657 Produce debugging information in the operating system's native format
2658 (stabs, COFF, XCOFF, or DWARF). GDB can work with this debugging
2661 @cindex common blocks
2662 @cindex equivalence areas
2663 @cindex missing debug features
2664 Support for this option in Fortran programs is incomplete.
2665 In particular, names of variables and arrays in common blocks
2666 or that are storage-associated via @code{EQUIVALENCE} are
2667 unavailable to the debugger.
2669 However, version 0.5.19 of @code{g77} does provide this information
2670 in a rudimentary way, as controlled by the
2671 @samp{-fdebug-kludge} option.
2673 @xref{Code Gen Options,,Options for Code Generation Conventions},
2674 for more information.
2677 @xref{Debugging Options,,Options for Debugging Your Program or GNU CC,
2678 gcc,Using and Porting GNU CC}, for more information on debugging options.
2680 @node Optimize Options
2681 @section Options That Control Optimization
2682 @cindex optimize options
2683 @cindex options, optimization
2685 Most Fortran users will want to use no optimization when
2686 developing and testing programs, and use @samp{-O} or @samp{-O2} when
2687 compiling programs for late-cycle testing and for production use.
2688 However, note that certain diagnostics---such as for uninitialized
2689 variables---depend on the flow analysis done by @samp{-O}, i.e.@: you
2690 must use @samp{-O} or @samp{-O2} to get such diagnostics.
2692 The following flags have particular applicability when
2693 compiling Fortran programs:
2696 @cindex -malign-double option
2697 @cindex options, -malign-double
2698 @item -malign-double
2699 (Intel x86 architecture only.)
2701 Noticeably improves performance of @code{g77} programs making
2702 heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data
2704 In particular, systems using Pentium, Pentium Pro, 586, and
2706 of the i386 architecture execute programs faster when
2707 @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}) data are
2708 aligned on 64-bit boundaries
2711 This option can, at least, make benchmark results more consistent
2712 across various system configurations, versions of the program,
2715 @emph{Note:} The warning in the @code{gcc} documentation about
2716 this option does not apply, generally speaking, to Fortran
2717 code compiled by @code{g77}.
2719 @xref{Aligned Data}, for more information on alignment issues.
2721 @emph{Also also note:} The negative form of @samp{-malign-double}
2722 is @samp{-mno-align-double}, not @samp{-benign-double}.
2724 @cindex -ffloat-store option
2725 @cindex options, -ffloat-store
2727 @cindex IEEE 754 conformance
2728 @cindex conformance, IEEE 754
2729 @cindex floating-point, precision
2730 Might help a Fortran program that depends on exact IEEE conformance on
2731 some machines, but might slow down a program that doesn't.
2733 This option is effective when the floating-point unit is set to work in
2734 IEEE 854 `extended precision'---as it typically is on x86 and m68k GNU
2735 systems---rather than IEEE 754 double precision. @code{-ffloat-store}
2736 tries to remove the extra precision by spilling data from floating-point
2737 registers into memory and this typically involves a big performance
2738 hit. However, it doesn't affect intermediate results, so that it is
2739 only partially effective. `Excess precision' is avoided in code like:
2744 but not in code like:
2749 For another, potentially better, way of controlling the precision,
2750 see @ref{Floating-point precision}.
2752 @cindex -fforce-mem option
2753 @cindex options, -fforce-mem
2755 @cindex -fforce-addr option
2756 @cindex options, -fforce-addr
2758 @cindex loops, speeding up
2759 @cindex speed, of loops
2760 Might improve optimization of loops.
2762 @cindex -fno-inline option
2763 @cindex options, -fno-inline
2765 @cindex in-line code
2766 @cindex compilation, in-line
2767 @c DL: Only relevant for -O3?
2768 Don't compile statement functions inline.
2769 Might reduce the size of a program unit---which might be at
2770 expense of some speed (though it should compile faster).
2771 Note that if you are not optimizing, no functions can be expanded inline.
2773 @cindex -ffast-math option
2774 @cindex options, -ffast-math
2776 @cindex IEEE 754 conformance
2777 @cindex conformance, IEEE 754
2778 Might allow some programs designed to not be too dependent
2779 on IEEE behavior for floating-point to run faster, or die trying.
2781 @cindex -fstrength-reduce option
2782 @cindex options, -fstrength-reduce
2783 @item -fstrength-reduce
2784 @cindex loops, speeding up
2785 @cindex speed, of loops
2786 @c DL: normally defaulted?
2787 Might make some loops run faster.
2789 @cindex -frerun-cse-after-loop option
2790 @cindex options, -frerun-cse-after-loop
2791 @item -frerun-cse-after-loop
2792 @cindex -fexpensive-optimizations option
2793 @cindex options, -fexpensive-optimizations
2795 @item -fexpensive-optimizations
2796 @cindex -fdelayed-branch option
2797 @cindex options, -fdelayed-branch
2798 @item -fdelayed-branch
2799 @cindex -fschedule-insns option
2800 @cindex options, -fschedule-insns
2801 @item -fschedule-insns
2802 @cindex -fschedule-insns2 option
2803 @cindex options, -fschedule-insns2
2804 @item -fschedule-insns2
2805 @cindex -fcaller-saves option
2806 @cindex options, -fcaller-saves
2807 @item -fcaller-saves
2808 Might improve performance on some code.
2810 @cindex -funroll-loops option
2811 @cindex options, -funroll-loops
2812 @item -funroll-loops
2813 @cindex loops, unrolling
2814 @cindex unrolling loops
2815 @cindex loops, optimizing
2816 @cindex indexed (iterative) @code{DO}
2817 @cindex iterative @code{DO}
2818 @c DL: fixme: Craig doesn't like `indexed' but f95 doesn't seem to
2819 @c provide a suitable term
2820 @c CB: I've decided on `iterative', for the time being, and changed
2821 @c my previous, rather bizarre, use of `imperative' to that
2822 @c (though `precomputed-trip' would be a more precise adjective)
2823 Typically improves performance on code using iterative @code{DO} loops by
2824 unrolling them and is probably generally appropriate for Fortran, though
2825 it is not turned on at any optimization level.
2826 Note that outer loop unrolling isn't done specifically; decisions about
2827 whether to unroll a loop are made on the basis of its instruction count.
2829 @c DL: Fixme: This should obviously go somewhere else...
2830 Also, no `loop discovery'@footnote{@dfn{loop discovery} refers to the
2831 process by which a compiler, or indeed any reader of a program,
2832 determines which portions of the program are more likely to be executed
2833 repeatedly as it is being run. Such discovery typically is done early
2834 when compiling using optimization techniques, so the ``discovered''
2835 loops get more attention---and more run-time resources, such as
2836 registers---from the compiler. It is easy to ``discover'' loops that are
2837 constructed out of looping constructs in the language
2838 (such as Fortran's @code{DO}). For some programs, ``discovering'' loops
2839 constructed out of lower-level constructs (such as @code{IF} and
2840 @code{GOTO}) can lead to generation of more optimal code
2841 than otherwise.} is done, so only loops written with @code{DO}
2842 benefit from loop optimizations, including---but not limited
2843 to---unrolling. Loops written with @code{IF} and @code{GOTO} are not
2844 currently recognized as such. This option unrolls only iterative
2845 @code{DO} loops, not @code{DO WHILE} loops.
2847 @cindex -funroll-all-loops option
2848 @cindex options, -funroll-all-loops
2850 @item -funroll-all-loops
2851 @c DL: Check my understanding of -funroll-all-loops v. -funroll-loops is correct.
2852 Probably improves performance on code using @code{DO WHILE} loops by
2853 unrolling them in addition to iterative @code{DO} loops. In the absence
2854 of @code{DO WHILE}, this option is equivalent to @code{-funroll-loops}
2855 but possibly slower.
2857 @item -fno-move-all-movables
2858 @cindex -fno-move-all-movables option
2859 @cindex options, -fno-move-all-movables
2860 @item -fno-reduce-all-givs
2861 @cindex -fno-reduce-all-givs option
2862 @cindex options, -fno-reduce-all-givs
2863 @item -fno-rerun-loop-opt
2864 @cindex -fno-rerun-loop-opt option
2865 @cindex options, -fno-rerun-loop-opt
2866 @emph{Version info:}
2867 These options are not supported by
2868 versions of @code{g77} based on @code{gcc} version 2.8.
2870 Each of these might improve performance on some code.
2872 Analysis of Fortran code optimization and the resulting
2873 optimizations triggered by the above options were
2874 contributed by Toon Moene (@email{toon@@moene.indiv.nluug.nl}).
2876 These three options are intended to be removed someday, once
2877 they have helped determine the efficacy of various
2878 approaches to improving the performance of Fortran code.
2880 Please let us know how use of these options affects
2881 the performance of your production code.
2882 We're particularly interested in code that runs faster
2883 when these options are @emph{disabled}, and in
2884 non-Fortran code that benefits when they are
2885 @emph{enabled} via the above @code{gcc} command-line options.
2888 @xref{Optimize Options,,Options That Control Optimization,
2889 gcc,Using and Porting GNU CC}, for more information on options
2890 to optimize the generated machine code.
2892 @node Preprocessor Options
2893 @section Options Controlling the Preprocessor
2894 @cindex preprocessor options
2895 @cindex options, preprocessor
2897 @cindex programs, cpp
2899 These options control the C preprocessor, which is run on each C source
2900 file before actual compilation.
2902 @xref{Preprocessor Options,,Options Controlling the Preprocessor,
2903 gcc,Using and Porting GNU CC}, for information on C preprocessor options.
2905 @cindex INCLUDE directive
2906 @cindex directive, INCLUDE
2907 Some of these options also affect how @code{g77} processes the
2908 @code{INCLUDE} directive.
2909 Since this directive is processed even when preprocessing
2910 is not requested, it is not described in this section.
2911 @xref{Directory Options,,Options for Directory Search}, for
2912 information on how @code{g77} processes the @code{INCLUDE} directive.
2914 However, the @code{INCLUDE} directive does not apply
2915 preprocessing to the contents of the included file itself.
2917 Therefore, any file that contains preprocessor directives
2918 (such as @code{#include}, @code{#define}, and @code{#if})
2919 must be included via the @code{#include} directive, not
2920 via the @code{INCLUDE} directive.
2921 Therefore, any file containing preprocessor directives,
2922 if included, is necessarily included by a file that itself
2923 contains preprocessor directives.
2925 @node Directory Options
2926 @section Options for Directory Search
2927 @cindex directory, options
2928 @cindex options, directory search
2931 These options affect how the @code{cpp} preprocessor searches
2932 for files specified via the @code{#include} directive.
2933 Therefore, when compiling Fortran programs, they are meaningful
2934 when the preprocessor is used.
2936 @cindex INCLUDE directive
2937 @cindex directive, INCLUDE
2938 Some of these options also affect how @code{g77} searches
2939 for files specified via the @code{INCLUDE} directive,
2940 although files included by that directive are not,
2941 themselves, preprocessed.
2946 @cindex options, -I-
2948 @cindex -Idir option
2949 @cindex options, -Idir
2951 @cindex directory, search paths for inclusion
2952 @cindex inclusion, directory search paths for
2953 @cindex search paths, for included files
2954 @cindex paths, search
2955 These affect interpretation of the @code{INCLUDE} directive
2956 (as well as of the @code{#include} directive of the @code{cpp}
2959 Note that @samp{-I@var{dir}} must be specified @emph{without} any
2960 spaces between @samp{-I} and the directory name---that is,
2961 @samp{-Ifoo/bar} is valid, but @samp{-I foo/bar}
2962 is rejected by the @code{g77} compiler (though the preprocessor supports
2964 @c this is due to toplev.c's inflexible option processing
2965 Also note that the general behavior of @samp{-I} and
2966 @code{INCLUDE} is pretty much the same as of @samp{-I} with
2967 @code{#include} in the @code{cpp} preprocessor, with regard to
2968 looking for @file{header.gcc} files and other such things.
2970 @xref{Directory Options,,Options for Directory Search,
2971 gcc,Using and Porting GNU CC}, for information on the @samp{-I} option.
2974 @node Code Gen Options
2975 @section Options for Code Generation Conventions
2976 @cindex code generation, conventions
2977 @cindex options, code generation
2978 @cindex run-time, options
2980 These machine-independent options control the interface conventions
2981 used in code generation.
2983 Most of them have both positive and negative forms; the negative form
2984 of @samp{-ffoo} would be @samp{-fno-foo}. In the table below, only
2985 one of the forms is listed---the one which is not the default. You
2986 can figure out the other form by either removing @samp{no-} or adding
2990 @cindex -fno-automatic option
2991 @cindex options, -fno-automatic
2992 @item -fno-automatic
2993 @cindex SAVE statement
2994 @cindex statements, SAVE
2995 Treat each program unit as if the @code{SAVE} statement was specified
2996 for every local variable and array referenced in it.
2997 Does not affect common blocks.
2998 (Some Fortran compilers provide this option under
2999 the name @samp{-static}.)
3001 @cindex -finit-local-zero option
3002 @cindex options, -finit-local-zero
3003 @item -finit-local-zero
3004 @cindex DATA statement
3005 @cindex statements, DATA
3006 @cindex initialization, of local variables
3007 @cindex variables, initialization of
3008 @cindex uninitialized variables
3009 @cindex variables, uninitialized
3010 Specify that variables and arrays that are local to a program unit
3011 (not in a common block and not passed as an argument) are to be initialized
3014 Since there is a run-time penalty for initialization of variables
3015 that are not given the @code{SAVE} attribute, it might be a
3016 good idea to also use @samp{-fno-automatic} with @samp{-finit-local-zero}.
3018 @cindex -fno-f2c option
3019 @cindex options, -fno-f2c
3021 @cindex @code{f2c} compatibility
3022 @cindex compatibility, @code{f2c}
3023 Do not generate code designed to be compatible with code generated
3024 by @code{f2c}; use the GNU calling conventions instead.
3026 The @code{f2c} calling conventions require functions that return
3027 type @code{REAL(KIND=1)} to actually return the C type @code{double},
3028 and functions that return type @code{COMPLEX} to return the
3029 values via an extra argument in the calling sequence that points
3030 to where to store the return value.
3031 Under the GNU calling conventions, such functions simply return
3032 their results as they would in GNU C---@code{REAL(KIND=1)} functions
3033 return the C type @code{float}, and @code{COMPLEX} functions
3034 return the GNU C type @code{complex} (or its @code{struct}
3037 This does not affect the generation of code that interfaces with the
3038 @code{libg2c} library.
3040 However, because the @code{libg2c} library uses @code{f2c}
3041 calling conventions, @code{g77} rejects attempts to pass
3042 intrinsics implemented by routines in this library as actual
3043 arguments when @samp{-fno-f2c} is used, to avoid bugs when
3044 they are actually called by code expecting the GNU calling
3045 conventions to work.
3047 For example, @samp{INTRINSIC ABS;CALL FOO(ABS)} is
3048 rejected when @samp{-fno-f2c} is in force.
3049 (Future versions of the @code{g77} run-time library might
3050 offer routines that provide GNU-callable versions of the
3051 routines that implement the @code{f2c}-callable intrinsics
3052 that may be passed as actual arguments, so that
3053 valid programs need not be rejected when @samp{-fno-f2c}
3056 @strong{Caution:} If @samp{-fno-f2c} is used when compiling any
3057 source file used in a program, it must be used when compiling
3058 @emph{all} Fortran source files used in that program.
3060 @c seems kinda dumb to tell people about an option they can't use -- jcb
3061 @c then again, we want users building future-compatible libraries with it.
3062 @cindex -ff2c-library option
3063 @cindex options, -ff2c-library
3065 Specify that use of @code{libg2c} (or the original @code{libf2c})
3067 This is the default for the current version of @code{g77}.
3070 valid to specify @samp{-fno-f2c-library}.
3071 This option is provided so users can specify it in shell
3072 scripts that build programs and libraries that require the
3073 @code{libf2c} library, even when being compiled by future
3074 versions of @code{g77} that might otherwise default to
3075 generating code for an incompatible library.
3077 @cindex -fno-underscoring option
3078 @cindex options, -fno-underscoring
3079 @item -fno-underscoring
3081 @cindex symbol names, underscores
3082 @cindex transforming symbol names
3083 @cindex symbol names, transforming
3084 Do not transform names of entities specified in the Fortran
3085 source file by appending underscores to them.
3087 With @samp{-funderscoring} in effect, @code{g77} appends two underscores
3088 to names with underscores and one underscore to external names with
3089 no underscores. (@code{g77} also appends two underscores to internal
3090 names with underscores to avoid naming collisions with external names.
3091 The @samp{-fno-second-underscore} option disables appending of the
3092 second underscore in all cases.)
3094 This is done to ensure compatibility with code produced by many
3095 UNIX Fortran compilers, including @code{f2c}, which perform the
3096 same transformations.
3098 Use of @samp{-fno-underscoring} is not recommended unless you are
3099 experimenting with issues such as integration of (GNU) Fortran into
3100 existing system environments (vis-a-vis existing libraries, tools, and
3103 For example, with @samp{-funderscoring}, and assuming other defaults like
3104 @samp{-fcase-lower} and that @samp{j()} and @samp{max_count()} are
3105 external functions while @samp{my_var} and @samp{lvar} are local variables,
3109 I = J() + MAX_COUNT (MY_VAR, LVAR)
3113 is implemented as something akin to:
3116 i = j_() + max_count__(&my_var__, &lvar);
3119 With @samp{-fno-underscoring}, the same statement is implemented as:
3122 i = j() + max_count(&my_var, &lvar);
3125 Use of @samp{-fno-underscoring} allows direct specification of
3126 user-defined names while debugging and when interfacing @code{g77}-compiled
3127 code with other languages.
3129 Note that just because the names match does @emph{not} mean that the
3130 interface implemented by @code{g77} for an external name matches the
3131 interface implemented by some other language for that same name.
3132 That is, getting code produced by @code{g77} to link to code produced
3133 by some other compiler using this or any other method can be only a
3134 small part of the overall solution---getting the code generated by
3135 both compilers to agree on issues other than naming can require
3136 significant effort, and, unlike naming disagreements, linkers normally
3137 cannot detect disagreements in these other areas.
3139 Also, note that with @samp{-fno-underscoring}, the lack of appended
3140 underscores introduces the very real possibility that a user-defined
3141 external name will conflict with a name in a system library, which
3142 could make finding unresolved-reference bugs quite difficult in some
3143 cases---they might occur at program run time, and show up only as
3144 buggy behavior at run time.
3146 In future versions of @code{g77}, we hope to improve naming and linking
3147 issues so that debugging always involves using the names as they appear
3148 in the source, even if the names as seen by the linker are mangled to
3149 prevent accidental linking between procedures with incompatible
3152 @cindex -fno-second-underscore option
3153 @cindex options, -fno-second-underscore
3154 @item -fno-second-underscore
3156 @cindex symbol names, underscores
3157 @cindex transforming symbol names
3158 @cindex symbol names, transforming
3159 Do not append a second underscore to names of entities specified
3160 in the Fortran source file.
3162 This option has no effect if @samp{-fno-underscoring} is
3165 Otherwise, with this option, an external name such as @samp{MAX_COUNT}
3166 is implemented as a reference to the link-time external symbol
3167 @samp{max_count_}, instead of @samp{max_count__}.
3169 @cindex -fno-ident option
3170 @cindex options, -fno-ident
3172 Ignore the @samp{#ident} directive.
3174 @cindex -fzeros option
3175 @cindex options, -fzeros
3177 Treat initial values of zero as if they were any other value.
3179 As of version 0.5.18, @code{g77} normally treats @code{DATA} and
3180 other statements that are used to specify initial values of zero
3181 for variables and arrays as if no values were actually specified,
3182 in the sense that no diagnostics regarding multiple initializations
3185 This is done to speed up compiling of programs that initialize
3186 large arrays to zeros.
3188 Use @samp{-fzeros} to revert to the simpler, slower behavior
3189 that can catch multiple initializations by keeping track of
3190 all initializations, zero or otherwise.
3192 @emph{Caution:} Future versions of @code{g77} might disregard this option
3193 (and its negative form, the default) or interpret it somewhat
3195 The interpretation changes will affect only non-standard
3196 programs; standard-conforming programs should not be affected.
3198 @cindex -fdebug-kludge option
3199 @cindex options, -fdebug-kludge
3200 @item -fdebug-kludge
3201 Emit information on @code{COMMON} and @code{EQUIVALENCE} members
3202 that might help users of debuggers work around lack of proper debugging
3203 information on such members.
3205 As of version 0.5.19, @code{g77} offers this option to emit
3206 information on members of aggregate areas to help users while debugging.
3207 This information consists of establishing the type and contents of each
3208 such member so that, when a debugger is asked to print the contents,
3209 the printed information provides rudimentary debugging information.
3210 This information identifies the name of the aggregate area (either the
3211 @code{COMMON} block name, or the @code{g77}-assigned name for the
3212 @code{EQUIVALENCE} name) and the offset, in bytes, of the member from
3213 the beginning of the area.
3215 Using @code{gdb}, this information is not coherently displayed in the Fortran
3216 language mode, so temporarily switching to the C language mode to display the
3217 information is suggested.
3218 Use @samp{set language c} and @samp{set language fortran} to accomplish this.
3226 EQUIVALENCE (I,XX(20:20))
3229 GDB is free software and you are welcome to distribute copies of it
3230 under certain conditions; type "show copying" to see the conditions.
3231 There is absolutely no warranty for GDB; type "show warranty" for details.
3232 GDB 4.16 (lm-gnits-dwim), Copyright 1996 Free Software Foundation, Inc...
3234 Breakpoint 1 at 0t1200000201120112: file cd.f, line 5.
3236 Starting program: /home/user/a.out
3238 Breakpoint 1, MAIN__ () at cd.f:5
3239 Current language: auto; currently fortran
3240 (gdb) set language c
3241 Warning: the current language does not match this frame.
3243 $2 = "At (COMMON) `x_' plus 0 bytes"
3245 $3 = "At (COMMON) `x_' plus 4 bytes"
3247 $4 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3249 $5 = "At (EQUIVALENCE) `__g77_equiv_c' plus 0 bytes"
3251 $6 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 20 bytes"
3253 $7 = "At (EQUIVALENCE) `__g77_equiv_xx' plus 1 bytes"
3254 (gdb) set language fortran
3259 Use @samp{-fdebug-kludge} to generate this information,
3260 which might make some programs noticeably larger.
3262 @emph{Caution:} Future versions of @code{g77} might disregard this option
3263 (and its negative form).
3264 Current plans call for this to happen when published versions of @code{g77}
3265 and @code{gdb} exist that provide proper access to debugging information on
3266 @code{COMMON} and @code{EQUIVALENCE} members.
3268 @cindex -femulate-complex option
3269 @cindex options, -femulate-complex
3270 @item -femulate-complex
3271 Implement @code{COMPLEX} arithmetic via emulation,
3272 instead of using the facilities of
3273 the @code{gcc} back end that provide direct support of
3274 @code{complex} arithmetic.
3276 (@code{gcc} had some bugs in its back-end support
3277 for @code{complex} arithmetic, due primarily to the support not being
3278 completed as of version 2.8.1 and @code{egcs} 1.1.2.)
3280 Use @samp{-femulate-complex} if you suspect code-generation bugs,
3281 or experience compiler crashes,
3282 that might result from @code{g77} using the @code{COMPLEX} support
3283 in the @code{gcc} back end.
3284 If using that option fixes the bugs or crashes you are seeing,
3285 that indicates a likely @code{g77} bugs
3286 (though, all compiler crashes are considered bugs),
3287 so, please report it.
3288 (Note that the known bugs, now believed fixed, produced compiler crashes
3289 rather than causing the generation of incorrect code.)
3291 Use of this option should not affect how Fortran code compiled
3292 by @code{g77} works in terms of its interfaces to other code,
3293 e.g. that compiled by @code{f2c}.
3295 @emph{Caution:} Future versions of @code{g77} might ignore both forms
3298 @cindex -falias-check option
3299 @cindex options, -falias-check
3300 @cindex -fargument-alias option
3301 @cindex options, -fargument-alias
3302 @cindex -fargument-noalias option
3303 @cindex options, -fargument-noalias
3304 @cindex -fno-argument-noalias-global option
3305 @cindex options, -fno-argument-noalias-global
3307 @item -fargument-alias
3308 @item -fargument-noalias
3309 @item -fno-argument-noalias-global
3310 @emph{Version info:}
3311 These options are not supported by
3312 versions of @code{g77} based on @code{gcc} version 2.8.
3314 These options specify to what degree aliasing
3316 is permitted between
3317 arguments (passed as pointers) and @code{COMMON} (external, or
3320 The default for Fortran code, as mandated by the FORTRAN 77 and
3321 Fortran 90 standards, is @samp{-fargument-noalias-global}.
3322 The default for code written in the C language family is
3323 @samp{-fargument-alias}.
3325 Note that, on some systems, compiling with @samp{-fforce-addr} in
3326 effect can produce more optimal code when the default aliasing
3327 options are in effect (and when optimization is enabled).
3329 @xref{Aliasing Assumed To Work}, for detailed information on the implications
3330 of compiling Fortran code that depends on the ability to alias dummy
3333 @cindex -fno-globals option
3334 @cindex options, -fno-globals
3336 @cindex global names, warning
3337 @cindex warnings, global names
3338 @cindex in-line code
3339 @cindex compilation, in-line
3340 Disable diagnostics about inter-procedural
3341 analysis problems, such as disagreements about the
3342 type of a function or a procedure's argument,
3343 that might cause a compiler crash when attempting
3344 to inline a reference to a procedure within a
3346 (The diagnostics themselves are still produced, but
3347 as warnings, unless @samp{-Wno-globals} is specified,
3348 in which case no relevant diagnostics are produced.)
3350 Further, this option disables such inlining, to
3351 avoid compiler crashes resulting from incorrect
3352 code that would otherwise be diagnosed.
3354 As such, this option might be quite useful when
3355 compiling existing, ``working'' code that happens
3356 to have a few bugs that do not generally show themselves,
3357 but which @code{g77} diagnoses.
3359 Use of this option therefore has the effect of
3360 instructing @code{g77} to behave more like it did
3361 up through version 0.5.19.1, when it paid little or
3362 no attention to disagreements between program units
3363 about a procedure's type and argument information,
3364 and when it performed no inlining of procedures
3365 (except statement functions).
3367 Without this option, @code{g77} defaults to performing
3368 the potentially inlining procedures as it started doing
3369 in version 0.5.20, but as of version 0.5.21, it also
3370 diagnoses disagreements that might cause such inlining
3371 to crash the compiler as (fatal) errors,
3372 and warns about similar disagreements
3373 that are currently believed to not
3374 likely to result in the compiler later crashing
3375 or producing incorrect code.
3378 @xref{Code Gen Options,,Options for Code Generation Conventions,
3379 gcc,Using and Porting GNU CC}, for information on more options
3381 shared by @code{g77}, @code{gcc}, and other GNU compilers.
3383 Some of these do @emph{not} work when compiling programs written in Fortran:
3386 @cindex -fpcc-struct-return option
3387 @cindex options, -fpcc-struct-return
3388 @item -fpcc-struct-return
3389 @cindex -freg-struct-return option
3390 @cindex options, -freg-struct-return
3391 @item -freg-struct-return
3392 You should not use these except strictly the same way as you
3393 used them to build the version of @code{libg2c} with which
3394 you will be linking all code compiled by @code{g77} with the
3397 @cindex -fshort-double option
3398 @cindex options, -fshort-double
3399 @item -fshort-double
3400 This probably either has no effect on Fortran programs, or
3401 makes them act loopy.
3403 @cindex -fno-common option
3404 @cindex options, -fno-common
3406 Do not use this when compiling Fortran programs,
3407 or there will be Trouble.
3409 @cindex -fpack-struct option
3410 @cindex options, -fpack-struct
3412 This probably will break any calls to the @code{libg2c} library,
3413 at the very least, even if it is built with the same option.
3416 @node Environment Variables
3417 @section Environment Variables Affecting GNU Fortran
3418 @cindex environment variables
3420 GNU Fortran currently does not make use of any environment
3421 variables to control its operation above and beyond those
3422 that affect the operation of @code{gcc}.
3424 @xref{Environment Variables,,Environment Variables Affecting GNU CC,
3425 gcc,Using and Porting GNU CC}, for information on environment
3435 @chapter The GNU Fortran Language
3437 @cindex standard, ANSI FORTRAN 77
3438 @cindex ANSI FORTRAN 77 standard
3439 @cindex reference works
3440 GNU Fortran supports a variety of extensions to, and dialects
3441 of, the Fortran language.
3442 Its primary base is the ANSI FORTRAN 77 standard, currently available on
3444 @uref{http://www.fortran.com/fortran/F77_std/rjcnf0001.html}
3445 or as monolithic text at
3446 @uref{http://www.fortran.com/fortran/F77_std/f77_std.html}.
3447 It offers some extensions that are popular among users
3448 of UNIX @code{f77} and @code{f2c} compilers, some that
3449 are popular among users of other compilers (such as Digital
3450 products), some that are popular among users of the
3451 newer Fortran 90 standard, and some that are introduced
3455 (If you need a text on Fortran,
3456 a few freely available electronic references have pointers from
3457 @uref{http://www.fortran.com/fortran/Books/}. There is a `cooperative
3458 net project', @cite{User Notes on Fortran Programming} at
3459 @uref{ftp://vms.huji.ac.il/fortran/} and mirrors elsewhere; some of this
3460 material might not apply specifically to @code{g77}.)
3462 Part of what defines a particular implementation of a Fortran
3463 system, such as @code{g77}, is the particular characteristics
3464 of how it supports types, constants, and so on.
3465 Much of this is left up to the implementation by the various
3466 Fortran standards and accepted practice in the industry.
3468 The GNU Fortran @emph{language} is described below.
3469 Much of the material is organized along the same lines
3470 as the ANSI FORTRAN 77 standard itself.
3472 @xref{Other Dialects}, for information on features @code{g77} supports
3473 that are not part of the GNU Fortran language.
3475 @emph{Note}: This portion of the documentation definitely needs a lot
3479 Relationship to the ANSI FORTRAN 77 standard:
3480 * Direction of Language Development:: Where GNU Fortran is headed.
3481 * Standard Support:: Degree of support for the standard.
3483 Extensions to the ANSI FORTRAN 77 standard:
3486 * Terms and Concepts::
3487 * Characters Lines Sequence::
3488 * Data Types and Constants::
3490 * Specification Statements::
3491 * Control Statements::
3492 * Functions and Subroutines::
3493 * Scope and Classes of Names::
3495 * Fortran 90 Features::
3498 @node Direction of Language Development
3499 @section Direction of Language Development
3500 @cindex direction of language development
3501 @cindex features, language
3502 @cindex language, features
3504 The purpose of the following description of the GNU Fortran
3505 language is to promote wide portability of GNU Fortran programs.
3507 GNU Fortran is an evolving language, due to the
3508 fact that @code{g77} itself is in beta test.
3509 Some current features of the language might later
3510 be redefined as dialects of Fortran supported by @code{g77}
3511 when better ways to express these features are added to @code{g77},
3513 Such features would still be supported by
3514 @code{g77}, but would be available only when
3515 one or more command-line options were used.
3517 The GNU Fortran @emph{language} is distinct from the
3518 GNU Fortran @emph{compilation system} (@code{g77}).
3520 For example, @code{g77} supports various dialects of
3521 Fortran---in a sense, these are languages other than
3522 GNU Fortran---though its primary
3523 purpose is to support the GNU Fortran language, which also is
3524 described in its documentation and by its implementation.
3526 On the other hand, non-GNU compilers might offer
3527 support for the GNU Fortran language, and are encouraged
3530 Currently, the GNU Fortran language is a fairly fuzzy object.
3531 It represents something of a cross between what @code{g77} accepts
3532 when compiling using the prevailing defaults and what this
3533 document describes as being part of the language.
3535 Future versions of @code{g77} are expected to clarify the
3536 definition of the language in the documentation.
3537 Often, this will mean adding new features to the language, in the form
3538 of both new documentation and new support in @code{g77}.
3539 However, it might occasionally mean removing a feature
3540 from the language itself to ``dialect'' status.
3541 In such a case, the documentation would be adjusted
3542 to reflect the change, and @code{g77} itself would likely be changed
3543 to require one or more command-line options to continue supporting
3546 The development of the GNU Fortran language is intended to strike
3551 Serving as a mostly-upwards-compatible language from the
3552 de facto UNIX Fortran dialect as supported by @code{f77}.
3555 Offering new, well-designed language features.
3556 Attributes of such features include
3557 not making existing code any harder to read
3558 (for those who might be unaware that the new
3559 features are not in use) and
3560 not making state-of-the-art
3561 compilers take longer to issue diagnostics,
3565 Supporting existing, well-written code without gratuitously
3566 rejecting non-standard constructs, regardless of the origin
3567 of the code (its dialect).
3570 Offering default behavior and command-line options to reduce
3571 and, where reasonable, eliminate the need for programmers to make
3572 any modifications to code that already works in existing
3573 production environments.
3576 Diagnosing constructs that have different meanings in different
3577 systems, languages, and dialects, while offering clear,
3578 less ambiguous ways to express each of the different meanings
3579 so programmers can change their code appropriately.
3582 One of the biggest practical challenges for the developers of the
3583 GNU Fortran language is meeting the sometimes contradictory demands
3586 For example, a feature might be widely used in one popular environment,
3587 but the exact same code that utilizes that feature might not work
3588 as expected---perhaps it might mean something entirely different---in
3589 another popular environment.
3591 Traditionally, Fortran compilers---even portable ones---have solved this
3592 problem by simply offering the appropriate feature to users of
3593 the respective systems.
3594 This approach treats users of various Fortran systems and dialects
3595 as remote ``islands'', or camps, of programmers, and assume that these
3596 camps rarely come into contact with each other (or,
3597 especially, with each other's code).
3599 Project GNU takes a radically different approach to software and language
3600 design, in that it assumes that users of GNU software do not necessarily
3601 care what kind of underlying system they are using, regardless
3602 of whether they are using software (at the user-interface
3603 level) or writing it (for example, writing Fortran or C code).
3605 As such, GNU users rarely need consider just what kind of underlying
3606 hardware (or, in many cases, operating system) they are using at any
3608 They can use and write software designed for a general-purpose,
3609 widely portable, heterogenous environment---the GNU environment.
3611 In line with this philosophy, GNU Fortran must evolve into a product
3612 that is widely ported and portable not only in the sense that it can
3613 be successfully built, installed, and run by users, but in the larger
3614 sense that its users can use it in the same way, and expect largely the
3615 same behaviors from it, regardless of the kind of system they are using
3616 at any particular time.
3618 This approach constrains the solutions @code{g77} can use to resolve
3619 conflicts between various camps of Fortran users.
3620 If these two camps disagree about what a particular construct should
3621 mean, @code{g77} cannot simply be changed to treat that particular construct as
3622 having one meaning without comment (such as a warning), lest the users
3623 expecting it to have the other meaning are unpleasantly surprised that
3624 their code misbehaves when executed.
3626 The use of the ASCII backslash character in character constants is
3627 an excellent (and still somewhat unresolved) example of this kind of
3629 @xref{Backslash in Constants}.
3630 Other examples are likely to arise in the future, as @code{g77} developers
3631 strive to improve its ability to accept an ever-wider variety of existing
3632 Fortran code without requiring significant modifications to said code.
3634 Development of GNU Fortran is further constrained by the desire
3635 to avoid requiring programmers to change their code.
3636 This is important because it allows programmers, administrators,
3637 and others to more faithfully evaluate and validate @code{g77}
3638 (as an overall product and as new versions are distributed)
3639 without having to support multiple versions of their programs
3640 so that they continue to work the same way on their existing
3641 systems (non-GNU perhaps, but possibly also earlier versions
3644 @node Standard Support
3645 @section ANSI FORTRAN 77 Standard Support
3646 @cindex ANSI FORTRAN 77 support
3647 @cindex standard, support for
3648 @cindex support, FORTRAN 77
3649 @cindex compatibility, FORTRAN 77
3650 @cindex FORTRAN 77 compatibility
3652 GNU Fortran supports ANSI FORTRAN 77 with the following caveats.
3653 In summary, the only ANSI FORTRAN 77 features @code{g77} doesn't
3654 support are those that are probably rarely used in actual code,
3655 some of which are explicitly disallowed by the Fortran 90 standard.
3658 * No Passing External Assumed-length:: CHAR*(*) CFUNC restriction.
3659 * No Passing Dummy Assumed-length:: CHAR*(*) CFUNC restriction.
3660 * No Pathological Implied-DO:: No @samp{((@dots{}, I=@dots{}), I=@dots{})}.
3661 * No Useless Implied-DO:: No @samp{(A, I=1, 1)}.
3664 @node No Passing External Assumed-length
3665 @subsection No Passing External Assumed-length
3667 @code{g77} disallows passing of an external procedure
3668 as an actual argument if the procedure's
3669 type is declared @code{CHARACTER*(*)}. For example:
3679 It isn't clear whether the standard considers this conforming.
3681 @node No Passing Dummy Assumed-length
3682 @subsection No Passing Dummy Assumed-length
3684 @code{g77} disallows passing of a dummy procedure
3685 as an actual argument if the procedure's
3686 type is declared @code{CHARACTER*(*)}.
3689 SUBROUTINE BAR(CFUNC)
3697 It isn't clear whether the standard considers this conforming.
3699 @node No Pathological Implied-DO
3700 @subsection No Pathological Implied-DO
3702 The @code{DO} variable for an implied-@code{DO} construct in a
3703 @code{DATA} statement may not be used as the @code{DO} variable
3704 for an outer implied-@code{DO} construct. For example, this
3705 fragment is disallowed by @code{g77}:
3708 DATA ((A(I, I), I= 1, 10), I= 1, 10) /@dots{}/
3712 This also is disallowed by Fortran 90, as it offers no additional
3713 capabilities and would have a variety of possible meanings.
3715 Note that it is @emph{very} unlikely that any production Fortran code
3716 tries to use this unsupported construct.
3718 @node No Useless Implied-DO
3719 @subsection No Useless Implied-DO
3721 An array element initializer in an implied-@code{DO} construct in a
3722 @code{DATA} statement must contain at least one reference to the @code{DO}
3723 variables of each outer implied-@code{DO} construct. For example,
3724 this fragment is disallowed by @code{g77}:
3727 DATA (A, I= 1, 1) /1./
3731 This also is disallowed by Fortran 90, as FORTRAN 77's more permissive
3732 requirements offer no additional capabilities.
3733 However, @code{g77} doesn't necessarily diagnose all cases
3734 where this requirement is not met.
3736 Note that it is @emph{very} unlikely that any production Fortran code
3737 tries to use this unsupported construct.
3740 @section Conformance
3742 (The following information augments or overrides the information in
3743 Section 1.4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3745 Chapter 1 of that document otherwise serves as the basis
3746 for the relevant aspects of GNU Fortran.)
3748 The definition of the GNU Fortran language is akin to that of
3749 the ANSI FORTRAN 77 language in that it does not generally require
3750 conforming implementations to diagnose cases where programs do
3751 not conform to the language.
3753 However, @code{g77} as a compiler is being developed in a way that
3754 is intended to enable it to diagnose such cases in an easy-to-understand
3757 A program that conforms to the GNU Fortran language should, when
3758 compiled, linked, and executed using a properly installed @code{g77}
3759 system, perform as described by the GNU Fortran language definition.
3760 Reasons for different behavior include, among others:
3764 Use of resources (memory---heap, stack, and so on; disk space; CPU
3765 time; etc.) exceeds those of the system.
3768 Range and/or precision of calculations required by the program
3769 exceeds that of the system.
3772 Excessive reliance on behaviors that are system-dependent
3773 (non-portable Fortran code).
3776 Bugs in the program.
3785 Despite these ``loopholes'', the availability of a clear specification
3786 of the language of programs submitted to @code{g77}, as this document
3787 is intended to provide, is considered an important aspect of providing
3788 a robust, clean, predictable Fortran implementation.
3790 The definition of the GNU Fortran language, while having no special
3791 legal status, can therefore be viewed as a sort of contract, or agreement.
3792 This agreement says, in essence, ``if you write a program in this language,
3793 and run it in an environment (such as a @code{g77} system) that supports
3794 this language, the program should behave in a largely predictable way''.
3797 @section Notation Used in This Chapter
3799 (The following information augments or overrides the information in
3800 Section 1.5 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3802 Chapter 1 of that document otherwise serves as the basis
3803 for the relevant aspects of GNU Fortran.)
3805 In this chapter, ``must'' denotes a requirement, ``may'' denotes permission,
3806 and ``must not'' and ``may not'' denote prohibition.
3807 Terms such as ``might'', ``should'', and ``can'' generally add little or
3808 nothing in the way of weight to the GNU Fortran language itself,
3809 but are used to explain or illustrate the language.
3814 ``The @code{FROBNITZ} statement must precede all executable
3815 statements in a program unit, and may not specify any dummy
3816 arguments. It may specify local or common variables and arrays.
3817 Its use should be limited to portions of the program designed to
3818 be non-portable and system-specific, because it might cause the
3819 containing program unit to behave quite differently on different
3823 Insofar as the GNU Fortran language is specified,
3824 the requirements and permissions denoted by the above sample statement
3825 are limited to the placement of the statement and the kinds of
3826 things it may specify.
3827 The rest of the statement---the content regarding non-portable portions
3828 of the program and the differing behavior of program units containing
3829 the @code{FROBNITZ} statement---does not pertain the GNU Fortran
3831 That content offers advice and warnings about the @code{FROBNITZ}
3834 @emph{Remember:} The GNU Fortran language definition specifies
3835 both what constitutes a valid GNU Fortran program and how,
3836 given such a program, a valid GNU Fortran implementation is
3837 to interpret that program.
3839 It is @emph{not} incumbent upon a valid GNU Fortran implementation
3840 to behave in any particular way, any consistent way, or any
3841 predictable way when it is asked to interpret input that is
3842 @emph{not} a valid GNU Fortran program.
3844 Such input is said to have @dfn{undefined} behavior when
3845 interpreted by a valid GNU Fortran implementation, though
3846 an implementation may choose to specify behaviors for some
3847 cases of inputs that are not valid GNU Fortran programs.
3849 Other notation used herein is that of the GNU texinfo format,
3850 which is used to generate printed hardcopy, on-line hypertext
3851 (Info), and on-line HTML versions, all from a single source
3853 This notation is used as follows:
3857 Keywords defined by the GNU Fortran language are shown
3858 in uppercase, as in: @code{COMMON}, @code{INTEGER}, and
3861 Note that, in practice, many Fortran programs are written
3862 in lowercase---uppercase is used in this manual as a
3863 means to readily distinguish keywords and sample Fortran-related
3864 text from the prose in this document.
3867 Portions of actual sample program, input, or output text
3868 look like this: @samp{Actual program text}.
3870 Generally, uppercase is used for all Fortran-specific and
3871 Fortran-related text, though this does not always include
3872 literal text within Fortran code.
3874 For example: @samp{PRINT *, 'My name is Bob'}.
3877 A metasyntactic variable---that is, a name used in this document
3878 to serve as a placeholder for whatever text is used by the
3879 user or programmer--appears as shown in the following example:
3881 ``The @code{INTEGER @var{ivar}} statement specifies that
3882 @var{ivar} is a variable or array of type @code{INTEGER}.''
3884 In the above example, any valid text may be substituted for
3885 the metasyntactic variable @var{ivar} to make the statement
3886 apply to a specific instance, as long as the same text is
3887 substituted for @emph{both} occurrences of @var{ivar}.
3890 Ellipses (``@dots{}'') are used to indicate further text that
3891 is either unimportant or expanded upon further, elsewhere.
3894 Names of data types are in the style of Fortran 90, in most
3897 @xref{Kind Notation}, for information on the relationship
3898 between Fortran 90 nomenclature (such as @code{INTEGER(KIND=1)})
3899 and the more traditional, less portably concise nomenclature
3900 (such as @code{INTEGER*4}).
3903 @node Terms and Concepts
3904 @section Fortran Terms and Concepts
3906 (The following information augments or overrides the information in
3907 Chapter 2 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
3909 Chapter 2 of that document otherwise serves as the basis
3910 for the relevant aspects of GNU Fortran.)
3914 * Statements Comments Lines::
3915 * Scope of Names and Labels::
3918 @node Syntactic Items
3919 @subsection Syntactic Items
3921 (Corresponds to Section 2.2 of ANSI X3.9-1978 FORTRAN 77.)
3923 @cindex limits, lengths of names
3924 In GNU Fortran, a symbolic name is at least one character long,
3925 and has no arbitrary upper limit on length.
3926 However, names of entities requiring external linkage (such as
3927 external functions, external subroutines, and @code{COMMON} areas)
3928 might be restricted to some arbitrary length by the system.
3929 Such a restriction is no more constrained than that of one
3930 through six characters.
3932 Underscores (@samp{_}) are accepted in symbol names after the first
3933 character (which must be a letter).
3935 @node Statements Comments Lines
3936 @subsection Statements, Comments, and Lines
3938 (Corresponds to Section 2.3 of ANSI X3.9-1978 FORTRAN 77.)
3940 @cindex trailing comment
3942 @cindex characters, comment
3944 @cindex exclamation point
3945 @cindex continuation character
3946 @cindex characters, continuation
3947 Use of an exclamation point (@samp{!}) to begin a
3948 trailing comment (a comment that extends to the end of the same
3949 source line) is permitted under the following conditions:
3953 The exclamation point does not appear in column 6.
3954 Otherwise, it is treated as an indicator of a continuation
3958 The exclamation point appears outside a character or Hollerith
3960 Otherwise, the exclamation point is considered part of the
3964 The exclamation point appears to the left of any other possible
3966 That is, a trailing comment may contain exclamation points
3967 in their commentary text.
3972 @cindex statements, separated by semicolon
3973 Use of a semicolon (@samp{;}) as a statement separator
3974 is permitted under the following conditions:
3978 The semicolon appears outside a character or Hollerith
3980 Otherwise, the semicolon is considered part of the
3984 The semicolon appears to the left of a trailing comment.
3985 Otherwise, the semicolon is considered part of that
3989 Neither a logical @code{IF} statement nor a non-construct
3990 @code{WHERE} statement (a Fortran 90 feature) may be
3991 followed (in the same, possibly continued, line) by
3992 a semicolon used as a statement separator.
3994 This restriction avoids the confusion
3995 that can result when reading a line such as:
3998 IF (VALIDP) CALL FOO; CALL BAR
4002 Some readers might think the @samp{CALL BAR} is executed
4003 only if @samp{VALIDP} is @code{.TRUE.}, while others might
4004 assume its execution is unconditional.
4006 (At present, @code{g77} does not diagnose code that
4007 violates this restriction.)
4010 @node Scope of Names and Labels
4011 @subsection Scope of Symbolic Names and Statement Labels
4014 (Corresponds to Section 2.9 of ANSI X3.9-1978 FORTRAN 77.)
4016 Included in the list of entities that have a scope of a
4017 program unit are construct names (a Fortran 90 feature).
4018 @xref{Construct Names}, for more information.
4020 @node Characters Lines Sequence
4021 @section Characters, Lines, and Execution Sequence
4023 (The following information augments or overrides the information in
4024 Chapter 3 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4026 Chapter 3 of that document otherwise serves as the basis
4027 for the relevant aspects of GNU Fortran.)
4032 * Continuation Line::
4034 * Statement Labels::
4037 * Cpp-style directives::
4041 @subsection GNU Fortran Character Set
4044 (Corresponds to Section 3.1 of ANSI X3.9-1978 FORTRAN 77.)
4046 Letters include uppercase letters (the twenty-six characters
4047 of the English alphabet) and lowercase letters (their lowercase
4049 Generally, lowercase letters may be used in place of uppercase
4050 letters, though in character and Hollerith constants, they
4053 Special characters include:
4059 Semicolon (@samp{;})
4063 @cindex exclamation point
4064 Exclamation point (@samp{!})
4068 @cindex double quote
4069 Double quote (@samp{"})
4074 Backslash (@samp{\})
4078 @cindex question mark
4079 Question mark (@samp{?})
4085 Hash mark (@samp{#})
4090 Ampersand (@samp{&})
4094 @cindex percent sign
4095 Percent sign (@samp{%})
4100 Underscore (@samp{_})
4106 @cindex open bracket
4107 @cindex left bracket
4108 Open angle (@samp{<})
4114 @cindex close bracket
4115 @cindex right bracket
4116 Close angle (@samp{>})
4119 The FORTRAN 77 special characters (@key{SPC}, @samp{=},
4120 @samp{+}, @samp{-}, @samp{*}, @samp{/}, @samp{(},
4121 @samp{)}, @samp{,}, @samp{.}, @samp{$}, @samp{'},
4128 Note that this document refers to @key{SPC} as @dfn{space},
4129 while X3.9-1978 FORTRAN 77 refers to it as @dfn{blank}.
4134 @cindex source file format
4135 @cindex source format
4136 @cindex file, source
4138 @cindex code, source
4142 (Corresponds to Section 3.2 of ANSI X3.9-1978 FORTRAN 77.)
4144 The way a Fortran compiler views source files depends entirely on the
4145 implementation choices made for the compiler, since those choices
4146 are explicitly left to the implementation by the published Fortran
4149 The GNU Fortran language mandates a view applicable to UNIX-like
4150 text files---files that are made up of an arbitrary number of lines,
4151 each with an arbitrary number of characters (sometimes called stream-based
4154 This view does not apply to types of files that are specified as
4155 having a particular number of characters on every single line (sometimes
4156 referred to as record-based files).
4158 Because a ``line in a program unit is a sequence of 72 characters'',
4159 to quote X3.9-1978, the GNU Fortran language specifies that a
4160 stream-based text file is translated to GNU Fortran lines as follows:
4164 A newline in the file is the character that represents the end of
4165 a line of text to the underlying system.
4166 For example, on ASCII-based systems, a newline is the @key{NL}
4167 character, which has ASCII value 12 (decimal).
4170 Each newline in the file serves to end the line of text that precedes
4171 it (and that does not contain a newline).
4174 The end-of-file marker (@code{EOF}) also serves to end the line
4175 of text that precedes it (and that does not contain a newline).
4181 Any line of text that is shorter than 72 characters is padded to that length
4182 with spaces (called ``blanks'' in the standard).
4185 Any line of text that is longer than 72 characters is truncated to that
4186 length, but the truncated remainder must consist entirely of spaces.
4189 Characters other than newline and the GNU Fortran character set
4193 For the purposes of the remainder of this description of the GNU
4194 Fortran language, the translation described above has already
4195 taken place, unless otherwise specified.
4197 The result of the above translation is that the source file appears,
4198 in terms of the remainder of this description of the GNU Fortran language,
4199 as if it had an arbitrary
4200 number of 72-character lines, each character being among the GNU Fortran
4203 For example, if the source file itself has two newlines in a row,
4204 the second newline becomes, after the above translation, a single
4205 line containing 72 spaces.
4207 @node Continuation Line
4208 @subsection Continuation Line
4209 @cindex continuation line, number of
4210 @cindex lines, continuation
4211 @cindex number of continuation lines
4212 @cindex limits, continuation lines
4214 (Corresponds to Section 3.2.3 of ANSI X3.9-1978 FORTRAN 77.)
4216 A continuation line is any line that both
4220 Contains a continuation character, and
4223 Contains only spaces in columns 1 through 5
4226 A continuation character is any character of the GNU Fortran character set
4227 other than space (@key{SPC}) or zero (@samp{0})
4228 in column 6, or a digit (@samp{0} through @samp{9}) in column
4229 7 through 72 of a line that has only spaces to the left of that
4232 The continuation character is ignored as far as the content of
4233 the statement is concerned.
4235 The GNU Fortran language places no limit on the number of
4236 continuation lines in a statement.
4237 In practice, the limit depends on a variety of factors, such as
4238 available memory, statement content, and so on, but no
4239 GNU Fortran system may impose an arbitrary limit.
4242 @subsection Statements
4244 (Corresponds to Section 3.3 of ANSI X3.9-1978 FORTRAN 77.)
4246 Statements may be written using an arbitrary number of continuation
4249 Statements may be separated using the semicolon (@samp{;}), except
4250 that the logical @code{IF} and non-construct @code{WHERE} statements
4251 may not be separated from subsequent statements using only a semicolon
4252 as statement separator.
4254 The @code{END PROGRAM}, @code{END SUBROUTINE}, @code{END FUNCTION},
4255 and @code{END BLOCK DATA} statements are alternatives to the @code{END}
4257 These alternatives may be written as normal statements---they are not
4258 subject to the restrictions of the @code{END} statement.
4260 However, no statement other than @code{END} may have an initial line
4261 that appears to be an @code{END} statement---even @code{END PROGRAM},
4262 for example, must not be written as:
4269 @node Statement Labels
4270 @subsection Statement Labels
4272 (Corresponds to Section 3.4 of ANSI X3.9-1978 FORTRAN 77.)
4274 A statement separated from its predecessor via a semicolon may be
4279 The semicolon is followed by the label for the statement,
4280 which in turn follows the label.
4283 The label must be no more than five digits in length.
4286 The first digit of the label for the statement is not
4287 the first non-space character on a line.
4288 Otherwise, that character is treated as a continuation
4292 A statement may have only one label defined for it.
4295 @subsection Order of Statements and Lines
4297 (Corresponds to Section 3.5 of ANSI X3.9-1978 FORTRAN 77.)
4299 Generally, @code{DATA} statements may precede executable statements.
4300 However, specification statements pertaining to any entities
4301 initialized by a @code{DATA} statement must precede that @code{DATA}
4304 after @samp{DATA I/1/}, @samp{INTEGER I} is not permitted, but
4305 @samp{INTEGER J} is permitted.
4307 The last line of a program unit may be an @code{END} statement,
4312 An @code{END PROGRAM} statement, if the program unit is a main program.
4315 An @code{END SUBROUTINE} statement, if the program unit is a subroutine.
4318 An @code{END FUNCTION} statement, if the program unit is a function.
4321 An @code{END BLOCK DATA} statement, if the program unit is a block data.
4325 @subsection Including Source Text
4326 @cindex INCLUDE directive
4328 Additional source text may be included in the processing of
4329 the source file via the @code{INCLUDE} directive:
4332 INCLUDE @var{filename}
4336 The source text to be included is identified by @var{filename},
4337 which is a literal GNU Fortran character constant.
4338 The meaning and interpretation of @var{filename} depends on the
4339 implementation, but typically is a filename.
4341 (@code{g77} treats it as a filename that it searches for
4342 in the current directory and/or directories specified
4343 via the @samp{-I} command-line option.)
4345 The effect of the @code{INCLUDE} directive is as if the
4346 included text directly replaced the directive in the source
4347 file prior to interpretation of the program.
4348 Included text may itself use @code{INCLUDE}.
4349 The depth of nested @code{INCLUDE} references depends on
4350 the implementation, but typically is a positive integer.
4352 This virtual replacement treats the statements and @code{INCLUDE}
4353 directives in the included text as syntactically distinct from
4354 those in the including text.
4356 Therefore, the first non-comment line of the included text
4357 must not be a continuation line.
4358 The included text must therefore have, after the non-comment
4359 lines, either an initial line (statement), an @code{INCLUDE}
4360 directive, or nothing (the end of the included text).
4362 Similarly, the including text may end the @code{INCLUDE}
4363 directive with a semicolon or the end of the line, but it
4364 cannot follow an @code{INCLUDE} directive at the end of its
4365 line with a continuation line.
4366 Thus, the last statement in an included text may not be
4369 Any statements between two @code{INCLUDE} directives on the
4370 same line are treated as if they appeared in between the
4371 respective included texts.
4375 INCLUDE 'A'; PRINT *, 'B'; INCLUDE 'C'; END PROGRAM
4379 If the text included by @samp{INCLUDE 'A'} constitutes
4380 a @samp{PRINT *, 'A'} statement and the text included by
4381 @samp{INCLUDE 'C'} constitutes a @samp{PRINT *, 'C'} statement,
4382 then the output of the above sample program would be
4391 (with suitable allowances for how an implementation defines
4392 its handling of output).
4394 Included text must not include itself directly or indirectly,
4395 regardless of whether the @var{filename} used to reference
4396 the text is the same.
4398 Note that @code{INCLUDE} is @emph{not} a statement.
4399 As such, it is neither a non-executable or executable
4401 However, if the text it includes constitutes one or more
4402 executable statements, then the placement of @code{INCLUDE}
4403 is subject to effectively the same restrictions as those
4404 on executable statements.
4406 An @code{INCLUDE} directive may be continued across multiple
4407 lines as if it were a statement.
4408 This permits long names to be used for @var{filename}.
4410 @node Cpp-style directives
4411 @subsection Cpp-style directives
4413 @cindex preprocessor
4415 @code{cpp} output-style @code{#} directives @xref{C Preprocessor
4416 Output,,, cpp, The C Preprocessor}, are recognized by the compiler even
4417 when the preprocessor isn't run on the input (as it is when compiling
4418 @samp{.F} files). (Note the distinction between these @code{cpp}
4419 @code{#} @emph{output} directives and @code{#line} @emph{input}
4422 @node Data Types and Constants
4423 @section Data Types and Constants
4425 (The following information augments or overrides the information in
4426 Chapter 4 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
4428 Chapter 4 of that document otherwise serves as the basis
4429 for the relevant aspects of GNU Fortran.)
4431 To more concisely express the appropriate types for
4432 entities, this document uses the more concise
4433 Fortran 90 nomenclature such as @code{INTEGER(KIND=1)}
4434 instead of the more traditional, but less portably concise,
4435 byte-size-based nomenclature such as @code{INTEGER*4},
4436 wherever reasonable.
4438 When referring to generic types---in contexts where the
4439 specific precision and range of a type are not important---this
4440 document uses the generic type names @code{INTEGER}, @code{LOGICAL},
4441 @code{REAL}, @code{COMPLEX}, and @code{CHARACTER}.
4443 In some cases, the context requires specification of a
4445 This document uses the @samp{KIND=} notation to accomplish
4446 this throughout, sometimes supplying the more traditional
4447 notation for clarification, though the traditional notation
4448 might not work the same way on all GNU Fortran implementations.
4450 Use of @samp{KIND=} makes this document more concise because
4451 @code{g77} is able to define values for @samp{KIND=} that
4452 have the same meanings on all systems, due to the way the
4453 Fortran 90 standard specifies these values are to be used.
4455 (In particular, that standard permits an implementation to
4456 arbitrarily assign nonnegative values.
4457 There are four distinct sets of assignments: one to the @code{CHARACTER}
4458 type; one to the @code{INTEGER} type; one to the @code{LOGICAL} type;
4459 and the fourth to both the @code{REAL} and @code{COMPLEX} types.
4460 Implementations are free to assign these values in any order,
4461 leave gaps in the ordering of assignments, and assign more than
4462 one value to a representation.)
4464 This makes @samp{KIND=} values superior to the values used
4465 in non-standard statements such as @samp{INTEGER*4}, because
4466 the meanings of the values in those statements vary from machine
4467 to machine, compiler to compiler, even operating system to
4470 However, use of @samp{KIND=} is @emph{not} generally recommended
4471 when writing portable code (unless, for example, the code is
4472 going to be compiled only via @code{g77}, which is a widely
4474 GNU Fortran does not yet have adequate language constructs to
4475 permit use of @samp{KIND=} in a fashion that would make the
4476 code portable to Fortran 90 implementations; and, this construct
4477 is known to @emph{not} be accepted by many popular FORTRAN 77
4478 implementations, so it cannot be used in code that is to be ported
4481 The distinction here is that this document is able to use
4482 specific values for @samp{KIND=} to concisely document the
4483 types of various operations and operands.
4485 A Fortran program should use the FORTRAN 77 designations for the
4486 appropriate GNU Fortran types---such as @code{INTEGER} for
4487 @code{INTEGER(KIND=1)}, @code{REAL} for @code{REAL(KIND=1)},
4488 and @code{DOUBLE COMPLEX} for @code{COMPLEX(KIND=2)}---and,
4489 where no such designations exist, make use of appropriate
4490 techniques (preprocessor macros, parameters, and so on)
4491 to specify the types in a fashion that may be easily adjusted
4492 to suit each particular implementation to which the program
4494 (These types generally won't need to be adjusted for ports of
4497 Further details regarding GNU Fortran data types and constants
4508 @subsection Data Types
4510 (Corresponds to Section 4.1 of ANSI X3.9-1978 FORTRAN 77.)
4512 GNU Fortran supports these types:
4516 Integer (generic type @code{INTEGER})
4519 Real (generic type @code{REAL})
4525 Complex (generic type @code{COMPLEX})
4528 Logical (generic type @code{LOGICAL})
4531 Character (generic type @code{CHARACTER})
4537 (The types numbered 1 through 6 above are standard FORTRAN 77 types.)
4539 The generic types shown above are referred to in this document
4540 using only their generic type names.
4541 Such references usually indicate that any specific type (kind)
4542 of that generic type is valid.
4544 For example, a context described in this document as accepting
4545 the @code{COMPLEX} type also is likely to accept the
4546 @code{DOUBLE COMPLEX} type.
4548 The GNU Fortran language supports three ways to specify
4549 a specific kind of a generic type.
4552 * Double Notation:: As in @code{DOUBLE COMPLEX}.
4553 * Star Notation:: As in @code{INTEGER*4}.
4554 * Kind Notation:: As in @code{INTEGER(KIND=1)}.
4557 @node Double Notation
4558 @subsubsection Double Notation
4560 The GNU Fortran language supports two uses of the keyword
4561 @code{DOUBLE} to specify a specific kind of type:
4565 @code{DOUBLE PRECISION}, equivalent to @code{REAL(KIND=2)}
4568 @code{DOUBLE COMPLEX}, equivalent to @code{COMPLEX(KIND=2)}
4571 Use one of the above forms where a type name is valid.
4573 While use of this notation is popular, it doesn't scale
4574 well in a language or dialect rich in intrinsic types,
4575 as is the case for the GNU Fortran language (especially
4576 planned future versions of it).
4578 After all, one rarely sees type names such as @samp{DOUBLE INTEGER},
4579 @samp{QUADRUPLE REAL}, or @samp{QUARTER INTEGER}.
4580 Instead, @code{INTEGER*8}, @code{REAL*16}, and @code{INTEGER*1}
4581 often are substituted for these, respectively, even though they
4582 do not always have the same meanings on all systems.
4583 (And, the fact that @samp{DOUBLE REAL} does not exist as such
4584 is an inconsistency.)
4586 Therefore, this document uses ``double notation'' only on occasion
4587 for the benefit of those readers who are accustomed to it.
4590 @subsubsection Star Notation
4591 @cindex *@var{n} notation
4593 The following notation specifies the storage size for a type:
4596 @var{generic-type}*@var{n}
4600 @var{generic-type} must be a generic type---one of
4601 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4602 or @code{CHARACTER}.
4603 @var{n} must be one or more digits comprising a decimal
4604 integer number greater than zero.
4606 Use the above form where a type name is valid.
4608 The @samp{*@var{n}} notation specifies that the amount of storage
4609 occupied by variables and array elements of that type is @var{n}
4610 times the storage occupied by a @code{CHARACTER*1} variable.
4612 This notation might indicate a different degree of precision and/or
4613 range for such variables and array elements, and the functions that
4614 return values of types using this notation.
4615 It does not limit the precision or range of values of that type
4616 in any particular way---use explicit code to do that.
4618 Further, the GNU Fortran language requires no particular values
4619 for @var{n} to be supported by an implementation via the @samp{*@var{n}}
4621 @code{g77} supports @code{INTEGER*1} (as @code{INTEGER(KIND=3)})
4622 on all systems, for example,
4623 but not all implementations are required to do so, and @code{g77}
4624 is known to not support @code{REAL*1} on most (or all) systems.
4626 As a result, except for @var{generic-type} of @code{CHARACTER},
4627 uses of this notation should be limited to isolated
4628 portions of a program that are intended to handle system-specific
4629 tasks and are expected to be non-portable.
4631 (Standard FORTRAN 77 supports the @samp{*@var{n}} notation for
4632 only @code{CHARACTER}, where it signifies not only the amount
4633 of storage occupied, but the number of characters in entities
4635 However, almost all Fortran compilers have supported this
4636 notation for generic types, though with a variety of meanings
4639 Specifications of types using the @samp{*@var{n}} notation
4640 always are interpreted as specifications of the appropriate
4641 types described in this document using the @samp{KIND=@var{n}}
4642 notation, described below.
4644 While use of this notation is popular, it doesn't serve well
4645 in the context of a widely portable dialect of Fortran, such as
4646 the GNU Fortran language.
4648 For example, even on one particular machine, two or more popular
4649 Fortran compilers might well disagree on the size of a type
4650 declared @code{INTEGER*2} or @code{REAL*16}.
4652 is known to be disagreement over such things among Fortran
4653 compilers on @emph{different} systems.
4655 Further, this notation offers no elegant way to specify sizes
4656 that are not even multiples of the ``byte size'' typically
4657 designated by @code{INTEGER*1}.
4658 Use of ``absurd'' values (such as @code{INTEGER*1000}) would
4659 certainly be possible, but would perhaps be stretching the original
4660 intent of this notation beyond the breaking point in terms
4661 of widespread readability of documentation and code making use
4664 Therefore, this document uses ``star notation'' only on occasion
4665 for the benefit of those readers who are accustomed to it.
4668 @subsubsection Kind Notation
4669 @cindex KIND= notation
4671 The following notation specifies the kind-type selector of a type:
4674 @var{generic-type}(KIND=@var{n})
4678 Use the above form where a type name is valid.
4680 @var{generic-type} must be a generic type---one of
4681 @code{INTEGER}, @code{REAL}, @code{COMPLEX}, @code{LOGICAL},
4682 or @code{CHARACTER}.
4683 @var{n} must be an integer initialization expression that
4684 is a positive, nonzero value.
4686 Programmers are discouraged from writing these values directly
4688 Future versions of the GNU Fortran language will offer
4689 facilities that will make the writing of code portable
4690 to @code{g77} @emph{and} Fortran 90 implementations simpler.
4692 However, writing code that ports to existing FORTRAN 77
4693 implementations depends on avoiding the @samp{KIND=} construct.
4695 The @samp{KIND=} construct is thus useful in the context
4696 of GNU Fortran for two reasons:
4700 It provides a means to specify a type in a fashion that
4701 is portable across all GNU Fortran implementations (though
4702 not other FORTRAN 77 and Fortran 90 implementations).
4705 It provides a sort of Rosetta stone for this document to use
4706 to concisely describe the types of various operations and
4710 The values of @var{n} in the GNU Fortran language are
4711 assigned using a scheme that:
4715 Attempts to maximize the ability of readers
4716 of this document to quickly familiarize themselves
4717 with assignments for popular types
4720 Provides a unique value for each specific desired
4724 Provides a means to automatically assign new values so
4725 they have a ``natural'' relationship to existing values,
4726 if appropriate, or, if no such relationship exists, will
4727 not interfere with future values assigned on the basis
4728 of such relationships
4731 Avoids using values that are similar to values used
4732 in the existing, popular @samp{*@var{n}} notation,
4733 to prevent readers from expecting that these implied
4734 correspondences work on all GNU Fortran implementations
4737 The assignment system accomplishes this by assigning
4738 to each ``fundamental meaning'' of a specific type a
4739 unique prime number.
4740 Combinations of fundamental meanings---for example, a type
4741 that is two times the size of some other type---are assigned
4742 values of @var{n} that are the products of the values for
4743 those fundamental meanings.
4745 A prime value of @var{n} is never given more than one fundamental
4746 meaning, to avoid situations where some code or system
4747 cannot reasonably provide those meanings in the form of a
4750 The values of @var{n} assigned so far are:
4754 This value is reserved for future use.
4756 The planned future use is for this value to designate,
4757 explicitly, context-sensitive kind-type selection.
4758 For example, the expression @samp{1D0 * 0.1_0} would
4759 be equivalent to @samp{1D0 * 0.1D0}.
4762 This corresponds to the default types for
4763 @code{REAL}, @code{INTEGER}, @code{LOGICAL}, @code{COMPLEX},
4764 and @code{CHARACTER}, as appropriate.
4766 These are the ``default'' types described in the Fortran 90 standard,
4767 though that standard does not assign any particular @samp{KIND=}
4768 value to these types.
4770 (Typically, these are @code{REAL*4}, @code{INTEGER*4},
4771 @code{LOGICAL*4}, and @code{COMPLEX*8}.)
4774 This corresponds to types that occupy twice as much
4775 storage as the default types.
4776 @code{REAL(KIND=2)} is @code{DOUBLE PRECISION} (typically @code{REAL*8}),
4777 @code{COMPLEX(KIND=2)} is @code{DOUBLE COMPLEX} (typically @code{COMPLEX*16}),
4779 These are the ``double precision'' types described in the Fortran 90
4781 though that standard does not assign any particular @samp{KIND=}
4782 value to these types.
4784 @var{n} of 4 thus corresponds to types that occupy four times
4785 as much storage as the default types, @var{n} of 8 to types that
4786 occupy eight times as much storage, and so on.
4788 The @code{INTEGER(KIND=2)} and @code{LOGICAL(KIND=2)} types
4789 are not necessarily supported by every GNU Fortran implementation.
4792 This corresponds to types that occupy as much
4793 storage as the default @code{CHARACTER} type,
4794 which is the same effective type as @code{CHARACTER(KIND=1)}
4795 (making that type effectively the same as @code{CHARACTER(KIND=3)}).
4797 (Typically, these are @code{INTEGER*1} and @code{LOGICAL*1}.)
4799 @var{n} of 6 thus corresponds to types that occupy twice as
4800 much storage as the @var{n}=3 types, @var{n} of 12 to types
4801 that occupy four times as much storage, and so on.
4803 These are not necessarily supported by every GNU Fortran
4807 This corresponds to types that occupy half the
4808 storage as the default (@var{n}=1) types.
4810 (Typically, these are @code{INTEGER*2} and @code{LOGICAL*2}.)
4812 @var{n} of 25 thus corresponds to types that occupy one-quarter
4813 as much storage as the default types.
4815 These are not necessarily supported by every GNU Fortran
4820 This is valid only as @code{INTEGER(KIND=7)} and
4821 denotes the @code{INTEGER} type that has the smallest
4822 storage size that holds a pointer on the system.
4824 A pointer representable by this type is capable of uniquely
4825 addressing a @code{CHARACTER*1} variable, array, array element,
4828 (Typically this is equivalent to @code{INTEGER*4} or,
4829 on 64-bit systems, @code{INTEGER*8}.
4830 In a compatible C implementation, it typically would
4831 be the same size and semantics of the C type @code{void *}.)
4834 Note that these are @emph{proposed} correspondences and might change
4835 in future versions of @code{g77}---avoid writing code depending
4836 on them while @code{g77}, and therefore the GNU Fortran language
4837 it defines, is in beta testing.
4839 Values not specified in the above list are reserved to
4840 future versions of the GNU Fortran language.
4842 Implementation-dependent meanings will be assigned new,
4843 unique prime numbers so as to not interfere with other
4844 implementation-dependent meanings, and offer the possibility
4845 of increasing the portability of code depending on such
4846 types by offering support for them in other GNU Fortran
4849 Other meanings that might be given unique values are:
4853 Types that make use of only half their storage size for
4854 representing precision and range.
4856 For example, some compilers offer options that cause
4857 @code{INTEGER} types to occupy the amount of storage
4858 that would be needed for @code{INTEGER(KIND=2)} types, but the
4859 range remains that of @code{INTEGER(KIND=1)}.
4862 The IEEE single floating-point type.
4865 Types with a specific bit pattern (endianness), such as the
4866 little-endian form of @code{INTEGER(KIND=1)}.
4867 These could permit, conceptually, use of portable code and
4868 implementations on data files written by existing systems.
4871 Future @emph{prime} numbers should be given meanings in as incremental
4872 a fashion as possible, to allow for flexibility and
4873 expressiveness in combining types.
4875 For example, instead of defining a prime number for little-endian
4876 IEEE doubles, one prime number might be assigned the meaning
4877 ``little-endian'', another the meaning ``IEEE double'', and the
4878 value of @var{n} for a little-endian IEEE double would thus
4879 naturally be the product of those two respective assigned values.
4880 (It could even be reasonable to have IEEE values result from the
4881 products of prime values denoting exponent and fraction sizes
4882 and meanings, hidden bit usage, availability and representations
4883 of special values such as subnormals, infinities, and Not-A-Numbers
4886 This assignment mechanism, while not inherently required for
4887 future versions of the GNU Fortran language, is worth using
4888 because it could ease management of the ``space'' of supported
4889 types much easier in the long run.
4891 The above approach suggests a mechanism for specifying inheritance
4892 of intrinsic (built-in) types for an entire, widely portable
4894 It is certainly reasonable that, unlike programmers of other languages
4895 offering inheritance mechanisms that employ verbose names for classes
4896 and subclasses, along with graphical browsers to elucidate the
4897 relationships, Fortran programmers would employ
4898 a mechanism that works by multiplying prime numbers together
4899 and finding the prime factors of such products.
4901 Most of the advantages for the above scheme have been explained
4903 One disadvantage is that it could lead to the defining,
4904 by the GNU Fortran language, of some fairly large prime numbers.
4905 This could lead to the GNU Fortran language being declared
4906 ``munitions'' by the United States Department of Defense.
4909 @subsection Constants
4911 @cindex types, constants
4913 (Corresponds to Section 4.2 of ANSI X3.9-1978 FORTRAN 77.)
4915 A @dfn{typeless constant} has one of the following forms:
4918 '@var{binary-digits}'B
4919 '@var{octal-digits}'O
4920 '@var{hexadecimal-digits}'Z
4921 '@var{hexadecimal-digits}'X
4925 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
4926 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
4927 and @samp{0123456789ABCDEFabcdef}, respectively.
4928 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
4931 A prefix-radix constant, such as @samp{Z'ABCD'}, can optionally be
4932 treated as typeless. @xref{Fortran Dialect Options,, Options
4933 Controlling Fortran Dialect}, for information on the
4934 @samp{-ftypeless-boz} option.
4936 Typeless constants have values that depend on the context in which
4939 All other constants, called @dfn{typed constants}, are interpreted---converted
4940 to internal form---according to their inherent type.
4941 Thus, context is @emph{never} a determining factor for the type, and hence
4942 the interpretation, of a typed constant.
4943 (All constants in the ANSI FORTRAN 77 language are typed constants.)
4945 For example, @samp{1} is always type @code{INTEGER(KIND=1)} in GNU
4946 Fortran (called default INTEGER in Fortran 90),
4947 @samp{9.435784839284958} is always type @code{REAL(KIND=1)} (even if the
4948 additional precision specified is lost, and even when used in a
4949 @code{REAL(KIND=2)} context), @samp{1E0} is always type @code{REAL(KIND=2)},
4950 and @samp{1D0} is always type @code{REAL(KIND=2)}.
4953 @subsection Integer Type
4955 (Corresponds to Section 4.3 of ANSI X3.9-1978 FORTRAN 77.)
4957 An integer constant also may have one of the following forms:
4960 B'@var{binary-digits}'
4961 O'@var{octal-digits}'
4962 Z'@var{hexadecimal-digits}'
4963 X'@var{hexadecimal-digits}'
4967 @var{binary-digits}, @var{octal-digits}, and @var{hexadecimal-digits}
4968 are nonempty strings of characters in the set @samp{01}, @samp{01234567},
4969 and @samp{0123456789ABCDEFabcdef}, respectively.
4970 (The value for @samp{A} (and @samp{a}) is 10, for @samp{B} and @samp{b}
4973 @node Character Type
4974 @subsection Character Type
4976 (Corresponds to Section 4.8 of ANSI X3.9-1978 FORTRAN 77.)
4978 @cindex double quoted character constants
4979 A character constant may be delimited by a pair of double quotes
4980 (@samp{"}) instead of apostrophes.
4981 In this case, an apostrophe within the constant represents
4982 a single apostrophe, while a double quote is represented in
4983 the source text of the constant by two consecutive double
4984 quotes with no intervening spaces.
4986 @cindex zero-length CHARACTER
4987 @cindex null CHARACTER strings
4988 @cindex empty CHARACTER strings
4989 @cindex strings, empty
4990 @cindex CHARACTER, null
4991 A character constant may be empty (have a length of zero).
4993 A character constant may include a substring specification,
4994 The value of such a constant is the value of the substring---for
4995 example, the value of @samp{'hello'(3:5)} is the same
4996 as the value of @samp{'llo'}.
4999 @section Expressions
5001 (The following information augments or overrides the information in
5002 Chapter 6 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5004 Chapter 6 of that document otherwise serves as the basis
5005 for the relevant aspects of GNU Fortran.)
5012 @subsection The @code{%LOC()} Construct
5013 @cindex %LOC() construct
5019 The @code{%LOC()} construct is an expression
5020 that yields the value of the location of its argument,
5021 @var{arg}, in memory.
5022 The size of the type of the expression depends on the system---typically,
5023 it is equivalent to either @code{INTEGER(KIND=1)} or @code{INTEGER(KIND=2)},
5024 though it is actually type @code{INTEGER(KIND=7)}.
5026 The argument to @code{%LOC()} must be suitable as the
5027 left-hand side of an assignment statement.
5028 That is, it may not be a general expression involving
5029 operators such as addition, subtraction, and so on,
5030 nor may it be a constant.
5032 Use of @code{%LOC()} is recommended only for code that
5033 is accessing facilities outside of GNU Fortran, such as
5034 operating system or windowing facilities.
5035 It is best to constrain such uses to isolated portions of
5036 a program---portions that deal specifically and exclusively
5037 with low-level, system-dependent facilities.
5038 Such portions might well provide a portable interface for
5039 use by the program as a whole, but are themselves not
5040 portable, and should be thoroughly tested each time they
5041 are rebuilt using a new compiler or version of a compiler.
5043 Do not depend on @code{%LOC()} returning a pointer that
5044 can be safely used to @emph{define} (change) the argument.
5045 While this might work in some circumstances, it is hard
5046 to predict whether it will continue to work when a program
5047 (that works using this unsafe behavior)
5048 is recompiled using different command-line options or
5049 a different version of @code{g77}.
5051 Generally, @code{%LOC()} is safe when used as an argument
5052 to a procedure that makes use of the value of the corresponding
5053 dummy argument only during its activation, and only when
5054 such use is restricted to referencing (reading) the value
5055 of the argument to @code{%LOC()}.
5057 @emph{Implementation Note:} Currently, @code{g77} passes
5058 arguments (those not passed using a construct such as @code{%VAL()})
5059 by reference or descriptor, depending on the type of
5060 the actual argument.
5061 Thus, given @samp{INTEGER I}, @samp{CALL FOO(I)} would
5062 seem to mean the same thing as @samp{CALL FOO(%VAL(%LOC(I)))}, and
5063 in fact might compile to identical code.
5065 However, @samp{CALL FOO(%VAL(%LOC(I)))} emphatically means
5066 ``pass, by value, the address of @samp{I} in memory''.
5067 While @samp{CALL FOO(I)} might use that same approach in a
5068 particular version of @code{g77}, another version or compiler
5069 might choose a different implementation, such as copy-in/copy-out,
5070 to effect the desired behavior---and which will therefore not
5071 necessarily compile to the same code as would
5072 @samp{CALL FOO(%VAL(%LOC(I)))}
5073 using the same version or compiler.
5075 @xref{Debugging and Interfacing}, for detailed information on
5076 how this particular version of @code{g77} implements various
5079 @node Specification Statements
5080 @section Specification Statements
5082 (The following information augments or overrides the information in
5083 Chapter 8 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5085 Chapter 8 of that document otherwise serves as the basis
5086 for the relevant aspects of GNU Fortran.)
5094 @subsection @code{NAMELIST} Statement
5095 @cindex NAMELIST statement
5096 @cindex statements, NAMELIST
5098 The @code{NAMELIST} statement, and related I/O constructs, are
5099 supported by the GNU Fortran language in essentially the same
5100 way as they are by @code{f2c}.
5102 This follows Fortran 90 with the restriction that on @code{NAMELIST}
5103 input, subscripts must have the form
5105 @var{subscript} [ @code{:} @var{subscript} [ @code{:} @var{stride}]]
5109 &xx x(1:3,8:10:2)=1,2,3,4,5,6/
5111 is allowed, but not, say,
5113 &xx x(:3,8::2)=1,2,3,4,5,6/
5116 As an extension of the Fortran 90 form, @code{$} and @code{$END} may be
5117 used in place of @code{&} and @code{/} in @code{NAMELIST} input, so that
5119 $&xx x(1:3,8:10:2)=1,2,3,4,5,6 $end
5121 could be used instead of the example above.
5123 @node DOUBLE COMPLEX
5124 @subsection @code{DOUBLE COMPLEX} Statement
5125 @cindex DOUBLE COMPLEX
5127 @code{DOUBLE COMPLEX} is a type-statement (and type) that
5128 specifies the type @code{COMPLEX(KIND=2)} in GNU Fortran.
5130 @node Control Statements
5131 @section Control Statements
5133 (The following information augments or overrides the information in
5134 Chapter 11 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5136 Chapter 11 of that document otherwise serves as the basis
5137 for the relevant aspects of GNU Fortran.)
5147 @subsection DO WHILE
5150 @cindex MIL-STD 1753
5152 The @code{DO WHILE} statement, a feature of both the MIL-STD 1753 and
5153 Fortran 90 standards, is provided by the GNU Fortran language.
5154 The Fortran 90 ``do forever'' statement comprising just @code{DO} is
5160 @cindex MIL-STD 1753
5162 The @code{END DO} statement is provided by the GNU Fortran language.
5164 This statement is used in one of two ways:
5168 The Fortran 90 meaning, in which it specifies the termination
5169 point of a single @code{DO} loop started with a @code{DO} statement
5170 that specifies no termination label.
5173 The MIL-STD 1753 meaning, in which it specifies the termination
5174 point of one or more @code{DO} loops, all of which start with a
5175 @code{DO} statement that specify the label defined for the
5176 @code{END DO} statement.
5178 This kind of @code{END DO} statement is merely a synonym for
5179 @code{CONTINUE}, except it is permitted only when the statement
5180 is labeled and a target of one or more labeled @code{DO} loops.
5182 It is expected that this use of @code{END DO} will be removed from
5183 the GNU Fortran language in the future, though it is likely that
5184 it will long be supported by @code{g77} as a dialect form.
5187 @node Construct Names
5188 @subsection Construct Names
5189 @cindex construct names
5191 The GNU Fortran language supports construct names as defined
5192 by the Fortran 90 standard.
5193 These names are local to the program unit and are defined
5197 @var{construct-name}: @var{block-statement}
5201 Here, @var{construct-name} is the construct name itself;
5202 its definition is connoted by the single colon (@samp{:}); and
5203 @var{block-statement} is an @code{IF}, @code{DO},
5204 or @code{SELECT CASE} statement that begins a block.
5206 A block that is given a construct name must also specify the
5207 same construct name in its termination statement:
5210 END @var{block} @var{construct-name}
5214 Here, @var{block} must be @code{IF}, @code{DO}, or @code{SELECT},
5217 @node CYCLE and EXIT
5218 @subsection The @code{CYCLE} and @code{EXIT} Statements
5220 @cindex CYCLE statement
5221 @cindex EXIT statement
5222 @cindex statements, CYCLE
5223 @cindex statements, EXIT
5224 The @code{CYCLE} and @code{EXIT} statements specify that
5225 the remaining statements in the current iteration of a
5226 particular active (enclosing) @code{DO} loop are to be skipped.
5228 @code{CYCLE} specifies that these statements are skipped,
5229 but the @code{END DO} statement that marks the end of the
5230 @code{DO} loop be executed---that is, the next iteration,
5231 if any, is to be started.
5232 If the statement marking the end of the @code{DO} loop is
5233 not @code{END DO}---in other words, if the loop is not
5234 a block @code{DO}---the @code{CYCLE} statement does not
5235 execute that statement, but does start the next iteration (if any).
5237 @code{EXIT} specifies that the loop specified by the
5238 @code{DO} construct is terminated.
5240 The @code{DO} loop affected by @code{CYCLE} and @code{EXIT}
5241 is the innermost enclosing @code{DO} loop when the following
5249 Otherwise, the following forms specify the construct name
5250 of the pertinent @code{DO} loop:
5253 CYCLE @var{construct-name}
5254 EXIT @var{construct-name}
5257 @code{CYCLE} and @code{EXIT} can be viewed as glorified @code{GO TO}
5259 However, they cannot be easily thought of as @code{GO TO} statements
5260 in obscure cases involving FORTRAN 77 loops.
5269 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5274 In particular, neither the @code{EXIT} nor @code{CYCLE} statements
5275 above are equivalent to a @code{GO TO} statement to either label
5276 @samp{10} or @samp{20}.
5278 To understand the effect of @code{CYCLE} and @code{EXIT} in the
5279 above fragment, it is helpful to first translate it to its equivalent
5280 using only block @code{DO} loops:
5288 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5295 Adding new labels allows translation of @code{CYCLE} and @code{EXIT}
5296 to @code{GO TO} so they may be more easily understood by programmers
5297 accustomed to FORTRAN coding:
5302 IF (J .EQ. 5) GOTO 18
5304 IF (K .EQ. 3) GO TO 12
5305 10 PRINT *, 'I=', I, ' J=', J, ' K=', K
5313 Thus, the @code{CYCLE} statement in the innermost loop skips over
5314 the @code{PRINT} statement as it begins the next iteration of the
5315 loop, while the @code{EXIT} statement in the middle loop ends that
5316 loop but @emph{not} the outermost loop.
5318 @node Functions and Subroutines
5319 @section Functions and Subroutines
5321 (The following information augments or overrides the information in
5322 Chapter 15 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5324 Chapter 15 of that document otherwise serves as the basis
5325 for the relevant aspects of GNU Fortran.)
5331 * Generics and Specifics::
5332 * REAL() and AIMAG() of Complex::
5333 * CMPLX() of DOUBLE PRECISION::
5335 * f77/f2c Intrinsics::
5336 * Table of Intrinsic Functions::
5340 @subsection The @code{%VAL()} Construct
5341 @cindex %VAL() construct
5347 The @code{%VAL()} construct specifies that an argument,
5348 @var{arg}, is to be passed by value, instead of by reference
5351 @code{%VAL()} is restricted to actual arguments in
5352 invocations of external procedures.
5354 Use of @code{%VAL()} is recommended only for code that
5355 is accessing facilities outside of GNU Fortran, such as
5356 operating system or windowing facilities.
5357 It is best to constrain such uses to isolated portions of
5358 a program---portions the deal specifically and exclusively
5359 with low-level, system-dependent facilities.
5360 Such portions might well provide a portable interface for
5361 use by the program as a whole, but are themselves not
5362 portable, and should be thoroughly tested each time they
5363 are rebuilt using a new compiler or version of a compiler.
5365 @emph{Implementation Note:} Currently, @code{g77} passes
5366 all arguments either by reference or by descriptor.
5368 Thus, use of @code{%VAL()} tends to be restricted to cases
5369 where the called procedure is written in a language other
5370 than Fortran that supports call-by-value semantics.
5371 (C is an example of such a language.)
5373 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)},
5374 for detailed information on
5375 how this particular version of @code{g77} passes arguments
5379 @subsection The @code{%REF()} Construct
5380 @cindex %REF() construct
5386 The @code{%REF()} construct specifies that an argument,
5387 @var{arg}, is to be passed by reference, instead of by
5388 value or descriptor.
5390 @code{%REF()} is restricted to actual arguments in
5391 invocations of external procedures.
5393 Use of @code{%REF()} is recommended only for code that
5394 is accessing facilities outside of GNU Fortran, such as
5395 operating system or windowing facilities.
5396 It is best to constrain such uses to isolated portions of
5397 a program---portions the deal specifically and exclusively
5398 with low-level, system-dependent facilities.
5399 Such portions might well provide a portable interface for
5400 use by the program as a whole, but are themselves not
5401 portable, and should be thoroughly tested each time they
5402 are rebuilt using a new compiler or version of a compiler.
5404 Do not depend on @code{%REF()} supplying a pointer to the
5405 procedure being invoked.
5406 While that is a likely implementation choice, other
5407 implementation choices are available that preserve Fortran
5408 pass-by-reference semantics without passing a pointer to
5409 the argument, @var{arg}.
5410 (For example, a copy-in/copy-out implementation.)
5412 @emph{Implementation Note:} Currently, @code{g77} passes
5414 (other than variables and arrays of type @code{CHARACTER})
5416 Future versions of, or dialects supported by, @code{g77} might
5417 not pass @code{CHARACTER} functions by reference.
5419 Thus, use of @code{%REF()} tends to be restricted to cases
5420 where @var{arg} is type @code{CHARACTER} but the called
5421 procedure accesses it via a means other than the method
5422 used for Fortran @code{CHARACTER} arguments.
5424 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5425 how this particular version of @code{g77} passes arguments
5429 @subsection The @code{%DESCR()} Construct
5430 @cindex %DESCR() construct
5436 The @code{%DESCR()} construct specifies that an argument,
5437 @var{arg}, is to be passed by descriptor, instead of by
5440 @code{%DESCR()} is restricted to actual arguments in
5441 invocations of external procedures.
5443 Use of @code{%DESCR()} is recommended only for code that
5444 is accessing facilities outside of GNU Fortran, such as
5445 operating system or windowing facilities.
5446 It is best to constrain such uses to isolated portions of
5447 a program---portions the deal specifically and exclusively
5448 with low-level, system-dependent facilities.
5449 Such portions might well provide a portable interface for
5450 use by the program as a whole, but are themselves not
5451 portable, and should be thoroughly tested each time they
5452 are rebuilt using a new compiler or version of a compiler.
5454 Do not depend on @code{%DESCR()} supplying a pointer
5455 and/or a length passed by value
5456 to the procedure being invoked.
5457 While that is a likely implementation choice, other
5458 implementation choices are available that preserve the
5459 pass-by-reference semantics without passing a pointer to
5460 the argument, @var{arg}.
5461 (For example, a copy-in/copy-out implementation.)
5462 And, future versions of @code{g77} might change the
5463 way descriptors are implemented, such as passing a
5464 single argument pointing to a record containing the
5465 pointer/length information instead of passing that same
5466 information via two arguments as it currently does.
5468 @emph{Implementation Note:} Currently, @code{g77} passes
5469 all variables and arrays of type @code{CHARACTER}
5471 Future versions of, or dialects supported by, @code{g77} might
5472 pass @code{CHARACTER} functions by descriptor as well.
5474 Thus, use of @code{%DESCR()} tends to be restricted to cases
5475 where @var{arg} is not type @code{CHARACTER} but the called
5476 procedure accesses it via a means similar to the method
5477 used for Fortran @code{CHARACTER} arguments.
5479 @xref{Procedures,,Procedures (SUBROUTINE and FUNCTION)}, for detailed information on
5480 how this particular version of @code{g77} passes arguments
5483 @node Generics and Specifics
5484 @subsection Generics and Specifics
5485 @cindex generic intrinsics
5486 @cindex intrinsics, generic
5488 The ANSI FORTRAN 77 language defines generic and specific
5490 In short, the distinctions are:
5494 @emph{Specific} intrinsics have
5495 specific types for their arguments and a specific return
5499 @emph{Generic} intrinsics are treated,
5500 on a case-by-case basis in the program's source code,
5501 as one of several possible specific intrinsics.
5503 Typically, a generic intrinsic has a return type that
5504 is determined by the type of one or more of its arguments.
5507 The GNU Fortran language generalizes these concepts somewhat,
5508 especially by providing intrinsic subroutines and generic
5509 intrinsics that are treated as either a specific intrinsic subroutine
5510 or a specific intrinsic function (e.g. @code{SECOND}).
5512 However, GNU Fortran avoids generalizing this concept to
5513 the point where existing code would be accepted as meaning
5514 something possibly different than what was intended.
5516 For example, @code{ABS} is a generic intrinsic, so all working
5517 code written using @code{ABS} of an @code{INTEGER} argument
5518 expects an @code{INTEGER} return value.
5519 Similarly, all such code expects that @code{ABS} of an @code{INTEGER*2}
5520 argument returns an @code{INTEGER*2} return value.
5522 Yet, @code{IABS} is a @emph{specific} intrinsic that accepts only
5523 an @code{INTEGER(KIND=1)} argument.
5524 Code that passes something other than an @code{INTEGER(KIND=1)}
5525 argument to @code{IABS} is not valid GNU Fortran code, because
5526 it is not clear what the author intended.
5528 For example, if @samp{J} is @code{INTEGER(KIND=6)}, @samp{IABS(J)}
5529 is not defined by the GNU Fortran language, because the programmer
5530 might have used that construct to mean any of the following, subtly
5535 Convert @samp{J} to @code{INTEGER(KIND=1)} first
5536 (as if @samp{IABS(INT(J))} had been written).
5539 Convert the result of the intrinsic to @code{INTEGER(KIND=1)}
5540 (as if @samp{INT(ABS(J))} had been written).
5543 No conversion (as if @samp{ABS(J)} had been written).
5546 The distinctions matter especially when types and values wider than
5547 @code{INTEGER(KIND=1)} (such as @code{INTEGER(KIND=2)}), or when
5548 operations performing more ``arithmetic'' than absolute-value, are involved.
5550 The following sample program is not a valid GNU Fortran program, but
5551 might be accepted by other compilers.
5552 If so, the output is likely to be revealing in terms of how a given
5553 compiler treats intrinsics (that normally are specific) when they
5554 are given arguments that do not conform to their stated requirements:
5556 @cindex JCB002 program
5560 C Modified 1999-02-15 (Burley) to delete my email address.
5561 C Modified 1997-05-21 (Burley) to accommodate compilers that implement
5562 C INT(I1-I2) as INT(I1)-INT(I2) given INTEGER*2 I1,I2.
5565 C Written by James Craig Burley 1997-02-20.
5568 C Determine how compilers handle non-standard IDIM
5569 C on INTEGER*2 operands, which presumably can be
5570 C extrapolated into understanding how the compiler
5571 C generally treats specific intrinsics that are passed
5572 C arguments not of the correct types.
5574 C If your compiler implements INTEGER*2 and INTEGER
5575 C as the same type, change all INTEGER*2 below to
5580 INTEGER*2 ISMALL, ILARGE
5581 INTEGER*2 ITOOLG, ITWO
5585 C Find smallest INTEGER*2 number.
5589 IF ((I0 .GE. ISMALL) .OR. (I0+1 .NE. ISMALL)) GOTO 20
5594 C Find largest INTEGER*2 number.
5598 IF ((I0 .LE. ILARGE) .OR. (I0-1 .NE. ILARGE)) GOTO 40
5603 C Multiplying by two adds stress to the situation.
5607 C Need a number that, added to -2, is too wide to fit in I*2.
5611 C Use IDIM the straightforward way.
5613 I1 = IDIM (ILARGE, ISMALL) * ITWO + ITOOLG
5615 C Calculate result for first interpretation.
5617 I2 = (INT (ILARGE) - INT (ISMALL)) * ITWO + ITOOLG
5619 C Calculate result for second interpretation.
5621 ITMP = ILARGE - ISMALL
5622 I3 = (INT (ITMP)) * ITWO + ITOOLG
5624 C Calculate result for third interpretation.
5626 I4 = (ILARGE - ISMALL) * ITWO + ITOOLG
5630 PRINT *, 'ILARGE=', ILARGE
5631 PRINT *, 'ITWO=', ITWO
5632 PRINT *, 'ITOOLG=', ITOOLG
5633 PRINT *, 'ISMALL=', ISMALL
5642 IF (L2 .AND. .NOT.L3 .AND. .NOT.L4) THEN
5643 PRINT *, 'Interp 1: IDIM(I*2,I*2) => IDIM(INT(I*2),INT(I*2))'
5646 IF (L3 .AND. .NOT.L2 .AND. .NOT.L4) THEN
5647 PRINT *, 'Interp 2: IDIM(I*2,I*2) => INT(DIM(I*2,I*2))'
5650 IF (L4 .AND. .NOT.L2 .AND. .NOT.L3) THEN
5651 PRINT *, 'Interp 3: IDIM(I*2,I*2) => DIM(I*2,I*2)'
5654 PRINT *, 'Results need careful analysis.'
5658 No future version of the GNU Fortran language
5659 will likely permit specific intrinsic invocations with wrong-typed
5660 arguments (such as @code{IDIM} in the above example), since
5661 it has been determined that disagreements exist among
5662 many production compilers on the interpretation of
5664 These disagreements strongly suggest that Fortran programmers,
5665 and certainly existing Fortran programs, disagree about the
5666 meaning of such invocations.
5668 The first version of @samp{JCB002} didn't accommodate some compilers'
5669 treatment of @samp{INT(I1-I2)} where @samp{I1} and @samp{I2} are
5671 In such a case, these compilers apparently convert both
5672 operands to @code{INTEGER*4} and then do an @code{INTEGER*4} subtraction,
5673 instead of doing an @code{INTEGER*2} subtraction on the
5674 original values in @samp{I1} and @samp{I2}.
5676 However, the results of the careful analyses done on the outputs
5677 of programs compiled by these various compilers show that they
5678 all implement either @samp{Interp 1} or @samp{Interp 2} above.
5680 Specifically, it is believed that the new version of @samp{JCB002}
5681 above will confirm that:
5685 Digital Semiconductor (``DEC'') Alpha OSF/1, HP-UX 10.0.1, AIX 3.2.5
5686 @code{f77} compilers all implement @samp{Interp 1}.
5689 IRIX 5.3 @code{f77} compiler implements @samp{Interp 2}.
5692 Solaris 2.5, SunOS 4.1.3, DECstation ULTRIX 4.3,
5693 and IRIX 6.1 @code{f77} compilers all implement @samp{Interp 3}.
5696 If you get different results than the above for the stated
5697 compilers, or have results for other compilers that might be
5698 worth adding to the above list, please let us know the details
5699 (compiler product, version, machine, results, and so on).
5701 @node REAL() and AIMAG() of Complex
5702 @subsection @code{REAL()} and @code{AIMAG()} of Complex
5703 @cindex @code{Real} intrinsic
5704 @cindex intrinsics, @code{Real}
5705 @cindex @code{AImag} intrinsic
5706 @cindex intrinsics, @code{AImag}
5708 The GNU Fortran language disallows @code{REAL(@var{expr})}
5709 and @code{AIMAG(@var{expr})},
5710 where @var{expr} is any @code{COMPLEX} type other than @code{COMPLEX(KIND=1)},
5711 except when they are used in the following way:
5714 REAL(REAL(@var{expr}))
5715 REAL(AIMAG(@var{expr}))
5719 The above forms explicitly specify that the desired effect
5720 is to convert the real or imaginary part of @var{expr}, which might
5721 be some @code{REAL} type other than @code{REAL(KIND=1)},
5722 to type @code{REAL(KIND=1)},
5723 and have that serve as the value of the expression.
5725 The GNU Fortran language offers clearly named intrinsics to extract the
5726 real and imaginary parts of a complex entity without any
5730 REALPART(@var{expr})
5731 IMAGPART(@var{expr})
5734 To express the above using typical extended FORTRAN 77,
5735 use the following constructs
5736 (when @var{expr} is @code{COMPLEX(KIND=2)}):
5743 The FORTRAN 77 language offers no way
5744 to explicitly specify the real and imaginary parts of a complex expression of
5745 arbitrary type, apparently as a result of requiring support for
5746 only one @code{COMPLEX} type (@code{COMPLEX(KIND=1)}).
5747 The concepts of converting an expression to type @code{REAL(KIND=1)} and
5748 of extracting the real part of a complex expression were
5749 thus ``smooshed'' by FORTRAN 77 into a single intrinsic, since
5750 they happened to have the exact same effect in that language
5751 (due to having only one @code{COMPLEX} type).
5753 @emph{Note:} When @samp{-ff90} is in effect,
5754 @code{g77} treats @samp{REAL(@var{expr})}, where @var{expr} is of
5755 type @code{COMPLEX}, as @samp{REALPART(@var{expr})},
5756 whereas with @samp{-fugly-complex -fno-f90} in effect, it is
5757 treated as @samp{REAL(REALPART(@var{expr}))}.
5759 @xref{Ugly Complex Part Extraction}, for more information.
5761 @node CMPLX() of DOUBLE PRECISION
5762 @subsection @code{CMPLX()} of @code{DOUBLE PRECISION}
5763 @cindex @code{Cmplx} intrinsic
5764 @cindex intrinsics, @code{Cmplx}
5766 In accordance with Fortran 90 and at least some (perhaps all)
5767 other compilers, the GNU Fortran language defines @code{CMPLX()}
5768 as always returning a result that is type @code{COMPLEX(KIND=1)}.
5770 This means @samp{CMPLX(D1,D2)}, where @samp{D1} and @samp{D2}
5771 are @code{REAL(KIND=2)} (@code{DOUBLE PRECISION}), is treated as:
5774 CMPLX(SNGL(D1), SNGL(D2))
5777 (It was necessary for Fortran 90 to specify this behavior
5778 for @code{DOUBLE PRECISION} arguments, since that is
5779 the behavior mandated by FORTRAN 77.)
5781 The GNU Fortran language also provides the @code{DCMPLX()} intrinsic,
5782 which is provided by some FORTRAN 77 compilers to construct
5783 a @code{DOUBLE COMPLEX} entity from of @code{DOUBLE PRECISION}
5785 However, this solution does not scale well when more @code{COMPLEX} types
5786 (having various precisions and ranges) are offered by Fortran implementations.
5788 Fortran 90 extends the @code{CMPLX()} intrinsic by adding
5789 an extra argument used to specify the desired kind of complex
5791 However, this solution is somewhat awkward to use, and
5792 @code{g77} currently does not support it.
5794 The GNU Fortran language provides a simple way to build a complex
5795 value out of two numbers, with the precise type of the value
5796 determined by the types of the two numbers (via the usual
5797 type-promotion mechanism):
5800 COMPLEX(@var{real}, @var{imag})
5803 When @var{real} and @var{imag} are the same @code{REAL} types, @code{COMPLEX()}
5804 performs no conversion other than to put them together to form a
5805 complex result of the same (complex version of real) type.
5807 @xref{Complex Intrinsic}, for more information.
5810 @subsection MIL-STD 1753 Support
5811 @cindex MIL-STD 1753
5813 The GNU Fortran language includes the MIL-STD 1753 intrinsics
5814 @code{BTEST}, @code{IAND}, @code{IBCLR}, @code{IBITS},
5815 @code{IBSET}, @code{IEOR}, @code{IOR}, @code{ISHFT},
5816 @code{ISHFTC}, @code{MVBITS}, and @code{NOT}.
5818 @node f77/f2c Intrinsics
5819 @subsection @code{f77}/@code{f2c} Intrinsics
5821 The bit-manipulation intrinsics supported by traditional
5822 @code{f77} and by @code{f2c} are available in the GNU Fortran language.
5823 These include @code{AND}, @code{LSHIFT}, @code{OR}, @code{RSHIFT},
5826 Also supported are the intrinsics @code{CDABS},
5827 @code{CDCOS}, @code{CDEXP}, @code{CDLOG}, @code{CDSIN},
5828 @code{CDSQRT}, @code{DCMPLX}, @code{DCONJG}, @code{DFLOAT},
5829 @code{DIMAG}, @code{DREAL}, and @code{IMAG},
5830 @code{ZABS}, @code{ZCOS}, @code{ZEXP}, @code{ZLOG}, @code{ZSIN},
5833 @node Table of Intrinsic Functions
5834 @subsection Table of Intrinsic Functions
5835 @cindex intrinsics, table of
5836 @cindex table of intrinsics
5838 (Corresponds to Section 15.10 of ANSI X3.9-1978 FORTRAN 77.)
5840 The GNU Fortran language adds various functions, subroutines, types,
5841 and arguments to the set of intrinsic functions in ANSI FORTRAN 77.
5842 The complete set of intrinsics supported by the GNU Fortran language
5845 Note that a name is not treated as that of an intrinsic if it is
5846 specified in an @code{EXTERNAL} statement in the same program unit;
5847 if a command-line option is used to disable the groups to which
5848 the intrinsic belongs; or if the intrinsic is not named in an
5849 @code{INTRINSIC} statement and a command-line option is used to
5850 hide the groups to which the intrinsic belongs.
5852 So, it is recommended that any reference in a program unit to
5853 an intrinsic procedure that is not a standard FORTRAN 77
5854 intrinsic be accompanied by an appropriate @code{INTRINSIC}
5855 statement in that program unit.
5856 This sort of defensive programming makes it more
5857 likely that an implementation will issue a diagnostic rather
5858 than generate incorrect code for such a reference.
5860 The terminology used below is based on that of the Fortran 90
5861 standard, so that the text may be more concise and accurate:
5865 @code{OPTIONAL} means the argument may be omitted.
5868 @samp{A-1, A-2, @dots{}, A-n} means more than one argument
5869 (generally named @samp{A}) may be specified.
5872 @samp{scalar} means the argument must not be an array (must
5873 be a variable or array element, or perhaps a constant if expressions
5877 @samp{DIMENSION(4)} means the argument must be an array having 4 elements.
5880 @code{INTENT(IN)} means the argument must be an expression
5881 (such as a constant or a variable that is defined upon invocation
5885 @code{INTENT(OUT)} means the argument must be definable by the
5886 invocation of the intrinsic (that is, must not be a constant nor
5887 an expression involving operators other than array reference and
5888 substring reference).
5891 @code{INTENT(INOUT)} means the argument must be defined prior to,
5892 and definable by, invocation of the intrinsic (a combination of
5893 the requirements of @code{INTENT(IN)} and @code{INTENT(OUT)}.
5896 @xref{Kind Notation}, for an explanation of @code{KIND}.
5900 (Note that the empty lines appearing in the menu below
5901 are not intentional---they result from a bug in the
5902 GNU @code{makeinfo} program@dots{}a program that, if it
5903 did not exist, would leave this document in far worse shape!)
5906 @c The actual documentation for intrinsics comes from
5907 @c intdoc.texi, which in turn is automatically generated
5908 @c from the internal g77 tables in intrin.def _and_ the
5909 @c largely hand-written text in intdoc.h. So, if you want
5910 @c to change or add to existing documentation on intrinsics,
5911 @c you probably want to edit intdoc.h.
5923 @include intdoc.texi
5925 @node Scope and Classes of Names
5926 @section Scope and Classes of Symbolic Names
5927 @cindex symbol names, scope and classes
5930 (The following information augments or overrides the information in
5931 Chapter 18 of ANSI X3.9-1978 FORTRAN 77 in specifying the GNU Fortran
5933 Chapter 18 of that document otherwise serves as the basis
5934 for the relevant aspects of GNU Fortran.)
5937 * Underscores in Symbol Names::
5940 @node Underscores in Symbol Names
5941 @subsection Underscores in Symbol Names
5944 Underscores (@samp{_}) are accepted in symbol names after the first
5945 character (which must be a letter).
5951 A dollar sign at the end of an output format specification suppresses
5952 the newline at the end of the output.
5954 @cindex <> edit descriptor
5955 @cindex edit descriptor, <>
5956 Edit descriptors in @code{FORMAT} statements may contain compile-time
5957 @code{INTEGER} constant expressions in angle brackets, such as
5959 10 FORMAT (I<WIDTH>)
5962 The @code{OPEN} specifier @code{NAME=} is equivalent to @code{FILE=}.
5964 These Fortran 90 features are supported:
5967 @cindex FORMAT descriptors
5968 @cindex Z edit descriptor
5969 @cindex edit descriptor, Z
5970 @cindex O edit descriptor
5971 @cindex edit descriptor, O
5972 The @code{O} and @code{Z} edit descriptors are supported for I/O of
5973 integers in octal and hexadecimal formats, respectively.
5975 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
5976 @code{STATUS='SCRATCH'} is supplied. The @code{STATUS='REPLACE'}
5977 specifier is supported.
5980 @node Fortran 90 Features
5981 @section Fortran 90 Features
5983 @cindex extensions, from Fortran 90
5985 For convenience this section collects a list (probably incomplete) of
5986 the Fortran 90 features supported by the GNU Fortran language, even if
5987 they are documented elsewhere.
5988 @c makeinfo 1.68 objects to the nested parens
5990 @xref{Characters Lines Sequence,,{Characters, Lines, and Execution Sequence}},
5993 @xref{Characters Lines Sequence},
5995 for information on additional fixed source form lexical issues.
5996 @cindex @samp{-ffree-form}
5997 Further, the free source form is supported through the
5998 @samp{-ffree-form} option.
5999 @cindex @samp{-ff90}
6000 Other Fortran 90 features can be turned on by the @samp{-ff90} option;
6001 see @ref{Fortran 90}.
6002 For information on the Fortran 90 intrinsics available,
6003 see @ref{Table of Intrinsic Functions}.
6006 @item Automatic arrays in procedures
6007 @item Character assignments
6008 @cindex character assignments
6009 In character assignments, the variable being assigned may occur on the
6010 right hand side of the assignment.
6011 @item Character strings
6012 @cindex double quoted character constants
6013 Strings may have zero length and substrings of character constants are
6014 permitted. Character constants may be enclosed in double quotes
6015 (@code{"}) as well as single quotes. @xref{Character Type}.
6016 @item Construct names
6017 (Symbolic tags on blocks.) @xref{Construct Names }.
6018 @item @code{CYCLE} and @code{EXIT}
6019 @xref{CYCLE and EXIT,,The @code{CYCLE} and @code{EXIT} Statements}.
6020 @item @code{DOUBLE COMPLEX}
6021 @xref{DOUBLE COMPLEX,,@code{DOUBLE COMPLEX} Statement
6023 @item @code{DO WHILE}
6025 @item @code{END} decoration
6030 @item @code{IMPLICIT NONE}
6031 @item @code{INCLUDE} statements
6033 @item List-directed and namelist I/O on internal files
6034 @item Binary, octal and hexadecimal constants
6035 These are supported more generally than required by Fortran 90.
6036 @xref{Integer Type}.
6037 @item @samp{O} and @samp{Z} edit descriptors
6038 @item @code{NAMELIST}
6040 @item @code{OPEN} specifiers
6041 @code{STATUS='REPLACE'} is supported.
6042 The @code{FILE=} specifier may be omitted in an @code{OPEN} statement if
6043 @code{STATUS='SCRATCH'} is supplied.
6044 @item @code{FORMAT} edit descriptors
6045 @cindex FORMAT descriptors
6046 @cindex Z edit descriptor
6047 @cindex edit descriptor, Z
6048 The @code{Z} edit descriptor is supported.
6049 @item Relational operators
6050 The operators @code{<}, @code{<=}, @code{==}, @code{/=}, @code{>} and
6051 @code{>=} may be used instead of @code{.LT.}, @code{.LE.}, @code{.EQ.},
6052 @code{.NE.}, @code{.GT.} and @code{.GE.} respectively.
6053 @item @code{SELECT CASE}
6054 Not fully implemented. @xref{SELECT CASE on CHARACTER Type,,
6055 @code{SELECT CASE} on @code{CHARACTER} Type}.
6056 @item Specification statements
6057 A limited subset of the Fortran 90 syntax and semantics for variable
6058 declarations is supported, including @code{KIND}. @xref{Kind Notation}.
6059 (@code{KIND} is of limited usefulness in the absence of the
6060 @code{KIND}-related intrinsics, since these intrinsics permit writing
6061 more widely portable code.) An example of supported @code{KIND} usage
6064 INTEGER (KIND=1) :: FOO=1, BAR=2
6065 CHARACTER (LEN=3) FOO
6067 @code{PARAMETER} and @code{DIMENSION} attributes aren't supported.
6070 @node Other Dialects
6071 @chapter Other Dialects
6073 GNU Fortran supports a variety of features that are not
6074 considered part of the GNU Fortran language itself, but
6075 are representative of various dialects of Fortran that
6076 @code{g77} supports in whole or in part.
6078 Any of the features listed below might be disallowed by
6079 @code{g77} unless some command-line option is specified.
6080 Currently, some of the features are accepted using the
6081 default invocation of @code{g77}, but that might change
6084 @emph{Note: This portion of the documentation definitely needs a lot
6088 * Source Form:: Details of fixed-form and free-form source.
6089 * Trailing Comment:: Use of @samp{/*} to start a comment.
6090 * Debug Line:: Use of @samp{D} in column 1.
6091 * Dollar Signs:: Use of @samp{$} in symbolic names.
6092 * Case Sensitivity:: Uppercase and lowercase in source files.
6093 * VXT Fortran:: @dots{}versus the GNU Fortran language.
6094 * Fortran 90:: @dots{}versus the GNU Fortran language.
6095 * Pedantic Compilation:: Enforcing the standard.
6096 * Distensions:: Misfeatures supported by GNU Fortran.
6100 @section Source Form
6101 @cindex source file format
6102 @cindex source format
6103 @cindex file, source
6105 @cindex code, source
6109 GNU Fortran accepts programs written in either fixed form or
6113 corresponds to ANSI FORTRAN 77 (plus popular extensions, such as
6114 allowing tabs) and Fortran 90's fixed form.
6116 Free form corresponds to
6117 Fortran 90's free form (though possibly not entirely up-to-date, and
6118 without complaining about some things that for which Fortran 90 requires
6119 diagnostics, such as the spaces in the constant in @samp{R = 3 . 1}).
6121 The way a Fortran compiler views source files depends entirely on the
6122 implementation choices made for the compiler, since those choices
6123 are explicitly left to the implementation by the published Fortran
6125 GNU Fortran currently tries to be somewhat like a few popular compilers
6126 (@code{f2c}, Digital (``DEC'') Fortran, and so on), though a cleaner default
6127 definition along with more
6128 flexibility offered by command-line options is likely to be offered
6131 This section describes how @code{g77} interprets source lines.
6134 * Carriage Returns:: Carriage returns ignored.
6135 * Tabs:: Tabs converted to spaces.
6136 * Short Lines:: Short lines padded with spaces (fixed-form only).
6137 * Long Lines:: Long lines truncated.
6138 * Ampersands:: Special Continuation Lines.
6141 @node Carriage Returns
6142 @subsection Carriage Returns
6143 @cindex carriage returns
6145 Carriage returns (@samp{\r}) in source lines are ignored.
6146 This is somewhat different from @code{f2c}, which seems to treat them as
6147 spaces outside character/Hollerith constants, and encodes them as @samp{\r}
6148 inside such constants.
6152 @cindex tab character
6153 @cindex horizontal tab
6155 A source line with a @key{TAB} character anywhere in it is treated as
6156 entirely significant---however long it is---instead of ending in
6157 column 72 (for fixed-form source) or 132 (for free-form source).
6158 This also is different from @code{f2c}, which encodes tabs as
6159 @samp{\t} (the ASCII @key{TAB} character) inside character
6160 and Hollerith constants, but nevertheless seems to treat the column
6161 position as if it had been affected by the canonical tab positioning.
6163 @code{g77} effectively
6164 translates tabs to the appropriate number of spaces (a la the default
6165 for the UNIX @code{expand} command) before doing any other processing, other
6166 than (currently) noting whether a tab was found on a line and using this
6167 information to decide how to interpret the length of the line and continued
6170 Note that this default behavior probably will change for version 0.6,
6171 when it will presumably be available via a command-line option.
6172 The default as of version 0.6 is planned to be a ``pure visual''
6173 model, where tabs are immediately
6174 converted to spaces and otherwise have no effect, so the way a typical
6175 user sees source lines produces a consistent result no matter how the
6176 spacing in those source lines is actually implemented via tabs, spaces,
6177 and trailing tabs/spaces before newline.
6178 Command-line options are likely to be added to specify whether all or
6179 just-tabbed lines are to be extended to 132 or full input-line length,
6180 and perhaps even an option will be added to specify the truncated-line
6181 behavior to which some Digital compilers default (and which affects
6182 the way continued character/Hollerith constants are interpreted).
6185 @subsection Short Lines
6186 @cindex short source lines
6187 @cindex space, padding with
6188 @cindex source lines, short
6189 @cindex lines, short
6191 Source lines shorter than the applicable fixed-form length are treated as
6192 if they were padded with spaces to that length.
6193 (None of this is relevant to source files written in free form.)
6196 continued character and Hollerith constants, and is a different
6197 interpretation than provided by some other popular compilers
6198 (although a bit more consistent with the traditional punched-card
6199 basis of Fortran and the way the Fortran standard expressed fixed
6202 @code{g77} might someday offer an option to warn about cases where differences
6203 might be seen as a result of this treatment, and perhaps an option to
6204 specify the alternate behavior as well.
6206 Note that this padding cannot apply to lines that are effectively of
6207 infinite length---such lines are specified using command-line options
6208 like @samp{-ffixed-line-length-none}, for example.
6211 @subsection Long Lines
6212 @cindex long source lines
6213 @cindex truncation, of long lines
6215 @cindex source lines, long
6217 Source lines longer than the applicable length are truncated to that
6219 Currently, @code{g77} does not warn if the truncated characters are
6220 not spaces, to accommodate existing code written for systems that
6221 treated truncated text as commentary (especially in columns 73 through 80).
6223 @xref{Fortran Dialect Options,,Options Controlling Fortran Dialect},
6224 for information on the @samp{-ffixed-line-length-@var{n}} option,
6225 which can be used to set the line length applicable to fixed-form
6229 @subsection Ampersand Continuation Line
6230 @cindex ampersand continuation line
6231 @cindex continuation line, ampersand
6233 A @samp{&} in column 1 of fixed-form source denotes an arbitrary-length
6234 continuation line, imitating the behavior of @code{f2c}.
6236 @node Trailing Comment
6237 @section Trailing Comment
6239 @cindex trailing comment
6241 @cindex characters, comment
6244 @cindex exclamation point
6245 @code{g77} supports use of @samp{/*} to start a trailing
6247 In the GNU Fortran language, @samp{!} is used for this purpose.
6249 @samp{/*} is not in the GNU Fortran language
6250 because the use of @samp{/*} in a program might
6251 suggest to some readers that a block, not trailing, comment is
6252 started (and thus ended by @samp{*/}, not end of line),
6253 since that is the meaning of @samp{/*} in C.
6255 Also, such readers might think they can use @samp{//} to start
6256 a trailing comment as an alternative to @samp{/*}, but
6257 @samp{//} already denotes concatenation, and such a ``comment''
6258 might actually result in a program that compiles without
6259 error (though it would likely behave incorrectly).
6264 @cindex comment line, debug
6266 Use of @samp{D} or @samp{d} as the first character (column 1) of
6267 a source line denotes a debug line.
6269 In turn, a debug line is treated as either a comment line
6270 or a normal line, depending on whether debug lines are enabled.
6272 When treated as a comment line, a line beginning with @samp{D} or
6273 @samp{d} is treated as if it the first character was @samp{C} or @samp{c}, respectively.
6274 When treated as a normal line, such a line is treated as if
6275 the first character was @key{SPC} (space).
6277 (Currently, @code{g77} provides no means for treating debug
6278 lines as normal lines.)
6281 @section Dollar Signs in Symbol Names
6285 Dollar signs (@samp{$}) are allowed in symbol names (after the first character)
6286 when the @samp{-fdollar-ok} option is specified.
6288 @node Case Sensitivity
6289 @section Case Sensitivity
6290 @cindex case sensitivity
6291 @cindex source file format
6292 @cindex code, source
6294 @cindex uppercase letters
6295 @cindex lowercase letters
6296 @cindex letters, uppercase
6297 @cindex letters, lowercase
6299 GNU Fortran offers the programmer way too much flexibility in deciding
6300 how source files are to be treated vis-a-vis uppercase and lowercase
6302 There are 66 useful settings that affect case sensitivity, plus 10
6303 settings that are nearly useless, with the remaining 116 settings
6304 being either redundant or useless.
6306 None of these settings have any effect on the contents of comments
6307 (the text after a @samp{c} or @samp{C} in Column 1, for example)
6308 or of character or Hollerith constants.
6309 Note that things like the @samp{E} in the statement
6310 @samp{CALL FOO(3.2E10)} and the @samp{TO} in @samp{ASSIGN 10 TO LAB}
6311 are considered built-in keywords, and so are affected by
6314 Low-level switches are identified in this section as follows:
6318 Source Case Conversion:
6322 Preserve (see Note 1)
6324 Convert to Upper Case
6326 Convert to Lower Case
6330 Built-in Keyword Matching:
6334 Match Any Case (per-character basis)
6336 Match Upper Case Only
6338 Match Lower Case Only
6340 Match InitialCaps Only (see tables for spellings)
6344 Built-in Intrinsic Matching:
6348 Match Any Case (per-character basis)
6350 Match Upper Case Only
6352 Match Lower Case Only
6354 Match InitialCaps Only (see tables for spellings)
6358 User-defined Symbol Possibilities (warnings only):
6362 Allow Any Case (per-character basis)
6364 Allow Upper Case Only
6366 Allow Lower Case Only
6368 Allow InitialCaps Only (see Note 2)
6372 Note 1: @code{g77} eventually will support @code{NAMELIST} in a manner that is
6373 consistent with these source switches---in the sense that input will be
6374 expected to meet the same requirements as source code in terms
6375 of matching symbol names and keywords (for the exponent letters).
6377 Currently, however, @code{NAMELIST} is supported by @code{libg2c},
6378 which uppercases @code{NAMELIST} input and symbol names for matching.
6379 This means not only that @code{NAMELIST} output currently shows symbol
6380 (and keyword) names in uppercase even if lower-case source
6381 conversion (option A2) is selected, but that @code{NAMELIST} cannot be
6382 adequately supported when source case preservation (option A0)
6385 If A0 is selected, a warning message will be
6386 output for each @code{NAMELIST} statement to this effect.
6388 of the program is undefined at run time if two or more symbol names
6389 appear in a given @code{NAMELIST} such that the names are identical
6390 when converted to upper case (e.g. @samp{NAMELIST /X/ VAR, Var, var}).
6391 For complete and total elegance, perhaps there should be a warning
6392 when option A2 is selected, since the output of NAMELIST is currently
6393 in uppercase but will someday be lowercase (when a @code{libg77} is written),
6394 but that seems to be overkill for a product in beta test.
6396 Note 2: Rules for InitialCaps names are:
6400 Must be a single uppercase letter, @strong{or}
6402 Must start with an uppercase letter and contain at least one
6406 So @samp{A}, @samp{Ab}, @samp{ABc}, @samp{AbC}, and @samp{Abc} are
6407 valid InitialCaps names, but @samp{AB}, @samp{A2}, and @samp{ABC} are
6409 Note that most, but not all, built-in names meet these
6410 requirements---the exceptions are some of the two-letter format
6411 specifiers, such as @samp{BN} and @samp{BZ}.
6413 Here are the names of the corresponding command-line options:
6416 A0: -fsource-case-preserve
6417 A1: -fsource-case-upper
6418 A2: -fsource-case-lower
6420 B0: -fmatch-case-any
6421 B1: -fmatch-case-upper
6422 B2: -fmatch-case-lower
6423 B3: -fmatch-case-initcap
6425 C0: -fintrin-case-any
6426 C1: -fintrin-case-upper
6427 C2: -fintrin-case-lower
6428 C3: -fintrin-case-initcap
6430 D0: -fsymbol-case-any
6431 D1: -fsymbol-case-upper
6432 D2: -fsymbol-case-lower
6433 D3: -fsymbol-case-initcap
6436 Useful combinations of the above settings, along with abbreviated
6437 option names that set some of these combinations all at once:
6440 1: A0-- B0--- C0--- D0--- -fcase-preserve
6441 2: A0-- B0--- C0--- D-1--
6442 3: A0-- B0--- C0--- D--2-
6443 4: A0-- B0--- C0--- D---3
6444 5: A0-- B0--- C-1-- D0---
6445 6: A0-- B0--- C-1-- D-1--
6446 7: A0-- B0--- C-1-- D--2-
6447 8: A0-- B0--- C-1-- D---3
6448 9: A0-- B0--- C--2- D0---
6449 10: A0-- B0--- C--2- D-1--
6450 11: A0-- B0--- C--2- D--2-
6451 12: A0-- B0--- C--2- D---3
6452 13: A0-- B0--- C---3 D0---
6453 14: A0-- B0--- C---3 D-1--
6454 15: A0-- B0--- C---3 D--2-
6455 16: A0-- B0--- C---3 D---3
6456 17: A0-- B-1-- C0--- D0---
6457 18: A0-- B-1-- C0--- D-1--
6458 19: A0-- B-1-- C0--- D--2-
6459 20: A0-- B-1-- C0--- D---3
6460 21: A0-- B-1-- C-1-- D0---
6461 22: A0-- B-1-- C-1-- D-1-- -fcase-strict-upper
6462 23: A0-- B-1-- C-1-- D--2-
6463 24: A0-- B-1-- C-1-- D---3
6464 25: A0-- B-1-- C--2- D0---
6465 26: A0-- B-1-- C--2- D-1--
6466 27: A0-- B-1-- C--2- D--2-
6467 28: A0-- B-1-- C--2- D---3
6468 29: A0-- B-1-- C---3 D0---
6469 30: A0-- B-1-- C---3 D-1--
6470 31: A0-- B-1-- C---3 D--2-
6471 32: A0-- B-1-- C---3 D---3
6472 33: A0-- B--2- C0--- D0---
6473 34: A0-- B--2- C0--- D-1--
6474 35: A0-- B--2- C0--- D--2-
6475 36: A0-- B--2- C0--- D---3
6476 37: A0-- B--2- C-1-- D0---
6477 38: A0-- B--2- C-1-- D-1--
6478 39: A0-- B--2- C-1-- D--2-
6479 40: A0-- B--2- C-1-- D---3
6480 41: A0-- B--2- C--2- D0---
6481 42: A0-- B--2- C--2- D-1--
6482 43: A0-- B--2- C--2- D--2- -fcase-strict-lower
6483 44: A0-- B--2- C--2- D---3
6484 45: A0-- B--2- C---3 D0---
6485 46: A0-- B--2- C---3 D-1--
6486 47: A0-- B--2- C---3 D--2-
6487 48: A0-- B--2- C---3 D---3
6488 49: A0-- B---3 C0--- D0---
6489 50: A0-- B---3 C0--- D-1--
6490 51: A0-- B---3 C0--- D--2-
6491 52: A0-- B---3 C0--- D---3
6492 53: A0-- B---3 C-1-- D0---
6493 54: A0-- B---3 C-1-- D-1--
6494 55: A0-- B---3 C-1-- D--2-
6495 56: A0-- B---3 C-1-- D---3
6496 57: A0-- B---3 C--2- D0---
6497 58: A0-- B---3 C--2- D-1--
6498 59: A0-- B---3 C--2- D--2-
6499 60: A0-- B---3 C--2- D---3
6500 61: A0-- B---3 C---3 D0---
6501 62: A0-- B---3 C---3 D-1--
6502 63: A0-- B---3 C---3 D--2-
6503 64: A0-- B---3 C---3 D---3 -fcase-initcap
6504 65: A-1- B01-- C01-- D01-- -fcase-upper
6505 66: A--2 B0-2- C0-2- D0-2- -fcase-lower
6508 Number 22 is the ``strict'' ANSI FORTRAN 77 model wherein all input
6509 (except comments, character constants, and Hollerith strings) must
6510 be entered in uppercase.
6511 Use @samp{-fcase-strict-upper} to specify this
6514 Number 43 is like Number 22 except all input must be lowercase. Use
6515 @samp{-fcase-strict-lower} to specify this combination.
6517 Number 65 is the ``classic'' ANSI FORTRAN 77 model as implemented on many
6518 non-UNIX machines whereby all the source is translated to uppercase.
6519 Use @samp{-fcase-upper} to specify this combination.
6521 Number 66 is the ``canonical'' UNIX model whereby all the source is
6522 translated to lowercase.
6523 Use @samp{-fcase-lower} to specify this combination.
6525 There are a few nearly useless combinations:
6528 67: A-1- B01-- C01-- D--2-
6529 68: A-1- B01-- C01-- D---3
6530 69: A-1- B01-- C--23 D01--
6531 70: A-1- B01-- C--23 D--2-
6532 71: A-1- B01-- C--23 D---3
6533 72: A--2 B01-- C0-2- D-1--
6534 73: A--2 B01-- C0-2- D---3
6535 74: A--2 B01-- C-1-3 D0-2-
6536 75: A--2 B01-- C-1-3 D-1--
6537 76: A--2 B01-- C-1-3 D---3
6540 The above allow some programs to be compiled but with restrictions that
6541 make most useful programs impossible: Numbers 67 and 72 warn about
6542 @emph{any} user-defined symbol names (such as @samp{SUBROUTINE FOO});
6544 68 and 73 warn about any user-defined symbol names longer than one
6545 character that don't have at least one non-alphabetic character after
6547 Numbers 69 and 74 disallow any references to intrinsics;
6548 and Numbers 70, 71, 75, and 76 are combinations of the restrictions in
6549 67+69, 68+69, 72+74, and 73+74, respectively.
6551 All redundant combinations are shown in the above tables anyplace
6552 where more than one setting is shown for a low-level switch.
6553 For example, @samp{B0-2-} means either setting 0 or 2 is valid for switch B.
6554 The ``proper'' setting in such a case is the one that copies the setting
6555 of switch A---any other setting might slightly reduce the speed of
6556 the compiler, though possibly to an unmeasurable extent.
6558 All remaining combinations are useless in that they prevent successful
6559 compilation of non-null source files (source files with something other
6563 @section VXT Fortran
6565 @cindex VXT extensions
6566 @cindex extensions, VXT
6567 @code{g77} supports certain constructs that
6568 have different meanings in VXT Fortran than they
6569 do in the GNU Fortran language.
6571 Generally, this manual uses the invented term VXT Fortran to refer
6572 VAX FORTRAN (circa v4).
6573 That compiler offered many popular features, though not necessarily
6574 those that are specific to the VAX processor architecture,
6575 the VMS operating system,
6576 or Digital Equipment Corporation's Fortran product line.
6577 (VAX and VMS probably are trademarks of Digital Equipment
6580 An extension offered by a Digital Fortran product that also is
6581 offered by several other Fortran products for different kinds of
6582 systems is probably going to be considered for inclusion in @code{g77}
6583 someday, and is considered a VXT Fortran feature.
6585 The @samp{-fvxt} option generally specifies that, where
6586 the meaning of a construct is ambiguous (means one thing
6587 in GNU Fortran and another in VXT Fortran), the VXT Fortran
6588 meaning is to be assumed.
6591 * Double Quote Meaning:: @samp{"2000} as octal constant.
6592 * Exclamation Point:: @samp{!} in column 6.
6595 @node Double Quote Meaning
6596 @subsection Meaning of Double Quote
6597 @cindex double quotes
6598 @cindex character constants
6599 @cindex constants, character
6600 @cindex octal constants
6601 @cindex constants, octal
6603 @code{g77} treats double-quote (@samp{"})
6604 as beginning an octal constant of @code{INTEGER(KIND=1)} type
6605 when the @code{-fvxt} option is specified.
6606 The form of this octal constant is
6613 where @var{octal-digits} is a nonempty string of characters in
6614 the set @samp{01234567}.
6616 For example, the @code{-fvxt} option permits this:
6624 The above program would print the value @samp{16}.
6626 @xref{Integer Type}, for information on the preferred construct
6627 for integer constants specified using GNU Fortran's octal notation.
6629 (In the GNU Fortran language, the double-quote character (@samp{"})
6630 delimits a character constant just as does apostrophe (@samp{'}).
6631 There is no way to allow
6632 both constructs in the general case, since statements like
6633 @samp{PRINT *,"2000 !comment?"} would be ambiguous.)
6635 @node Exclamation Point
6636 @subsection Meaning of Exclamation Point in Column 6
6638 @cindex exclamation point
6639 @cindex continuation character
6640 @cindex characters, continuation
6641 @cindex comment character
6642 @cindex characters, comment
6644 @code{g77} treats an exclamation point (@samp{!}) in column 6 of
6645 a fixed-form source file
6646 as a continuation character rather than
6647 as the beginning of a comment
6648 (as it does in any other column)
6649 when the @code{-fvxt} option is specified.
6651 The following program, when run, prints a message indicating
6652 whether it is interpreted according to GNU Fortran (and Fortran 90)
6653 rules or VXT Fortran rules:
6656 C234567 (This line begins in column 1.)
6659 IF (I.EQ.0) PRINT *, ' I am a VXT Fortran program'
6660 IF (I.EQ.1) PRINT *, ' I am a Fortran 90 program'
6661 IF (I.LT.0 .OR. I.GT.1) PRINT *, ' I am a HAL 9000 computer'
6665 (In the GNU Fortran and Fortran 90 languages, exclamation point is
6666 a valid character and, unlike space (@key{SPC}) or zero (@samp{0}),
6667 marks a line as a continuation line when it appears in column 6.)
6671 @cindex compatibility, Fortran 90
6672 @cindex Fortran 90, compatibility
6674 The GNU Fortran language includes a number of features that are
6675 part of Fortran 90, even when the @samp{-ff90} option is not specified.
6676 The features enabled by @samp{-ff90} are intended to be those that,
6677 when @samp{-ff90} is not specified, would have another
6678 meaning to @code{g77}---usually meaning something invalid in the
6679 GNU Fortran language.
6681 So, the purpose of @samp{-ff90} is not to specify whether @code{g77} is
6682 to gratuitously reject Fortran 90 constructs.
6683 The @samp{-pedantic} option specified with @samp{-fno-f90} is intended
6684 to do that, although its implementation is certainly incomplete at
6687 When @samp{-ff90} is specified:
6691 The type of @samp{REAL(@var{expr})} and @samp{AIMAG(@var{expr})},
6692 where @var{expr} is @code{COMPLEX} type,
6693 is the same type as the real part of @var{expr}.
6695 For example, assuming @samp{Z} is type @code{COMPLEX(KIND=2)},
6696 @samp{REAL(Z)} would return a value of type @code{REAL(KIND=2)},
6697 not of type @code{REAL(KIND=1)}, since @samp{-ff90} is specified.
6700 @node Pedantic Compilation
6701 @section Pedantic Compilation
6702 @cindex pedantic compilation
6703 @cindex compilation, pedantic
6705 The @samp{-fpedantic} command-line option specifies that @code{g77}
6706 is to warn about code that is not standard-conforming.
6707 This is useful for finding
6708 some extensions @code{g77} accepts that other compilers might not accept.
6709 (Note that the @samp{-pedantic} and @samp{-pedantic-errors} options
6710 always imply @samp{-fpedantic}.)
6712 With @samp{-fno-f90} in force, ANSI FORTRAN 77 is used as the standard
6713 for conforming code.
6714 With @samp{-ff90} in force, Fortran 90 is used.
6716 The constructs for which @code{g77} issues diagnostics when @samp{-fpedantic}
6717 and @samp{-fno-f90} are in force are:
6721 Automatic arrays, as in
6730 where @samp{A} is not listed in any @code{ENTRY} statement,
6731 and thus is not a dummy argument.
6734 The commas in @samp{READ (5), I} and @samp{WRITE (10), J}.
6736 These commas are disallowed by FORTRAN 77, but, while strictly
6737 superfluous, are syntactically elegant,
6738 especially given that commas are required in statements such
6739 as @samp{READ 99, I} and @samp{PRINT *, J}.
6740 Many compilers permit the superfluous commas for this reason.
6743 @code{DOUBLE COMPLEX}, either explicitly or implicitly.
6745 An explicit use of this type is via a @code{DOUBLE COMPLEX} or
6746 @code{IMPLICIT DOUBLE COMPLEX} statement, for examples.
6748 An example of an implicit use is the expression @samp{C*D},
6749 where @samp{C} is @code{COMPLEX(KIND=1)}
6750 and @samp{D} is @code{DOUBLE PRECISION}.
6751 This expression is prohibited by ANSI FORTRAN 77
6752 because the rules of promotion would suggest that it
6753 produce a @code{DOUBLE COMPLEX} result---a type not
6754 provided for by that standard.
6757 Automatic conversion of numeric
6758 expressions to @code{INTEGER(KIND=1)} in contexts such as:
6762 Array-reference indexes.
6764 Alternate-return values.
6766 Computed @code{GOTO}.
6768 @code{FORMAT} run-time expressions (not yet supported).
6770 Dimension lists in specification statements.
6772 Numbers for I/O statements (such as @samp{READ (UNIT=3.2), I})
6774 Sizes of @code{CHARACTER} entities in specification statements.
6776 Kind types in specification entities (a Fortran 90 feature).
6778 Initial, terminal, and incrementation parameters for implied-@code{DO}
6779 constructs in @code{DATA} statements.
6783 Automatic conversion of @code{LOGICAL} expressions to @code{INTEGER}
6784 in contexts such as arithmetic @code{IF} (where @code{COMPLEX}
6785 expressions are disallowed anyway).
6788 Zero-size array dimensions, as in:
6791 INTEGER I(10,20,4:2)
6795 Zero-length @code{CHARACTER} entities, as in:
6802 Substring operators applied to character constants and named
6806 PRINT *, 'hello'(3:5)
6810 Null arguments passed to statement function, as in:
6817 Disagreement among program units regarding whether a given @code{COMMON}
6818 area is @code{SAVE}d (for targets where program units in a single source
6819 file are ``glued'' together as they typically are for UNIX development
6823 Disagreement among program units regarding the size of a
6824 named @code{COMMON} block.
6827 Specification statements following first @code{DATA} statement.
6829 (In the GNU Fortran language, @samp{DATA I/1/} may be followed by @samp{INTEGER J},
6830 but not @samp{INTEGER I}.
6831 The @samp{-fpedantic} option disallows both of these.)
6834 Semicolon as statement separator, as in:
6841 @c Comma before list of I/O items in @code{WRITE}
6842 @c @c, @code{ENCODE}, @code{DECODE}, and @code{REWRITE}
6843 @c statements, as with @code{READ} (as explained above).
6846 Use of @samp{&} in column 1 of fixed-form source (to indicate continuation).
6849 Use of @code{CHARACTER} constants to initialize numeric entities, and vice
6853 Expressions having two arithmetic operators in a row, such
6857 If @samp{-fpedantic} is specified along with @samp{-ff90}, the
6858 following constructs result in diagnostics:
6862 Use of semicolon as a statement separator on a line
6863 that has an @code{INCLUDE} directive.
6867 @section Distensions
6869 @cindex ugly features
6870 @cindex features, ugly
6872 The @samp{-fugly-*} command-line options determine whether certain
6873 features supported by VAX FORTRAN and other such compilers, but considered
6874 too ugly to be in code that can be changed to use safer and/or more
6875 portable constructs, are accepted.
6876 These are humorously referred to as ``distensions'',
6877 extensions that just plain look ugly in the harsh light of day.
6879 @emph{Note:} The @samp{-fugly} option, which currently serves
6880 as shorthand to enable all of the distensions below, is likely to
6881 be removed in a future version of @code{g77}.
6882 That's because it's likely new distensions will be added that
6883 conflict with existing ones in terms of assigning meaning to
6884 a given chunk of code.
6885 (Also, it's pretty clear that users should not use @samp{-fugly}
6886 as shorthand when the next release of @code{g77} might add a
6887 distension to that that causes their existing code, when recompiled,
6888 to behave differently---perhaps even fail to compile or run
6892 * Ugly Implicit Argument Conversion:: Disabled via @samp{-fno-ugly-args}.
6893 * Ugly Assumed-Size Arrays:: Enabled via @samp{-fugly-assumed}.
6894 * Ugly Null Arguments:: Enabled via @samp{-fugly-comma}.
6895 * Ugly Complex Part Extraction:: Enabled via @samp{-fugly-complex}.
6896 * Ugly Conversion of Initializers:: Disabled via @samp{-fno-ugly-init}.
6897 * Ugly Integer Conversions:: Enabled via @samp{-fugly-logint}.
6898 * Ugly Assigned Labels:: Enabled via @samp{-fugly-assign}.
6901 @node Ugly Implicit Argument Conversion
6902 @subsection Implicit Argument Conversion
6903 @cindex Hollerith constants
6904 @cindex constants, Hollerith
6906 The @samp{-fno-ugly-args} option disables
6907 passing typeless and Hollerith constants as actual arguments
6908 in procedure invocations.
6917 These constructs can be too easily used to create non-portable
6918 code, but are not considered as ``ugly'' as others.
6919 Further, they are widely used in existing Fortran source code
6920 in ways that often are quite portable.
6921 Therefore, they are enabled by default.
6923 @node Ugly Assumed-Size Arrays
6924 @subsection Ugly Assumed-Size Arrays
6925 @cindex arrays, assumed-size
6926 @cindex assumed-size arrays
6927 @cindex DIMENSION X(1)
6929 The @samp{-fugly-assumed} option enables
6930 the treatment of any array with a final dimension specified as @samp{1}
6931 as an assumed-size array, as if @samp{*} had been specified
6934 For example, @samp{DIMENSION X(1)} is treated as if it
6935 had read @samp{DIMENSION X(*)} if @samp{X} is listed as
6936 a dummy argument in a preceding @code{SUBROUTINE}, @code{FUNCTION},
6937 or @code{ENTRY} statement in the same program unit.
6939 Use an explicit lower bound to avoid this interpretation.
6940 For example, @samp{DIMENSION X(1:1)} is never treated as if
6941 it had read @samp{DIMENSION X(*)} or @samp{DIMENSION X(1:*)}.
6942 Nor is @samp{DIMENSION X(2-1)} affected by this option,
6943 since that kind of expression is unlikely to have been
6944 intended to designate an assumed-size array.
6946 This option is used to prevent warnings being issued about apparent
6947 out-of-bounds reference such as @samp{X(2) = 99}.
6949 It also prevents the array from being used in contexts that
6950 disallow assumed-size arrays, such as @samp{PRINT *,X}.
6951 In such cases, a diagnostic is generated and the source file is
6954 The construct affected by this option is used only in old code
6955 that pre-exists the widespread acceptance of adjustable and assumed-size
6956 arrays in the Fortran community.
6958 @emph{Note:} This option does not affect how @samp{DIMENSION X(1)} is
6959 treated if @samp{X} is listed as a dummy argument only
6960 @emph{after} the @code{DIMENSION} statement (presumably in
6961 an @code{ENTRY} statement).
6962 For example, @samp{-fugly-assumed} has no effect on the
6963 following program unit:
6974 @node Ugly Complex Part Extraction
6975 @subsection Ugly Complex Part Extraction
6976 @cindex complex values
6978 @cindex imaginary part
6980 The @samp{-fugly-complex} option enables
6981 use of the @code{REAL()} and @code{AIMAG()}
6982 intrinsics with arguments that are
6983 @code{COMPLEX} types other than @code{COMPLEX(KIND=1)}.
6985 With @samp{-ff90} in effect, these intrinsics return
6986 the unconverted real and imaginary parts (respectively)
6989 With @samp{-fno-f90} in effect, these intrinsics convert
6990 the real and imaginary parts to @code{REAL(KIND=1)}, and return
6991 the result of that conversion.
6993 Due to this ambiguity, the GNU Fortran language defines
6994 these constructs as invalid, except in the specific
6995 case where they are entirely and solely passed as an
6996 argument to an invocation of the @code{REAL()} intrinsic.
7004 is permitted even when @samp{Z} is @code{COMPLEX(KIND=2)}
7005 and @samp{-fno-ugly-complex} is in effect, because the
7008 @code{g77} enforces this restriction, unless @samp{-fugly-complex}
7009 is specified, in which case the appropriate interpretation is
7010 chosen and no diagnostic is issued.
7012 @xref{CMPAMBIG}, for information on how to cope with existing
7013 code with unclear expectations of @code{REAL()} and @code{AIMAG()}
7014 with @code{COMPLEX(KIND=2)} arguments.
7016 @xref{RealPart Intrinsic}, for information on the @code{REALPART()}
7017 intrinsic, used to extract the real part of a complex expression
7019 @xref{ImagPart Intrinsic}, for information on the @code{IMAGPART()}
7020 intrinsic, used to extract the imaginary part of a complex expression
7023 @node Ugly Null Arguments
7024 @subsection Ugly Null Arguments
7025 @cindex trailing comma
7026 @cindex comma, trailing
7027 @cindex characters, comma
7028 @cindex null arguments
7029 @cindex arguments, null
7031 The @samp{-fugly-comma} option enables use of a single trailing comma
7032 to mean ``pass an extra trailing null argument''
7033 in a list of actual arguments to an external procedure,
7034 and use of an empty list of arguments to such a procedure
7035 to mean ``pass a single null argument''.
7037 @cindex omitting arguments
7038 @cindex arguments, omitting
7039 (Null arguments often are used in some procedure-calling
7040 schemes to indicate omitted arguments.)
7042 For example, @samp{CALL FOO(,)} means ``pass
7043 two null arguments'', rather than ``pass one null argument''.
7044 Also, @samp{CALL BAR()} means ``pass one null argument''.
7046 This construct is considered ``ugly'' because it does not
7047 provide an elegant way to pass a single null argument
7048 that is syntactically distinct from passing no arguments.
7049 That is, this construct changes the meaning of code that
7050 makes no use of the construct.
7052 So, with @samp{-fugly-comma} in force, @samp{CALL FOO()}
7053 and @samp{I = JFUNC()} pass a single null argument, instead
7054 of passing no arguments as required by the Fortran 77 and
7057 @emph{Note:} Many systems gracefully allow the case
7058 where a procedure call passes one extra argument that the
7059 called procedure does not expect.
7061 So, in practice, there might be no difference in
7062 the behavior of a program that does @samp{CALL FOO()}
7063 or @samp{I = JFUNC()} and is compiled with @samp{-fugly-comma}
7064 in force as compared to its behavior when compiled
7065 with the default, @samp{-fno-ugly-comma}, in force,
7066 assuming @samp{FOO} and @samp{JFUNC} do not expect any
7067 arguments to be passed.
7069 @node Ugly Conversion of Initializers
7070 @subsection Ugly Conversion of Initializers
7072 The constructs disabled by @samp{-fno-ugly-init} are:
7075 @cindex Hollerith constants
7076 @cindex constants, Hollerith
7078 Use of Hollerith and typeless constants in contexts where they set
7079 initial (compile-time) values for variables, arrays, and named
7080 constants---that is, @code{DATA} and @code{PARAMETER} statements, plus
7081 type-declaration statements specifying initial values.
7083 Here are some sample initializations that are disabled by the
7084 @samp{-fno-ugly-init} option:
7087 PARAMETER (VAL='9A304FFE'X)
7088 REAL*8 STRING/8HOUTPUT00/
7092 @cindex character constants
7093 @cindex constants, character
7095 In the same contexts as above, use of character constants to initialize
7096 numeric items and vice versa (one constant per item).
7098 Here are more sample initializations that are disabled by the
7099 @samp{-fno-ugly-init} option:
7104 PARAMETER (IA = 'A')
7105 PARAMETER (BELL = 7)
7109 Use of Hollerith and typeless constants on the right-hand side
7110 of assignment statements to numeric types, and in other
7111 contexts (such as passing arguments in invocations of
7112 intrinsic procedures and statement functions) that
7113 are treated as assignments to known types (the dummy
7114 arguments, in these cases).
7116 Here are sample statements that are disabled by the
7117 @samp{-fno-ugly-init} option:
7121 PRINT *, IMAX0(2HAB, 2HBA)
7125 The above constructs, when used,
7126 can tend to result in non-portable code.
7127 But, they are widely used in existing Fortran code in ways
7128 that often are quite portable.
7129 Therefore, they are enabled by default.
7131 @node Ugly Integer Conversions
7132 @subsection Ugly Integer Conversions
7134 The constructs enabled via @samp{-fugly-logint} are:
7138 Automatic conversion between @code{INTEGER} and @code{LOGICAL} as
7140 context (typically implies nonportable dependencies on how a
7141 particular implementation encodes @code{.TRUE.} and @code{.FALSE.}).
7144 Use of a @code{LOGICAL} variable in @code{ASSIGN} and assigned-@code{GOTO}
7148 The above constructs are disabled by default because use
7149 of them tends to lead to non-portable code.
7150 Even existing Fortran code that uses that often turns out
7151 to be non-portable, if not outright buggy.
7153 Some of this is due to differences among implementations as
7154 far as how @code{.TRUE.} and @code{.FALSE.} are encoded as
7155 @code{INTEGER} values---Fortran code that assumes a particular
7156 coding is likely to use one of the above constructs, and is
7157 also likely to not work correctly on implementations using
7158 different encodings.
7160 @xref{Equivalence Versus Equality}, for more information.
7162 @node Ugly Assigned Labels
7163 @subsection Ugly Assigned Labels
7164 @cindex ASSIGN statement
7165 @cindex statements, ASSIGN
7166 @cindex assigned labels
7169 The @samp{-fugly-assign} option forces @code{g77} to use the
7170 same storage for assigned labels as it would for a normal
7171 assignment to the same variable.
7173 For example, consider the following code fragment:
7181 Normally, for portability and improved diagnostics, @code{g77}
7182 reserves distinct storage for a ``sibling'' of @samp{I}, used
7183 only for @code{ASSIGN} statements to that variable (along with
7184 the corresponding assigned-@code{GOTO} and assigned-@samp{FORMAT}-I/O
7185 statements that reference the variable).
7187 However, some code (that violates the ANSI FORTRAN 77 standard)
7188 attempts to copy assigned labels among variables involved with
7189 @code{ASSIGN} statements, as in:
7200 Such code doesn't work under @code{g77} unless @samp{-fugly-assign}
7201 is specified on the command-line, ensuring that the value of @code{I}
7202 referenced in the second line is whatever value @code{g77} uses
7203 to designate statement label @samp{10}, so the value may be
7204 copied into the @samp{ISTATE} array, later retrieved into a
7205 variable of the appropriate type (@samp{J}), and used as the target of
7206 an assigned-@code{GOTO} statement.
7208 @emph{Note:} To avoid subtle program bugs,
7209 when @samp{-fugly-assign} is specified,
7210 @code{g77} requires the type of variables
7211 specified in assigned-label contexts
7212 @emph{must} be the same type returned by @code{%LOC()}.
7213 On many systems, this type is effectively the same
7214 as @code{INTEGER(KIND=1)}, while, on others, it is
7215 effectively the same as @code{INTEGER(KIND=2)}.
7217 Do @emph{not} depend on @code{g77} actually writing valid pointers
7218 to these variables, however.
7219 While @code{g77} currently chooses that implementation, it might
7220 be changed in the future.
7222 @xref{Assigned Statement Labels,,Assigned Statement Labels (ASSIGN and GOTO)},
7223 for implementation details on assigned-statement labels.
7226 @chapter The GNU Fortran Compiler
7228 The GNU Fortran compiler, @code{g77}, supports programs written
7229 in the GNU Fortran language and in some other dialects of Fortran.
7231 Some aspects of how @code{g77} works are universal regardless
7232 of dialect, and yet are not properly part of the GNU Fortran
7234 These are described below.
7236 @emph{Note: This portion of the documentation definitely needs a lot
7241 * Run-time Environment Limits::
7243 * Compiler Constants::
7244 * Compiler Intrinsics::
7247 @node Compiler Limits
7248 @section Compiler Limits
7249 @cindex limits, compiler
7250 @cindex compiler limits
7252 @code{g77}, as with GNU tools in general, imposes few arbitrary restrictions
7253 on lengths of identifiers, number of continuation lines, number of external
7254 symbols in a program, and so on.
7256 @cindex options, -Nl
7258 @cindex options, -Nx
7260 @cindex limits, continuation lines
7261 @cindex limits, lengths of names
7262 For example, some other Fortran compiler have an option
7263 (such as @samp{-Nl@var{x}}) to increase the limit on the
7264 number of continuation lines.
7265 Also, some Fortran compilation systems have an option
7266 (such as @samp{-Nx@var{x}}) to increase the limit on the
7267 number of external symbols.
7269 @code{g77}, @code{gcc}, and GNU @code{ld} (the GNU linker) have
7270 no equivalent options, since they do not impose arbitrary
7271 limits in these areas.
7273 @cindex rank, maximum
7274 @cindex maximum rank
7275 @cindex number of dimensions, maximum
7276 @cindex maximum number of dimensions
7277 @cindex limits, rank
7278 @cindex limits, array dimensions
7279 @code{g77} does currently limit the number of dimensions in an array
7280 to the same degree as do the Fortran standards---seven (7).
7281 This restriction might be lifted in a future version.
7283 @node Run-time Environment Limits
7284 @section Run-time Environment Limits
7285 @cindex limits, run-time library
7288 As a portable Fortran implementation,
7289 @code{g77} offers its users direct access to,
7290 and otherwise depends upon,
7291 the underlying facilities of the system
7292 used to build @code{g77},
7293 the system on which @code{g77} itself is used to compile programs,
7294 and the system on which the @code{g77}-compiled program is actually run.
7295 (For most users, the three systems are of the same
7296 type---combination of operating environment and hardware---often
7297 the same physical system.)
7299 The run-time environment for a particular system
7300 inevitably imposes some limits on a program's use
7301 of various system facilities.
7302 These limits vary from system to system.
7304 Even when such limits might be well beyond the
7305 possibility of being encountered on a particular system,
7306 the @code{g77} run-time environment
7307 has certain built-in limits,
7308 usually, but not always, stemming from intrinsics
7309 with inherently limited interfaces.
7311 Currently, the @code{g77} run-time environment
7312 does not generally offer a less-limiting environment
7313 by augmenting the underlying system's own environment.
7315 Therefore, code written in the GNU Fortran language,
7316 while syntactically and semantically portable,
7317 might nevertheless make non-portable assumptions
7318 about the run-time environment---assumptions that
7319 prove to be false for some particular environments.
7321 The GNU Fortran language,
7322 the @code{g77} compiler and run-time environment,
7323 and the @code{g77} documentation
7324 do not yet offer comprehensive portable work-arounds for such limits,
7325 though programmers should be able to
7326 find their own in specific instances.
7328 Not all of the limitations are described in this document.
7329 Some of the known limitations include:
7332 * Timer Wraparounds::
7333 * Year 2000 (Y2K) Problems::
7335 * Character-variable Length::
7336 * Year 10000 (Y10K) Problems::
7339 @node Timer Wraparounds
7340 @subsection Timer Wraparounds
7342 Intrinsics that return values computed from system timers,
7343 whether elapsed (wall-clock) timers,
7345 or other kinds of timers,
7346 are prone to experiencing wrap-around errors
7347 (or returning wrapped-around values from successive calls)
7348 due to insufficient ranges
7349 offered by the underlying system's timers.
7351 @cindex negative time
7354 Some of the symptoms of such behaviors include
7355 apparently negative time being computed for a duration,
7356 an extremely short amount of time being computed for a long duration,
7357 and an extremely long amount of time being computed for a short duration.
7359 See the following for intrinsics
7360 known to have potential problems in these areas
7361 on at least some systems:
7362 @ref{CPU_Time Intrinsic},
7363 @ref{DTime Intrinsic (function)}, @ref{DTime Intrinsic (subroutine)},
7364 @ref{ETime Intrinsic (function)}, @ref{ETime Intrinsic (subroutine)},
7365 @ref{MClock Intrinsic}, @ref{MClock8 Intrinsic},
7366 @ref{Secnds Intrinsic},
7367 @ref{Second Intrinsic (function)}, @ref{Second Intrinsic (subroutine)},
7368 @ref{System_Clock Intrinsic},
7369 @ref{Time Intrinsic (UNIX)}, @ref{Time Intrinsic (VXT)},
7370 @ref{Time8 Intrinsic}.
7372 @node Year 2000 (Y2K) Problems
7373 @subsection Year 2000 (Y2K) Problems
7374 @cindex Y2K compliance
7375 @cindex Year 2000 compliance
7377 While the @code{g77} compiler itself is believed to
7378 be Year-2000 (Y2K) compliant,
7379 some intrinsics are not,
7380 and, potentially, some underlying systems are not,
7381 perhaps rendering some Y2K-compliant intrinsics
7382 non-compliant when used on those particular systems.
7384 Fortran code that uses non-Y2K-compliant intrinsics
7386 is, itself, almost certainly not compliant,
7387 and should be modified to use Y2K-compliant intrinsics instead.
7389 Fortran code that uses no non-Y2K-compliant intrinsics,
7390 but which currently is running on a non-Y2K-compliant system,
7391 can be made more Y2K compliant by compiling and
7392 linking it for use on a new Y2K-compliant system,
7393 such as a new version of an old, non-Y2K-compliant, system.
7395 Currently, information on Y2K and related issues
7396 is being maintained at
7397 @uref{http://www.gnu.org/software/year2000-list.html}.
7399 See the following for intrinsics
7400 known to have potential problems in these areas
7401 on at least some systems:
7402 @ref{Date Intrinsic},
7403 @ref{IDate Intrinsic (VXT)}.
7406 @cindex date_y2kbuggy_0
7407 @cindex vxtidate_y2kbuggy_0
7408 @cindex G77_date_y2kbuggy_0
7409 @cindex G77_vxtidate_y2kbuggy_0
7410 The @code{libg2c} library
7411 shipped with any @code{g77} that warns
7412 about invocation of a non-Y2K-compliant intrinsic
7413 has renamed the @samp{EXTERNAL} procedure names
7414 of those intrinsics.
7415 This is done so that
7416 the @code{libg2c} implementations of these intrinsics
7417 cannot be directly linked to
7418 as @samp{EXTERNAL} names
7419 (which normally would avoid the non-Y2K-intrinsic warning).
7421 The renamed forms of the @samp{EXTERNAL} names
7422 of these renamed procedures
7424 by appending the string @samp{_y2kbug}
7425 to the name of the procedure
7432 EXTERNAL DATE_Y2KBUG, VXTIDATE_Y2KBUG
7433 CALL DATE_Y2KBUG (STR)
7434 CALL VXTIDATE_Y2KBUG (MM, DD, YY)
7437 (Note that the @samp{EXTERNAL} statement
7438 is not actually required,
7439 since the modified names are not recognized as intrinsics
7440 by the current version of @code{g77}.
7441 But it is shown in this specific case,
7442 for purposes of illustration.)
7444 The renaming of @samp{EXTERNAL} procedure names of these intrinsics
7445 causes unresolved references at link time.
7446 For example, @samp{EXTERNAL DATE; CALL DATE(STR)}
7447 is normally compiled by @code{g77}
7448 as, in C, @samp{date_(&str, 20);}.
7449 This, in turn, links to the @samp{date_} procedure
7450 in the @samp{libE77} portion of @code{libg2c},
7451 which purposely calls a nonexistent procedure
7452 named @samp{G77_date_y2kbuggy_0}.
7453 The resulting link-time error is designed, via this name,
7454 to encourage the programmer to look up the
7455 index entries to this portion of the @code{g77} documentation.
7457 Generally, we recommend that the @samp{EXTERNAL} method
7458 of invoking procedures in @code{libg2c}
7460 When used, some of the correctness checking
7461 normally performed by @code{g77}
7464 In particular, it is probably better to use the
7465 @samp{INTRINSIC} method of invoking
7466 non-Y2K-compliant procedures,
7467 so anyone compiling the code
7468 can quickly notice the potential Y2K problems
7469 (via the warnings printing by @code{g77})
7470 without having to even look at the code itself.
7472 If there are problems linking @code{libg2c}
7473 to code compiled by @code{g77}
7474 that involve the string @samp{y2kbug},
7475 and these are not explained above,
7476 that probably indicates
7477 that a version of @code{libg2c}
7478 older than @code{g77}
7480 or that the new library is being linked
7481 to code compiled by an older version of @code{g77}.
7483 That's because, as of the version that warns about
7484 non-Y2K-compliant intrinsic invocation,
7485 @code{g77} references the @code{libg2c} implementations
7487 using new names, containing the string @samp{y2kbug}.
7489 So, linking newly-compiled code
7490 (invoking one of the intrinsics in question)
7492 might yield an unresolved reference
7493 to @samp{G77_date_y2kbug_0}.
7494 (The old library calls it @samp{G77_date_0}.)
7496 Similarly, linking previously-compiled code
7498 might yield an unresolved reference
7499 to @samp{G77_vxtidate_0}.
7500 (The new library calls it @samp{G77_vxtidate_y2kbug_0}.)
7502 The proper fix for the above problems
7503 is to obtain the latest release of @code{g77}
7504 and related products
7505 (including @code{libg2c})
7506 and install them on all systems,
7507 then recompile, relink, and install
7509 all existing Fortran programs.
7511 (Normally, this sort of renaming is steadfastly avoided.
7512 In this case, however, it seems more important to highlight
7513 potential Y2K problems
7514 than to ease the transition
7515 of potentially non-Y2K-compliant code
7516 to new versions of @code{g77} and @code{libg2c}.)
7519 @subsection Array Size
7520 @cindex limits, array size
7523 Currently, @code{g77} uses the default @code{INTEGER} type
7525 which limits the sizes of single-dimension arrays
7526 on systems offering a larger address space
7527 than can be addressed by that type.
7528 (That @code{g77} puts all arrays in memory
7529 could be considered another limitation---it
7530 could use large temporary files---but that decision
7531 is left to the programmer as an implementation choice
7532 by most Fortran implementations.)
7534 @c ??? Investigate this, to offer a more clear statement
7535 @c than the following paragraphs do. -- burley 1999-02-17
7536 It is not yet clear whether this limitation
7537 never, sometimes, or always applies to the
7538 sizes of multiple-dimension arrays as a whole.
7540 For example, on a system with 64-bit addresses
7541 and 32-bit default @code{INTEGER},
7542 an array with a size greater than can be addressed
7544 can be declared using multiple dimensions.
7545 Such an array is therefore larger
7546 than a single-dimension array can be,
7549 @cindex limits, multi-dimension arrays
7550 @cindex multi-dimension arrays
7551 @cindex arrays, dimensioning
7552 Whether large multiple-dimension arrays are reliably supported
7553 depends mostly on the @code{gcc} back end (code generator)
7554 used by @code{g77}, and has not yet been fully investigated.
7556 @node Character-variable Length
7557 @subsection Character-variable Length
7558 @cindex limits, on character-variable length
7559 @cindex character-variable length
7561 Currently, @code{g77} uses the default @code{INTEGER} type
7562 for the lengths of @code{CHARACTER} variables
7565 This means that, for example,
7566 a system with a 64-bit address space
7567 and a 32-bit default @code{INTEGER} type
7568 does not, under @code{g77},
7569 support a @code{CHARACTER*@var{n}} declaration
7570 where @var{n} is greater than 2147483647.
7572 @node Year 10000 (Y10K) Problems
7573 @subsection Year 10000 (Y10K) Problems
7574 @cindex Y10K compliance
7575 @cindex Year 10000 compliance
7577 Most intrinsics returning, or computing values based on,
7578 date information are prone to Year-10000 (Y10K) problems,
7579 due to supporting only 4 digits for the year.
7581 See the following for examples:
7582 @ref{FDate Intrinsic (function)}, @ref{FDate Intrinsic (subroutine)},
7583 @ref{IDate Intrinsic (UNIX)},
7584 @ref{Time Intrinsic (VXT)},
7585 @ref{Date_and_Time Intrinsic}.
7587 @node Compiler Types
7588 @section Compiler Types
7589 @cindex types, of data
7592 Fortran implementations have a fair amount of freedom given them by the
7593 standard as far as how much storage space is used and how much precision
7594 and range is offered by the various types such as @code{LOGICAL(KIND=1)},
7595 @code{INTEGER(KIND=1)}, @code{REAL(KIND=1)}, @code{REAL(KIND=2)},
7596 @code{COMPLEX(KIND=1)}, and @code{CHARACTER}.
7597 Further, many compilers offer so-called @samp{*@var{n}} notation, but
7598 the interpretation of @var{n} varies across compilers and target architectures.
7600 The standard requires that @code{LOGICAL(KIND=1)}, @code{INTEGER(KIND=1)},
7601 and @code{REAL(KIND=1)}
7602 occupy the same amount of storage space, and that @code{COMPLEX(KIND=1)}
7603 and @code{REAL(KIND=2)} take twice as much storage space as @code{REAL(KIND=1)}.
7604 Further, it requires that @code{COMPLEX(KIND=1)}
7605 entities be ordered such that when a @code{COMPLEX(KIND=1)} variable is
7606 storage-associated (such as via @code{EQUIVALENCE})
7607 with a two-element @code{REAL(KIND=1)} array named @samp{R}, @samp{R(1)}
7608 corresponds to the real element and @samp{R(2)} to the imaginary
7609 element of the @code{COMPLEX(KIND=1)} variable.
7611 (Few requirements as to precision or ranges of any of these are
7612 placed on the implementation, nor is the relationship of storage sizes of
7613 these types to the @code{CHARACTER} type specified, by the standard.)
7615 @code{g77} follows the above requirements, warning when compiling
7616 a program requires placement of items in memory that contradict the
7617 requirements of the target architecture.
7618 (For example, a program can require placement of a @code{REAL(KIND=2)}
7619 on a boundary that is not an even multiple of its size, but still an
7620 even multiple of the size of a @code{REAL(KIND=1)} variable.
7621 On some target architectures, using the canonical
7622 mapping of Fortran types to underlying architectural types, such
7623 placement is prohibited by the machine definition or
7624 the Application Binary Interface (ABI) in force for
7625 the configuration defined for building @code{gcc} and @code{g77}.
7626 @code{g77} warns about such
7627 situations when it encounters them.)
7629 @code{g77} follows consistent rules for configuring the mapping between Fortran
7630 types, including the @samp{*@var{n}} notation, and the underlying architectural
7631 types as accessed by a similarly-configured applicable version of the
7632 @code{gcc} compiler.
7633 These rules offer a widely portable, consistent Fortran/C
7634 environment, although they might well conflict with the expectations of
7635 users of Fortran compilers designed and written for particular
7638 These rules are based on the configuration that is in force for the
7639 version of @code{gcc} built in the same release as @code{g77} (and
7640 which was therefore used to build both the @code{g77} compiler
7641 components and the @code{libg2c} run-time library):
7644 @cindex REAL(KIND=1) type
7645 @cindex types, REAL(KIND=1)
7647 Same as @code{float} type.
7649 @cindex REAL(KIND=2) type
7650 @cindex types, REAL(KIND=2)
7652 Same as whatever floating-point type that is twice the size
7653 of a @code{float}---usually, this is a @code{double}.
7655 @cindex INTEGER(KIND=1) type
7656 @cindex types, INTEGER(KIND=1)
7657 @item INTEGER(KIND=1)
7658 Same as an integral type that is occupies the same amount
7659 of memory storage as @code{float}---usually, this is either
7660 an @code{int} or a @code{long int}.
7662 @cindex LOGICAL(KIND=1) type
7663 @cindex types, LOGICAL(KIND=1)
7664 @item LOGICAL(KIND=1)
7665 Same @code{gcc} type as @code{INTEGER(KIND=1)}.
7667 @cindex INTEGER(KIND=2) type
7668 @cindex types, INTEGER(KIND=2)
7669 @item INTEGER(KIND=2)
7670 Twice the size, and usually nearly twice the range,
7671 as @code{INTEGER(KIND=1)}---usually, this is either
7672 a @code{long int} or a @code{long long int}.
7674 @cindex LOGICAL(KIND=2) type
7675 @cindex types, LOGICAL(KIND=2)
7676 @item LOGICAL(KIND=2)
7677 Same @code{gcc} type as @code{INTEGER(KIND=2)}.
7679 @cindex INTEGER(KIND=3) type
7680 @cindex types, INTEGER(KIND=3)
7681 @item INTEGER(KIND=3)
7682 Same @code{gcc} type as signed @code{char}.
7684 @cindex LOGICAL(KIND=3) type
7685 @cindex types, LOGICAL(KIND=3)
7686 @item LOGICAL(KIND=3)
7687 Same @code{gcc} type as @code{INTEGER(KIND=3)}.
7689 @cindex INTEGER(KIND=6) type
7690 @cindex types, INTEGER(KIND=6)
7691 @item INTEGER(KIND=6)
7692 Twice the size, and usually nearly twice the range,
7693 as @code{INTEGER(KIND=3)}---usually, this is
7696 @cindex LOGICAL(KIND=6) type
7697 @cindex types, LOGICAL(KIND=6)
7698 @item LOGICAL(KIND=6)
7699 Same @code{gcc} type as @code{INTEGER(KIND=6)}.
7701 @cindex COMPLEX(KIND=1) type
7702 @cindex types, COMPLEX(KIND=1)
7703 @item COMPLEX(KIND=1)
7704 Two @code{REAL(KIND=1)} scalars (one for the real part followed by
7705 one for the imaginary part).
7707 @cindex COMPLEX(KIND=2) type
7708 @cindex types, COMPLEX(KIND=2)
7709 @item COMPLEX(KIND=2)
7710 Two @code{REAL(KIND=2)} scalars.
7712 @cindex *@var{n} notation
7713 @item @var{numeric-type}*@var{n}
7714 (Where @var{numeric-type} is any type other than @code{CHARACTER}.)
7715 Same as whatever @code{gcc} type occupies @var{n} times the storage
7716 space of a @code{gcc} @code{char} item.
7718 @cindex DOUBLE PRECISION type
7719 @cindex types, DOUBLE PRECISION
7720 @item DOUBLE PRECISION
7721 Same as @code{REAL(KIND=2)}.
7723 @cindex DOUBLE COMPLEX type
7724 @cindex types, DOUBLE COMPLEX
7725 @item DOUBLE COMPLEX
7726 Same as @code{COMPLEX(KIND=2)}.
7729 Note that the above are proposed correspondences and might change
7730 in future versions of @code{g77}---avoid writing code depending
7733 Other types supported by @code{g77}
7734 are derived from gcc types such as @code{char}, @code{short},
7735 @code{int}, @code{long int}, @code{long long int}, @code{long double},
7737 That is, whatever types @code{gcc} already supports, @code{g77} supports
7738 now or probably will support in a future version.
7739 The rules for the @samp{@var{numeric-type}*@var{n}} notation
7740 apply to these types,
7741 and new values for @samp{@var{numeric-type}(KIND=@var{n})} will be
7742 assigned in a way that encourages clarity, consistency, and portability.
7744 @node Compiler Constants
7745 @section Compiler Constants
7747 @cindex types, constants
7749 @code{g77} strictly assigns types to @emph{all} constants not
7750 documented as ``typeless'' (typeless constants including @samp{'1'Z},
7752 Many other Fortran compilers attempt to assign types to typed constants
7753 based on their context.
7754 This results in hard-to-find bugs, nonportable
7755 code, and is not in the spirit (though it strictly follows the letter)
7756 of the 77 and 90 standards.
7758 @code{g77} might offer, in a future release, explicit constructs by
7759 which a wider variety of typeless constants may be specified, and/or
7760 user-requested warnings indicating places where @code{g77} might differ
7761 from how other compilers assign types to constants.
7763 @xref{Context-Sensitive Constants}, for more information on this issue.
7765 @node Compiler Intrinsics
7766 @section Compiler Intrinsics
7768 @code{g77} offers an ever-widening set of intrinsics.
7769 Currently these all are procedures (functions and subroutines).
7771 Some of these intrinsics are unimplemented, but their names reserved
7772 to reduce future problems with existing code as they are implemented.
7773 Others are implemented as part of the GNU Fortran language, while
7774 yet others are provided for compatibility with other dialects of
7775 Fortran but are not part of the GNU Fortran language.
7777 To manage these distinctions, @code{g77} provides intrinsic @emph{groups},
7778 a facility that is simply an extension of the intrinsic groups provided
7779 by the GNU Fortran language.
7782 * Intrinsic Groups:: How intrinsics are grouped for easy management.
7783 * Other Intrinsics:: Intrinsics other than those in the GNU
7787 @node Intrinsic Groups
7788 @subsection Intrinsic Groups
7789 @cindex groups of intrinsics
7790 @cindex intrinsics, groups
7792 A given specific intrinsic belongs in one or more groups.
7793 Each group is deleted, disabled, hidden, or enabled
7794 by default or a command-line option.
7795 The meaning of each term follows.
7798 @cindex deleted intrinsics
7799 @cindex intrinsics, deleted
7801 No intrinsics are recognized as belonging to that group.
7803 @cindex disabled intrinsics
7804 @cindex intrinsics, disabled
7806 Intrinsics are recognized as belonging to the group, but
7807 references to them (other than via the @code{INTRINSIC} statement)
7808 are disallowed through that group.
7810 @cindex hidden intrinsics
7811 @cindex intrinsics, hidden
7813 Intrinsics in that group are recognized and enabled (if implemented)
7814 @emph{only} if the first mention of the actual name of an intrinsic
7815 in a program unit is in an @code{INTRINSIC} statement.
7817 @cindex enabled intrinsics
7818 @cindex intrinsics, enabled
7820 Intrinsics in that group are recognized and enabled (if implemented).
7823 The distinction between deleting and disabling a group is illustrated
7824 by the following example.
7825 Assume intrinsic @samp{FOO} belongs only to group @samp{FGR}.
7826 If group @samp{FGR} is deleted, the following program unit will
7827 successfully compile, because @samp{FOO()} will be seen as a
7828 reference to an external function named @samp{FOO}:
7836 If group @samp{FGR} is disabled, compiling the above program will produce
7837 diagnostics, either because the @samp{FOO} intrinsic is improperly invoked
7838 or, if properly invoked, it is not enabled.
7839 To change the above program so it references an external function @samp{FOO}
7840 instead of the disabled @samp{FOO} intrinsic,
7841 add the following line to the top:
7848 So, deleting a group tells @code{g77} to pretend as though the intrinsics in
7849 that group do not exist at all, whereas disabling it tells @code{g77} to
7850 recognize them as (disabled) intrinsics in intrinsic-like contexts.
7852 Hiding a group is like enabling it, but the intrinsic must be first
7853 named in an @code{INTRINSIC} statement to be considered a reference to the
7854 intrinsic rather than to an external procedure.
7855 This might be the ``safest'' way to treat a new group of intrinsics
7857 code, because it allows the old code to be generally written as if
7858 those new intrinsics never existed, but to be changed to use them
7859 by inserting @code{INTRINSIC} statements in the appropriate places.
7860 However, it should be the goal of development to use @code{EXTERNAL}
7861 for all names of external procedures that might be intrinsic names.
7863 If an intrinsic is in more than one group, it is enabled if any of its
7864 containing groups are enabled; if not so enabled, it is hidden if
7865 any of its containing groups are hidden; if not so hidden, it is disabled
7866 if any of its containing groups are disabled; if not so disabled, it is
7868 This extra complication is necessary because some intrinsics,
7869 such as @code{IBITS}, belong to more than one group, and hence should be
7870 enabled if any of the groups to which they belong are enabled, and so
7875 @cindex intrinsics, groups of
7876 @cindex groups of intrinsics
7878 @cindex @code{badu77} intrinsics group
7880 UNIX intrinsics having inappropriate forms (usually functions that
7881 have intended side effects).
7883 @cindex @code{gnu} intrinsics group
7885 Intrinsics the GNU Fortran language supports that are extensions to
7886 the Fortran standards (77 and 90).
7888 @cindex @code{f2c} intrinsics group
7890 Intrinsics supported by AT&T's @code{f2c} converter and/or @code{libf2c}.
7892 @cindex @code{f90} intrinsics group
7894 Fortran 90 intrinsics.
7896 @cindex @code{mil} intrinsics group
7898 MIL-STD 1753 intrinsics (@code{MVBITS}, @code{IAND}, @code{BTEST}, and so on).
7900 @cindex @code{mil} intrinsics group
7902 UNIX intrinsics (@code{IARGC}, @code{EXIT}, @code{ERF}, and so on).
7904 @cindex @code{mil} intrinsics group
7906 VAX/VMS FORTRAN (current as of v4) intrinsics.
7909 @node Other Intrinsics
7910 @subsection Other Intrinsics
7911 @cindex intrinsics, others
7912 @cindex other intrinsics
7914 @code{g77} supports intrinsics other than those in the GNU Fortran
7916 This set of intrinsics is described below.
7919 (Note that the empty lines appearing in the menu below
7920 are not intentional---they result from a bug in the
7921 @code{makeinfo} program.)
7924 @c The actual documentation for intrinsics comes from
7925 @c intdoc.texi, which in turn is automatically generated
7926 @c from the internal g77 tables in intrin.def _and_ the
7927 @c largely hand-written text in intdoc.h. So, if you want
7928 @c to change or add to existing documentation on intrinsics,
7929 @c you probably want to edit intdoc.h.
7941 @include intdoc.texi
7943 @node Other Compilers
7944 @chapter Other Compilers
7946 An individual Fortran source file can be compiled to
7947 an object (@file{*.o}) file instead of to the final
7949 This allows several portions of a program to be compiled
7950 at different times and linked together whenever a new
7951 version of the program is needed.
7952 However, it introduces the issue of @dfn{object compatibility}
7953 across the various object files (and libraries, or @file{*.a}
7954 files) that are linked together to produce any particular
7957 Object compatibility is an issue when combining, in one
7958 program, Fortran code compiled by more than one compiler
7959 (or more than one configuration of a compiler).
7961 disagree on how to transform the names of procedures, there
7962 will normally be errors when linking such programs.
7963 Worse, if the compilers agree on naming, but disagree on issues
7964 like how to pass parameters, return arguments, and lay out
7965 @code{COMMON} areas, the earliest detected errors might be the
7966 incorrect results produced by the program (and that assumes
7967 these errors are detected, which is not always the case).
7969 Normally, @code{g77} generates code that is
7970 object-compatible with code generated by a version of
7971 @code{f2c} configured (with, for example, @file{f2c.h} definitions)
7972 to be generally compatible with @code{g77} as built by @code{gcc}.
7973 (Normally, @code{f2c} will, by default, conform to the appropriate
7974 configuration, but it is possible that older or perhaps even newer
7975 versions of @code{f2c}, or versions having certain configuration changes
7976 to @code{f2c} internals, will produce object files that are
7977 incompatible with @code{g77}.)
7979 For example, a Fortran string subroutine
7980 argument will become two arguments on the C side: a @code{char *}
7981 and an @code{int} length.
7983 Much of this compatibility results from the fact that
7984 @code{g77} uses the same run-time library,
7985 @code{libf2c}, used by @code{f2c},
7986 though @code{g77} gives its version the name @code{libg2c}
7987 so as to avoid conflicts when linking,
7988 installing them in the same directories,
7991 Other compilers might or might not generate code that
7992 is object-compatible with @code{libg2c} and current @code{g77},
7993 and some might offer such compatibility only when explicitly
7994 selected via a command-line option to the compiler.
7996 @emph{Note: This portion of the documentation definitely needs a lot
8000 * Dropping f2c Compatibility:: When speed is more important.
8001 * Compilers Other Than f2c:: Interoperation with code from other compilers.
8004 @node Dropping f2c Compatibility
8005 @section Dropping @code{f2c} Compatibility
8007 Specifying @samp{-fno-f2c} allows @code{g77} to generate, in
8008 some cases, faster code, by not needing to allow to the possibility
8009 of linking with code compiled by @code{f2c}.
8011 For example, this affects how @code{REAL(KIND=1)},
8012 @code{COMPLEX(KIND=1)}, and @code{COMPLEX(KIND=2)} functions are called.
8013 With @samp{-fno-f2c}, they are
8014 compiled as returning the appropriate @code{gcc} type
8015 (@code{float}, @code{__complex__ float}, @code{__complex__ double},
8016 in many configurations).
8018 With @samp{-ff2c} in force, they
8019 are compiled differently (with perhaps slower run-time performance)
8020 to accommodate the restrictions inherent in @code{f2c}'s use of K&R
8021 C as an intermediate language---@code{REAL(KIND=1)} functions
8022 return C's @code{double} type, while @code{COMPLEX} functions return
8023 @code{void} and use an extra argument pointing to a place for the functions to
8024 return their values.
8026 It is possible that, in some cases, leaving @samp{-ff2c} in force
8027 might produce faster code than using @samp{-fno-f2c}.
8028 Feel free to experiment, but remember to experiment with changing the way
8029 @emph{entire programs and their Fortran libraries are compiled} at
8030 a time, since this sort of experimentation affects the interface
8031 of code generated for a Fortran source file---that is, it affects
8032 object compatibility.
8034 Note that @code{f2c} compatibility is a fairly static target to achieve,
8035 though not necessarily perfectly so, since, like @code{g77}, it is
8036 still being improved.
8037 However, specifying @samp{-fno-f2c} causes @code{g77}
8038 to generate code that will probably be incompatible with code
8039 generated by future versions of @code{g77} when the same option
8041 You should make sure you are always able to recompile complete
8042 programs from source code when upgrading to new versions of @code{g77}
8043 or @code{f2c}, especially when using options such as @samp{-fno-f2c}.
8045 Therefore, if you are using @code{g77} to compile libraries and other
8046 object files for possible future use and you don't want to require
8047 recompilation for future use with subsequent versions of @code{g77},
8048 you might want to stick with @code{f2c} compatibility for now, and
8049 carefully watch for any announcements about changes to the
8050 @code{f2c}/@code{libf2c} interface that might affect existing programs
8051 (thus requiring recompilation).
8053 It is probable that a future version of @code{g77} will not,
8054 by default, generate object files compatible with @code{f2c},
8055 and that version probably would no longer use @code{libf2c}.
8056 If you expect to depend on this compatibility in the
8057 long term, use the options @samp{-ff2c -ff2c-library} when compiling
8058 all of the applicable code.
8059 This should cause future versions of @code{g77} either to produce
8060 compatible code (at the expense of the availability of some features and
8061 performance), or at the very least, to produce diagnostics.
8063 (The library @code{g77} produces will no longer be named @file{libg2c}
8064 when it is no longer generally compatible with @file{libf2c}.
8065 It will likely be referred to, and, if installed as a distinct
8066 library, named @code{libg77}, or some other as-yet-unused name.)
8068 @node Compilers Other Than f2c
8069 @section Compilers Other Than @code{f2c}
8071 On systems with Fortran compilers other than @code{f2c} and @code{g77},
8072 code compiled by @code{g77} is not expected to work
8073 well with code compiled by the native compiler.
8074 (This is true for @code{f2c}-compiled objects as well.)
8075 Libraries compiled with the native compiler probably will have
8076 to be recompiled with @code{g77} to be used with @code{g77}-compiled code.
8078 Reasons for such incompatibilities include:
8082 There might be differences in the way names of Fortran procedures
8083 are translated for use in the system's object-file format.
8084 For example, the statement @samp{CALL FOO} might be compiled
8085 by @code{g77} to call a procedure the linker @code{ld} sees
8086 given the name @samp{_foo_}, while the apparently corresponding
8087 statement @samp{SUBROUTINE FOO} might be compiled by the
8088 native compiler to define the linker-visible name @samp{_foo},
8089 or @samp{_FOO_}, and so on.
8092 There might be subtle type mismatches which cause subroutine arguments
8093 and function return values to get corrupted.
8095 This is why simply getting @code{g77} to
8096 transform procedure names the same way a native
8097 compiler does is not usually a good idea---unless
8098 some effort has been made to ensure that, aside
8099 from the way the two compilers transform procedure
8100 names, everything else about the way they generate
8101 code for procedure interfaces is identical.
8105 use libraries of private I/O routines which will not be available
8106 at link time unless you have the native compiler---and you would
8107 have to explicitly ask for them.
8109 For example, on the Sun you
8110 would have to add @samp{-L/usr/lang/SCx.x -lF77 -lV77} to the link
8114 @node Other Languages
8115 @chapter Other Languages
8117 @emph{Note: This portion of the documentation definitely needs a lot
8121 * Interoperating with C and C++::
8124 @node Interoperating with C and C++
8125 @section Tools and advice for interoperating with C and C++
8127 @cindex C, linking with
8128 @cindex C++, linking with
8129 @cindex linking with C
8130 The following discussion assumes that you are running @code{g77} in @code{f2c}
8131 compatibility mode, i.e.@: not using @samp{-fno-f2c}.
8133 advice about quick and simple techniques for linking Fortran and C (or
8134 C++), the most common requirement.
8135 For the full story consult the
8136 description of code generation.
8137 @xref{Debugging and Interfacing}.
8139 When linking Fortran and C, it's usually best to use @code{g77} to do
8140 the linking so that the correct libraries are included (including the
8142 If you're linking with C++ you will want to add
8143 @samp{-lstdc++}, @samp{-lg++} or whatever.
8144 If you need to use another
8145 driver program (or @code{ld} directly),
8146 you can find out what linkage
8147 options @code{g77} passes by running @samp{g77 -v}.
8150 * C Interfacing Tools::
8151 * C Access to Type Information::
8152 * f2c Skeletons and Prototypes::
8153 * C++ Considerations::
8157 @node C Interfacing Tools
8158 @subsection C Interfacing Tools
8162 Even if you don't actually use it as a compiler, @samp{f2c} from
8163 @uref{ftp://ftp.netlib.org/f2c/src}, can be a useful tool when you're
8164 interfacing (linking) Fortran and C@.
8165 @xref{f2c Skeletons and Prototypes,,Generating Skeletons and Prototypes with @code{f2c}}.
8167 To use @code{f2c} for this purpose you only need retrieve and
8168 build the @file{src} directory from the distribution, consult the
8169 @file{README} instructions there for machine-specifics, and install the
8170 @code{f2c} program on your path.
8172 Something else that might be useful is @samp{cfortran.h} from
8173 @uref{ftp://zebra/desy.de/cfortran}.
8174 This is a fairly general tool which
8175 can be used to generate interfaces for calling in both directions
8176 between Fortran and C@.
8177 It can be used in @code{f2c} mode with
8178 @code{g77}---consult its documentation for details.
8180 @node C Access to Type Information
8181 @subsection Accessing Type Information in C
8183 @cindex types, Fortran/C
8184 Generally, C code written to link with
8185 @code{g77} code---calling and/or being
8186 called from Fortran---should @samp{#include <g2c.h>} to define the C
8187 versions of the Fortran types.
8188 Don't assume Fortran @code{INTEGER} types
8189 correspond to C @samp{int}s, for instance; instead, declare them as
8190 @code{integer}, a type defined by @file{g2c.h}.
8191 @file{g2c.h} is installed where @code{gcc} will find it by
8192 default, assuming you use a copy of @code{gcc} compatible with
8193 @code{g77}, probably built at the same time as @code{g77}.
8195 @node f2c Skeletons and Prototypes
8196 @subsection Generating Skeletons and Prototypes with @code{f2c}
8199 @cindex -fno-second-underscore
8200 A simple and foolproof way to write @code{g77}-callable C routines---e.g.@: to
8201 interface with an existing library---is to write a file (named, for
8202 example, @file{fred.f}) of dummy Fortran
8203 skeletons comprising just the declaration of the routine(s) and dummy
8204 arguments plus @samp{END} statements.
8205 Then run @code{f2c} on file @file{fred.f} to produce @file{fred.c}
8206 into which you can edit
8207 useful code, confident the calling sequence is correct, at least.
8208 (There are some errors otherwise commonly made in generating C
8209 interfaces with @code{f2c} conventions,
8210 such as not using @code{doublereal}
8211 as the return type of a @code{REAL} @code{FUNCTION}.)
8214 @code{f2c} also can help with calling Fortran from C, using its
8215 @samp{-P} option to generate C prototypes appropriate for calling the
8216 Fortran.@footnote{The files generated like this can also be used for
8217 inter-unit consistency checking of dummy and actual arguments, although
8218 the @samp{ftnchek} tool from @uref{ftp://ftp.netlib.org/fortran}
8219 or @uref{ftp://ftp.dsm.fordham.edu} is
8220 probably better for this purpose.}
8221 If the Fortran code containing any
8222 routines to be called from C is in file @file{joe.f}, use the command
8223 @kbd{f2c -P joe.f} to generate the file @file{joe.P} containing
8224 prototype information.
8225 @code{#include} this in the C which has to call
8226 the Fortran routines to make sure you get it right.
8228 @xref{Arrays,,Arrays (DIMENSION)}, for information on the differences
8229 between the way Fortran (including compilers like @code{g77}) and
8232 @node C++ Considerations
8233 @subsection C++ Considerations
8236 @code{f2c} can be used to generate suitable code for compilation with a
8237 C++ system using the @samp{-C++} option.
8238 The important thing about linking @code{g77}-compiled
8239 code with C++ is that the prototypes for the @code{g77}
8240 routines must specify C linkage to avoid name mangling.
8241 So, use an @samp{extern "C"} declaration.
8242 @code{f2c}'s @samp{-C++} option will take care
8243 of this when generating skeletons or prototype files as above, and also
8244 avoid clashes with C++ reserved words in addition to those in C@.
8247 @subsection Startup Code
8249 @cindex startup code
8250 @cindex run-time, initialization
8251 @cindex initialization, run-time
8252 Unlike with some runtime systems,
8253 it shouldn't be necessary
8254 (unless there are bugs)
8255 to use a Fortran main program unit to ensure the
8256 runtime---specifically the I/O system---is initialized.
8258 However, to use the @code{g77} intrinsics @code{GETARG} and @code{IARGC},
8259 either the @code{main} routine from the @file{libg2c} library must be used,
8260 or the @code{f_setarg} routine
8261 (new as of @code{egcs} version 1.1 and @code{g77} version 0.5.23)
8262 must be called with the appropriate @code{argc} and @code{argv} arguments
8263 prior to the program calling @code{GETARG} or @code{IARGC}.
8265 To provide more flexibility for mixed-language programming
8266 involving @code{g77} while allowing for shared libraries,
8267 as of @code{egcs} version 1.1 and @code{g77} version 0.5.23,
8268 @code{g77}'s @code{main} routine in @code{libg2c}
8269 does the following, in order:
8273 Calls @code{f_setarg}
8274 with the incoming @code{argc} and @code{argv} arguments,
8275 in the same order as for @code{main} itself.
8277 This sets up the command-line environment
8278 for @code{GETARG} and @code{IARGC}.
8281 Calls @code{f_setsig} (with no arguments).
8283 This sets up the signaling and exception environment.
8286 Calls @code{f_init} (with no arguments).
8288 This initializes the I/O environment,
8289 though that should not be necessary,
8290 as all I/O functions in @code{libf2c}
8291 are believed to call @code{f_init} automatically,
8294 (A future version of @code{g77} might skip this explicit step,
8295 to speed up normal exit of a program.)
8298 Arranges for @code{f_exit} to be called (with no arguments)
8299 when the program exits.
8301 This ensures that the I/O environment is properly shut down
8302 before the program exits normally.
8303 Otherwise, output buffers might not be fully flushed,
8304 scratch files might not be deleted, and so on.
8306 The simple way @code{main} does this is
8307 to call @code{f_exit} itself after calling
8308 @code{MAIN__} (in the next step).
8310 However, this does not catch the cases where the program
8311 might call @code{exit} directly,
8312 instead of using the @code{EXIT} intrinsic
8313 (implemented as @code{exit_} in @code{libf2c}).
8315 So, @code{main} attempts to use
8316 the operating environment's @code{onexit} or @code{atexit}
8317 facility, if available,
8318 to cause @code{f_exit} to be called automatically
8319 upon any invocation of @code{exit}.
8322 Calls @code{MAIN__} (with no arguments).
8324 This starts executing the Fortran main program unit for
8326 (Both @code{g77} and @code{f2c} currently compile a main
8327 program unit so that its global name is @code{MAIN__}.)
8330 If no @code{onexit} or @code{atexit} is provided by the system,
8331 calls @code{f_exit}.
8334 Calls @code{exit} with a zero argument,
8335 to signal a successful program termination.
8338 Returns a zero value to the caller,
8339 to signal a successful program termination,
8340 in case @code{exit} doesn't exit on the system.
8343 All of the above names are C @code{extern} names,
8346 When using the @code{main} procedure provided by @code{g77}
8347 without a Fortran main program unit,
8348 you need to provide @code{MAIN__}
8349 as the entry point for your C code.
8350 (Make sure you link the object file that defines that
8351 entry point with the rest of your program.)
8353 To provide your own @code{main} procedure
8354 in place of @code{g77}'s,
8355 make sure you specify the object file defining that procedure
8356 @emph{before} @samp{-lg2c} on the @code{g77} command line.
8357 Since the @samp{-lg2c} option is implicitly provided,
8358 this is usually straightforward.
8359 (Use the @samp{--verbose} option to see how and where
8360 @code{g77} implicitly adds @samp{-lg2c} in a command line
8361 that will link the program.
8362 Feel free to specify @samp{-lg2c} explicitly,
8365 However, when providing your own @code{main},
8366 make sure you perform the appropriate tasks in the
8368 For example, if your @code{main} does not call @code{f_setarg},
8369 make sure the rest of your application does not call
8370 @code{GETARG} or @code{IARGC}.
8372 And, if your @code{main} fails to ensure that @code{f_exit}
8373 is called upon program exit,
8374 some files might end up incompletely written,
8375 some scratch files might be left lying around,
8376 and some existing files being written might be left
8377 with old data not properly truncated at the end.
8379 Note that, generally, the @code{g77} operating environment
8380 does not depend on a procedure named @code{MAIN__} actually
8381 being called prior to any other @code{g77}-compiled code.
8382 That is, @code{MAIN__} does not, itself,
8383 set up any important operating-environment characteristics
8384 upon which other code might depend.
8385 This might change in future versions of @code{g77},
8386 with appropriate notification in the release notes.
8388 For more information, consult the source code for the above routines.
8389 These are in @file{@value{path-libf2c}/libF77/}, named @file{main.c},
8390 @file{setarg.c}, @file{setsig.c}, @file{getarg_.c}, and @file{iargc_.c}.
8392 Also, the file @file{@value{path-g77}/com.c} contains the code @code{g77}
8393 uses to open-code (inline) references to @code{IARGC}.
8395 @include g77install.texi
8397 @node Debugging and Interfacing
8398 @chapter Debugging and Interfacing
8401 @cindex calling C routines
8402 @cindex C routines calling Fortran
8403 @cindex f2c compatibility
8405 GNU Fortran currently generates code that is object-compatible with
8406 the @code{f2c} converter.
8407 Also, it avoids limitations in the current GBE, such as the
8408 inability to generate a procedure with
8409 multiple entry points, by generating code that is structured
8410 differently (in terms of procedure names, scopes, arguments, and
8411 so on) than might be expected.
8413 As a result, writing code in other languages that calls on, is
8414 called by, or shares in-memory data with @code{g77}-compiled code generally
8415 requires some understanding of the way @code{g77} compiles code for
8418 Similarly, using a debugger to debug @code{g77}-compiled
8419 code, even if that debugger supports native Fortran debugging, generally
8420 requires this sort of information.
8422 This section describes some of the basic information on how
8423 @code{g77} compiles code for constructs involving interfaces to other
8424 languages and to debuggers.
8426 @emph{Caution:} Much or all of this information pertains to only the current
8427 release of @code{g77}, sometimes even to using certain compiler options
8428 with @code{g77} (such as @samp{-fno-f2c}).
8429 Do not write code that depends on this
8430 information without clearly marking said code as nonportable and
8431 subject to review for every new release of @code{g77}.
8433 is provided primarily to make debugging of code generated by this
8434 particular release of @code{g77} easier for the user, and partly to make
8435 writing (generally nonportable) interface code easier.
8437 activities require tracking changes in new version of @code{g77} as they
8438 are installed, because new versions can change the behaviors
8439 described in this section.
8442 * Main Program Unit:: How @code{g77} compiles a main program unit.
8443 * Procedures:: How @code{g77} constructs parameter lists
8445 * Functions:: Functions returning floating-point or character data.
8446 * Names:: Naming of user-defined variables, procedures, etc.
8447 * Common Blocks:: Accessing common variables while debugging.
8448 * Local Equivalence Areas:: Accessing @code{EQUIVALENCE} while debugging.
8449 * Complex Variables:: How @code{g77} performs complex arithmetic.
8450 * Arrays:: Dealing with (possibly multi-dimensional) arrays.
8451 * Adjustable Arrays:: Special consideration for adjustable arrays.
8452 * Alternate Entry Points:: How @code{g77} implements alternate @code{ENTRY}.
8453 * Alternate Returns:: How @code{g77} handles alternate returns.
8454 * Assigned Statement Labels:: How @code{g77} handles @code{ASSIGN}.
8455 * Run-time Library Errors:: Meanings of some @code{IOSTAT=} values.
8458 @node Main Program Unit
8459 @section Main Program Unit (PROGRAM)
8460 @cindex PROGRAM statement
8461 @cindex statements, PROGRAM
8463 When @code{g77} compiles a main program unit, it gives it the public
8464 procedure name @samp{MAIN__}.
8465 The @code{libg2c} library has the actual @code{main()} procedure
8466 as is typical of C-based environments, and
8467 it is this procedure that performs some initial start-up
8468 activity and then calls @samp{MAIN__}.
8470 Generally, @code{g77} and @code{libg2c} are designed so that you need not
8471 include a main program unit written in Fortran in your program---it
8472 can be written in C or some other language.
8473 Especially for I/O handling, this is the case, although @code{g77} version 0.5.16
8474 includes a bug fix for @code{libg2c} that solved a problem with using the
8475 @code{OPEN} statement as the first Fortran I/O activity in a program
8476 without a Fortran main program unit.
8478 However, if you don't intend to use @code{g77} (or @code{f2c}) to compile
8479 your main program unit---that is, if you intend to compile a @code{main()}
8480 procedure using some other language---you should carefully
8481 examine the code for @code{main()} in @code{libg2c}, found in the source
8482 file @file{@value{path-libf2c}/libF77/main.c}, to see what kinds of things
8483 might need to be done by your @code{main()} in order to provide the
8484 Fortran environment your Fortran code is expecting.
8486 @cindex @code{IArgC} intrinsic
8487 @cindex intrinsics, @code{IArgC}
8488 @cindex @code{GetArg} intrinsic
8489 @cindex intrinsics, @code{GetArg}
8490 For example, @code{libg2c}'s @code{main()} sets up the information used by
8491 the @code{IARGC} and @code{GETARG} intrinsics.
8492 Bypassing @code{libg2c}'s @code{main()}
8493 without providing a substitute for this activity would mean
8494 that invoking @code{IARGC} and @code{GETARG} would produce undefined
8498 @cindex main program unit, debugging
8502 When debugging, one implication of the fact that @code{main()}, which
8503 is the place where the debugged program ``starts'' from the
8504 debugger's point of view, is in @code{libg2c} is that you won't be
8505 starting your Fortran program at a point you recognize as your
8508 The standard way to get around this problem is to set a break
8509 point (a one-time, or temporary, break point will do) at
8510 the entrance to @samp{MAIN__}, and then run the program.
8511 A convenient way to do so is to add the @code{gdb} command
8518 to the file @file{.gdbinit} in the directory in which you're debugging
8521 After doing this, the debugger will see the current execution
8522 point of the program as at the beginning of the main program
8523 unit of your program.
8525 Of course, if you really want to set a break point at some
8526 other place in your program and just start the program
8527 running, without first breaking at @samp{MAIN__},
8528 that should work fine.
8531 @section Procedures (SUBROUTINE and FUNCTION)
8533 @cindex SUBROUTINE statement
8534 @cindex statements, SUBROUTINE
8535 @cindex FUNCTION statement
8536 @cindex statements, FUNCTION
8537 @cindex signature of procedures
8539 Currently, @code{g77} passes arguments via reference---specifically,
8540 by passing a pointer to the location in memory of a variable, array,
8541 array element, a temporary location that holds the result of evaluating an
8542 expression, or a temporary or permanent location that holds the value
8545 Procedures that accept @code{CHARACTER} arguments are implemented by
8546 @code{g77} so that each @code{CHARACTER} argument has two actual arguments.
8548 The first argument occupies the expected position in the
8549 argument list and has the user-specified name.
8551 is a pointer to an array of characters, passed by the caller.
8553 The second argument is appended to the end of the user-specified
8554 calling sequence and is named @samp{__g77_length_@var{x}}, where @var{x}
8555 is the user-specified name.
8556 This argument is of the C type @code{ftnlen}
8557 (see @file{@value{path-libf2c}/g2c.h.in} for information on that type) and
8558 is the number of characters the caller has allocated in the
8559 array pointed to by the first argument.
8561 A procedure will ignore the length argument if @samp{X} is not declared
8562 @code{CHARACTER*(*)}, because for other declarations, it knows the
8564 Not all callers necessarily ``know'' this, however, which
8565 is why they all pass the extra argument.
8567 The contents of the @code{CHARACTER} argument are specified by the
8568 address passed in the first argument (named after it).
8569 The procedure can read or write these contents as appropriate.
8571 When more than one @code{CHARACTER} argument is present in the argument
8572 list, the length arguments are appended in the order
8573 the original arguments appear.
8574 So @samp{CALL FOO('HI','THERE')} is implemented in
8575 C as @samp{foo("hi","there",2,5);}, ignoring the fact that @code{g77}
8576 does not provide the trailing null bytes on the constant
8577 strings (@code{f2c} does provide them, but they are unnecessary in
8578 a Fortran environment, and you should not expect them to be
8581 Note that the above information applies to @code{CHARACTER} variables and
8582 arrays @strong{only}.
8583 It does @strong{not} apply to external @code{CHARACTER}
8584 functions or to intrinsic @code{CHARACTER} functions.
8585 That is, no second length argument is passed to @samp{FOO} in this case:
8594 Nor does @samp{FOO} expect such an argument in this case:
8602 Because of this implementation detail, if a program has a bug
8603 such that there is disagreement as to whether an argument is
8604 a procedure, and the type of the argument is @code{CHARACTER}, subtle
8605 symptoms might appear.
8608 @section Functions (FUNCTION and RETURN)
8610 @cindex FUNCTION statement
8611 @cindex statements, FUNCTION
8612 @cindex RETURN statement
8613 @cindex statements, RETURN
8614 @cindex return type of functions
8616 @code{g77} handles in a special way functions that return the following
8628 For @code{CHARACTER}, @code{g77} implements a subroutine (a C function
8629 returning @code{void})
8630 with two arguments prepended: @samp{__g77_result}, which the caller passes
8631 as a pointer to a @code{char} array expected to hold the return value,
8632 and @samp{__g77_length}, which the caller passes as an @code{ftnlen} value
8633 specifying the length of the return value as declared in the calling
8635 For @code{CHARACTER*(*)}, the called function uses @samp{__g77_length}
8636 to determine the size of the array that @samp{__g77_result} points to;
8637 otherwise, it ignores that argument.
8639 For @code{COMPLEX}, when @samp{-ff2c} is in
8640 force, @code{g77} implements
8641 a subroutine with one argument prepended: @samp{__g77_result}, which the
8642 caller passes as a pointer to a variable of the type of the function.
8643 The called function writes the return value into this variable instead
8644 of returning it as a function value.
8645 When @samp{-fno-f2c} is in force,
8646 @code{g77} implements a @code{COMPLEX} function as @code{gcc}'s
8647 @samp{__complex__ float} or @samp{__complex__ double} function
8648 (or an emulation thereof, when @samp{-femulate-complex} is in effect),
8649 returning the result of the function in the same way as @code{gcc} would.
8651 For @code{REAL(KIND=1)}, when @samp{-ff2c} is in force, @code{g77} implements
8652 a function that actually returns @code{REAL(KIND=2)} (typically
8653 C's @code{double} type).
8654 When @samp{-fno-f2c} is in force, @code{REAL(KIND=1)}
8655 functions return @code{float}.
8659 @cindex symbol names
8660 @cindex transforming symbol names
8662 Fortran permits each implementation to decide how to represent
8663 names as far as how they're seen in other contexts, such as debuggers
8664 and when interfacing to other languages, and especially as far
8665 as how casing is handled.
8667 External names---names of entities that are public, or ``accessible'',
8668 to all modules in a program---normally have an underscore (@samp{_})
8669 appended by @code{g77},
8670 to generate code that is compatible with @code{f2c}.
8671 External names include names of Fortran things like common blocks,
8672 external procedures (subroutines and functions, but not including
8673 statement functions, which are internal procedures), and entry point
8676 However, use of the @samp{-fno-underscoring} option
8677 disables this kind of transformation of external names (though inhibiting
8678 the transformation certainly improves the chances of colliding with
8679 incompatible externals written in other languages---but that
8680 might be intentional.
8682 @cindex -fno-underscoring option
8683 @cindex options, -fno-underscoring
8684 @cindex -fno-second-underscore option
8685 @cindex options, -fno-underscoring
8686 When @samp{-funderscoring} is in force, any name (external or local)
8687 that already has at least one underscore in it is
8688 implemented by @code{g77} by appending two underscores.
8689 (This second underscore can be disabled via the
8690 @samp{-fno-second-underscore} option.)
8691 External names are changed this way for @code{f2c} compatibility.
8692 Local names are changed this way to avoid collisions with external names
8693 that are different in the source code---@code{f2c} does the same thing, but
8694 there's no compatibility issue there except for user expectations while
8705 Here, a user would, in the debugger, refer to this variable using the
8706 name @samp{max_cost__} (or @samp{MAX_COST__} or @samp{Max_Cost__},
8707 as described below).
8708 (We hope to improve @code{g77} in this regard in the future---don't
8709 write scripts depending on this behavior!
8710 Also, consider experimenting with the @samp{-fno-underscoring}
8711 option to try out debugging without having to massage names by
8714 @code{g77} provides a number of command-line options that allow the user
8715 to control how case mapping is handled for source files.
8716 The default is the traditional UNIX model for Fortran compilers---names
8717 are mapped to lower case.
8718 Other command-line options can be specified to map names to upper
8719 case, or to leave them exactly as written in the source file.
8728 Here, it is normally the case that the variable assigned will be named
8730 This would be the name to enter when using a debugger to
8731 access the variable.
8733 However, depending on the command-line options specified, the
8734 name implemented by @code{g77} might instead be @samp{FOO} or even
8735 @samp{Foo}, thus affecting how debugging is done.
8744 This would normally call a procedure that, if it were in a separate C program,
8745 be defined starting with the line:
8752 However, @code{g77} command-line options could be used to change the casing
8753 of names, resulting in the name @samp{FOO_} or @samp{Foo_} being given to the
8754 procedure instead of @samp{foo_}, and the @samp{-fno-underscoring} option
8755 could be used to inhibit the appending of the underscore to the name.
8758 @section Common Blocks (COMMON)
8759 @cindex common blocks
8760 @cindex @code{COMMON} statement
8761 @cindex statements, @code{COMMON}
8763 @code{g77} names and lays out @code{COMMON} areas
8764 the same way @code{f2c} does,
8765 for compatibility with @code{f2c}.
8767 Currently, @code{g77} does not emit ``true'' debugging information for
8768 members of a @code{COMMON} area, due to an apparent bug in the GBE.
8770 (As of Version 0.5.19, @code{g77} emits debugging information for such
8771 members in the form of a constant string specifying the base name of
8772 the aggregate area and the offset of the member in bytes from the start
8774 Use the @samp{-fdebug-kludge} option to enable this behavior.
8775 In @code{gdb}, use @samp{set language c} before printing the value
8776 of the member, then @samp{set language fortran} to restore the default
8777 language, since @code{gdb} doesn't provide a way to print a readable
8778 version of a character string in Fortran language mode.
8780 This kludge will be removed in a future version of @code{g77} that,
8781 in conjunction with a contemporary version of @code{gdb},
8782 properly supports Fortran-language debugging, including access
8783 to members of @code{COMMON} areas.)
8785 @xref{Code Gen Options,,Options for Code Generation Conventions},
8786 for information on the @samp{-fdebug-kludge} option.
8788 Moreover, @code{g77} currently implements a @code{COMMON} area such that its
8789 type is an array of the C @code{char} data type.
8791 So, when debugging, you must know the offset into a @code{COMMON} area
8792 for a particular item in that area, and you have to take into
8793 account the appropriate multiplier for the respective sizes
8794 of the types (as declared in your code) for the items preceding
8795 the item in question as compared to the size of the @code{char} type.
8797 For example, using default implicit typing, the statement
8800 COMMON I(15), R(20), T
8804 results in a public 144-byte @code{char} array named @samp{_BLNK__}
8805 with @samp{I} placed at @samp{_BLNK__[0]}, @samp{R} at @samp{_BLNK__[60]},
8806 and @samp{T} at @samp{_BLNK__[140]}.
8807 (This is assuming that the target machine for
8808 the compilation has 4-byte @code{INTEGER(KIND=1)} and @code{REAL(KIND=1)}
8811 @node Local Equivalence Areas
8812 @section Local Equivalence Areas (EQUIVALENCE)
8813 @cindex equivalence areas
8814 @cindex local equivalence areas
8815 @cindex EQUIVALENCE statement
8816 @cindex statements, EQUIVALENCE
8818 @code{g77} treats storage-associated areas involving a @code{COMMON}
8819 block as explained in the section on common blocks.
8821 A local @code{EQUIVALENCE} area is a collection of variables and arrays
8822 connected to each other in any way via @code{EQUIVALENCE}, none of which are
8823 listed in a @code{COMMON} statement.
8825 Currently, @code{g77} does not emit ``true'' debugging information for
8826 members in a local @code{EQUIVALENCE} area, due to an apparent bug in the GBE.
8828 (As of Version 0.5.19, @code{g77} does emit debugging information for such
8829 members in the form of a constant string specifying the base name of
8830 the aggregate area and the offset of the member in bytes from the start
8832 Use the @samp{-fdebug-kludge} option to enable this behavior.
8833 In @code{gdb}, use @samp{set language c} before printing the value
8834 of the member, then @samp{set language fortran} to restore the default
8835 language, since @code{gdb} doesn't provide a way to print a readable
8836 version of a character string in Fortran language mode.
8838 This kludge will be removed in a future version of @code{g77} that,
8839 in conjunction with a contemporary version of @code{gdb},
8840 properly supports Fortran-language debugging, including access
8841 to members of @code{EQUIVALENCE} areas.)
8843 @xref{Code Gen Options,,Options for Code Generation Conventions},
8844 for information on the @samp{-fdebug-kludge} option.
8846 Moreover, @code{g77} implements a local @code{EQUIVALENCE} area such that its
8847 type is an array of the C @code{char} data type.
8849 The name @code{g77} gives this array of @code{char} type is @samp{__g77_equiv_@var{x}},
8850 where @var{x} is the name of the item that is placed at the beginning (offset 0)
8852 If more than one such item is placed at the beginning, @var{x} is
8853 the name that sorts to the top in an alphabetical sort of the list of
8856 When debugging, you must therefore access members of @code{EQUIVALENCE}
8857 areas by specifying the appropriate @samp{__g77_equiv_@var{x}}
8858 array section with the appropriate offset.
8859 See the explanation of debugging @code{COMMON} blocks
8860 for info applicable to debugging local @code{EQUIVALENCE} areas.
8862 (@emph{Note:} @code{g77} version 0.5.18 and earlier chose the name
8863 for @var{x} using a different method when more than one name was
8864 in the list of names of entities placed at the beginning of the
8866 Though the documentation specified that the first name listed in
8867 the @code{EQUIVALENCE} statements was chosen for @var{x}, @code{g77}
8868 in fact chose the name using a method that was so complicated,
8869 it seemed easier to change it to an alphabetical sort than to describe the
8870 previous method in the documentation.)
8872 @node Complex Variables
8873 @section Complex Variables (COMPLEX)
8874 @cindex complex variables
8875 @cindex imaginary part
8876 @cindex COMPLEX statement
8877 @cindex statements, COMPLEX
8879 As of 0.5.20, @code{g77} defaults to handling @code{COMPLEX} types
8880 (and related intrinsics, constants, functions, and so on)
8882 makes direct debugging involving these types in Fortran
8883 language mode difficult.
8885 Essentially, @code{g77} implements these types using an
8886 internal construct similar to C's @code{struct}, at least
8887 as seen by the @code{gcc} back end.
8889 Currently, the back end, when outputting debugging info with
8890 the compiled code for the assembler to digest, does not detect
8891 these @code{struct} types as being substitutes for Fortran
8893 As a result, the Fortran language modes of debuggers such as
8894 @code{gdb} see these types as C @code{struct} types, which
8895 they might or might not support.
8897 Until this is fixed, switch to C language mode to work with
8898 entities of @code{COMPLEX} type and then switch back to Fortran language
8900 (In @code{gdb}, this is accomplished via @samp{set lang c} and
8901 either @samp{set lang fortran} or @samp{set lang auto}.)
8904 @section Arrays (DIMENSION)
8905 @cindex DIMENSION statement
8906 @cindex statements, DIMENSION
8907 @cindex array ordering
8908 @cindex ordering, array
8909 @cindex column-major ordering
8910 @cindex row-major ordering
8913 Fortran uses ``column-major ordering'' in its arrays.
8914 This differs from other languages, such as C, which use ``row-major ordering''.
8915 The difference is that, with Fortran, array elements adjacent to
8916 each other in memory differ in the @emph{first} subscript instead of
8917 the last; @samp{A(5,10,20)} immediately follows @samp{A(4,10,20)},
8918 whereas with row-major ordering it would follow @samp{A(5,10,19)}.
8921 affects not only interfacing with and debugging Fortran code,
8922 it can greatly affect how code is designed and written, especially
8923 when code speed and size is a concern.
8925 Fortran also differs from C, a popular language for interfacing and
8926 to support directly in debuggers, in the way arrays are treated.
8927 In C, arrays are single-dimensional and have interesting relationships
8928 to pointers, neither of which is true for Fortran.
8929 As a result, dealing with Fortran arrays from within
8930 an environment limited to C concepts can be challenging.
8932 For example, accessing the array element @samp{A(5,10,20)} is easy enough
8933 in Fortran (use @samp{A(5,10,20)}), but in C some difficult machinations
8935 First, C would treat the A array as a single-dimension array.
8936 Second, C does not understand low bounds for arrays as does Fortran.
8937 Third, C assumes a low bound of zero (0), while Fortran defaults to a
8938 low bound of one (1) and can supports an arbitrary low bound.
8939 Therefore, calculations must be done
8940 to determine what the C equivalent of @samp{A(5,10,20)} would be, and these
8941 calculations require knowing the dimensions of @samp{A}.
8943 For @samp{DIMENSION A(2:11,21,0:29)}, the calculation of the offset of
8944 @samp{A(5,10,20)} would be:
8949 + (20-0)*(11-2+1)*(21-1+1)
8954 So the C equivalent in this case would be @samp{a[4293]}.
8956 When using a debugger directly on Fortran code, the C equivalent
8957 might not work, because some debuggers cannot understand the notion
8958 of low bounds other than zero. However, unlike @code{f2c}, @code{g77}
8959 does inform the GBE that a multi-dimensional array (like @samp{A}
8960 in the above example) is really multi-dimensional, rather than a
8961 single-dimensional array, so at least the dimensionality of the array
8964 Debuggers that understand Fortran should have no trouble with
8965 non-zero low bounds, but for non-Fortran debuggers, especially
8966 C debuggers, the above example might have a C equivalent of
8968 This calculation is arrived at by eliminating the subtraction
8969 of the lower bound in the first parenthesized expression on each
8970 line---that is, for @samp{(5-2)} substitute @samp{(5)}, for @samp{(10-1)}
8971 substitute @samp{(10)}, and for @samp{(20-0)} substitute @samp{(20)}.
8972 Actually, the implication of
8973 this can be that the expression @samp{*(&a[2][1][0] + 4293)} works fine,
8974 but that @samp{a[20][10][5]} produces the equivalent of
8975 @samp{*(&a[0][0][0] + 4305)} because of the missing lower bounds.
8977 Come to think of it, perhaps
8978 the behavior is due to the debugger internally compensating for
8979 the lower bounds by offsetting the base address of @samp{a}, leaving
8980 @samp{&a} set lower, in this case, than @samp{&a[2][1][0]} (the address of
8981 its first element as identified by subscripts equal to the
8982 corresponding lower bounds).
8984 You know, maybe nobody really needs to use arrays.
8986 @node Adjustable Arrays
8987 @section Adjustable Arrays (DIMENSION)
8988 @cindex arrays, adjustable
8989 @cindex adjustable arrays
8990 @cindex arrays, automatic
8991 @cindex automatic arrays
8992 @cindex DIMENSION statement
8993 @cindex statements, DIMENSION
8994 @cindex dimensioning arrays
8995 @cindex arrays, dimensioning
8997 Adjustable and automatic arrays in Fortran require the implementation
8999 case, the @code{g77} compiler) to ``memorize'' the expressions that
9000 dimension the arrays each time the procedure is invoked.
9001 This is so that subsequent changes to variables used in those
9002 expressions, made during execution of the procedure, do not
9003 have any effect on the dimensions of those arrays.
9020 Here, the implementation should, when running the program, print something
9028 Note that this shows that while the value of @samp{N} was successfully
9029 changed, the size of the @samp{A} array remained at 5 elements.
9031 To support this, @code{g77} generates code that executes before any user
9032 code (and before the internally generated computed @code{GOTO} to handle
9033 alternate entry points, as described below) that evaluates each
9034 (nonconstant) expression in the list of subscripts for an
9035 array, and saves the result of each such evaluation to be used when
9036 determining the size of the array (instead of re-evaluating the
9039 So, in the above example, when @samp{X} is first invoked, code is
9040 executed that copies the value of @samp{N} to a temporary.
9041 And that same temporary serves as the actual high bound for the single
9042 dimension of the @samp{A} array (the low bound being the constant 1).
9043 Since the user program cannot (legitimately) change the value
9044 of the temporary during execution of the procedure, the size
9045 of the array remains constant during each invocation.
9047 For alternate entry points, the code @code{g77} generates takes into
9048 account the possibility that a dummy adjustable array is not actually
9049 passed to the actual entry point being invoked at that time.
9050 In that case, the public procedure implementing the entry point
9051 passes to the master private procedure implementing all the
9052 code for the entry points a @code{NULL} pointer where a pointer to that
9053 adjustable array would be expected.
9054 The @code{g77}-generated code
9055 doesn't attempt to evaluate any of the expressions in the subscripts
9056 for an array if the pointer to that array is @code{NULL} at run time in
9058 (Don't depend on this particular implementation
9059 by writing code that purposely passes @code{NULL} pointers where the
9060 callee expects adjustable arrays, even if you know the callee
9061 won't reference the arrays---nor should you pass @code{NULL} pointers
9062 for any dummy arguments used in calculating the bounds of such
9063 arrays or leave undefined any values used for that purpose in
9064 COMMON---because the way @code{g77} implements these things might
9065 change in the future!)
9067 @node Alternate Entry Points
9068 @section Alternate Entry Points (ENTRY)
9069 @cindex alternate entry points
9070 @cindex entry points
9071 @cindex ENTRY statement
9072 @cindex statements, ENTRY
9074 The GBE does not understand the general concept of
9075 alternate entry points as Fortran provides via the ENTRY statement.
9076 @code{g77} gets around this by using an approach to compiling procedures
9077 having at least one @code{ENTRY} statement that is almost identical to the
9078 approach used by @code{f2c}.
9079 (An alternate approach could be used that
9080 would probably generate faster, but larger, code that would also
9081 be a bit easier to debug.)
9083 Information on how @code{g77} implements @code{ENTRY} is provided for those
9084 trying to debug such code.
9085 The choice of implementation seems
9086 unlikely to affect code (compiled in other languages) that interfaces
9089 @code{g77} compiles exactly one public procedure for the primary entry
9090 point of a procedure plus each @code{ENTRY} point it specifies, as usual.
9091 That is, in terms of the public interface, there is no difference
9110 The difference between the above two cases lies in the code compiled
9111 for the @samp{X} and @samp{Y} procedures themselves, plus the fact that,
9112 for the second case, an extra internal procedure is compiled.
9114 For every Fortran procedure with at least one @code{ENTRY}
9115 statement, @code{g77} compiles an extra procedure
9116 named @samp{__g77_masterfun_@var{x}}, where @var{x} is
9117 the name of the primary entry point (which, in the above case,
9118 using the standard compiler options, would be @samp{x_} in C).
9120 This extra procedure is compiled as a private procedure---that is,
9121 a procedure not accessible by name to separately compiled modules.
9122 It contains all the code in the program unit, including the code
9123 for the primary entry point plus for every entry point.
9124 (The code for each public procedure is quite short, and explained later.)
9126 The extra procedure has some other interesting characteristics.
9128 The argument list for this procedure is invented by @code{g77}.
9130 a single integer argument named @samp{__g77_which_entrypoint},
9131 passed by value (as in Fortran's @samp{%VAL()} intrinsic), specifying the
9132 entry point index---0 for the primary entry point, 1 for the
9133 first entry point (the first @code{ENTRY} statement encountered), 2 for
9134 the second entry point, and so on.
9136 It also contains, for functions returning @code{CHARACTER} and
9137 (when @samp{-ff2c} is in effect) @code{COMPLEX} functions,
9138 and for functions returning different types among the
9139 @code{ENTRY} statements (e.g. @samp{REAL FUNCTION R()}
9140 containing @samp{ENTRY I()}), an argument named @samp{__g77_result} that
9141 is expected at run time to contain a pointer to where to store
9142 the result of the entry point.
9143 For @code{CHARACTER} functions, this
9144 storage area is an array of the appropriate number of characters;
9145 for @code{COMPLEX} functions, it is the appropriate area for the return
9146 type; for multiple-return-type functions, it is a union of all the supported return
9147 types (which cannot include @code{CHARACTER}, since combining @code{CHARACTER}
9148 and non-@code{CHARACTER} return types via @code{ENTRY} in a single function
9149 is not supported by @code{g77}).
9151 For @code{CHARACTER} functions, the @samp{__g77_result} argument is followed
9152 by yet another argument named @samp{__g77_length} that, at run time,
9153 specifies the caller's expected length of the returned value.
9154 Note that only @code{CHARACTER*(*)} functions and entry points actually
9155 make use of this argument, even though it is always passed by
9156 all callers of public @code{CHARACTER} functions (since the caller does not
9157 generally know whether such a function is @code{CHARACTER*(*)} or whether
9158 there are any other callers that don't have that information).
9160 The rest of the argument list is the union of all the arguments
9161 specified for all the entry points (in their usual forms, e.g.
9162 @code{CHARACTER} arguments have extra length arguments, all appended at
9163 the end of this list).
9164 This is considered the ``master list'' of
9167 The code for this procedure has, before the code for the first
9168 executable statement, code much like that for the following Fortran
9172 GOTO (100000,100001,100002), __g77_which_entrypoint
9173 100000 @dots{}code for primary entry point@dots{}
9174 100001 @dots{}code immediately following first ENTRY statement@dots{}
9175 100002 @dots{}code immediately following second ENTRY statement@dots{}
9179 (Note that invalid Fortran statement labels and variable names
9180 are used in the above example to highlight the fact that it
9181 represents code generated by the @code{g77} internals, not code to be
9182 written by the user.)
9184 It is this code that, when the procedure is called, picks which
9185 entry point to start executing.
9187 Getting back to the public procedures (@samp{x} and @samp{Y} in the original
9188 example), those procedures are fairly simple.
9190 are just like they would be if they were self-contained procedures
9191 (without @code{ENTRY}), of course, since that is what the callers
9193 Their code consists of simply calling the private
9194 procedure, described above, with the appropriate extra arguments
9195 (the entry point index, and perhaps a pointer to a multiple-type-
9196 return variable, local to the public procedure, that contains
9197 all the supported returnable non-character types).
9199 that are not listed for a given entry point that are listed for
9200 other entry points, and therefore that are in the ``master list''
9201 for the private procedure, null pointers (in C, the @code{NULL} macro)
9203 Also, for entry points that are part of a multiple-type-
9204 returning function, code is compiled after the call of the private
9205 procedure to extract from the multi-type union the appropriate result,
9206 depending on the type of the entry point in question, returning
9207 that result to the original caller.
9209 When debugging a procedure containing alternate entry points, you
9210 can either set a break point on the public procedure itself (e.g.
9211 a break point on @samp{X} or @samp{Y}) or on the private procedure that
9212 contains most of the pertinent code (e.g. @samp{__g77_masterfun_@var{x}}).
9213 If you do the former, you should use the debugger's command to
9214 ``step into'' the called procedure to get to the actual code; with
9215 the latter approach, the break point leaves you right at the
9216 actual code, skipping over the public entry point and its call
9217 to the private procedure (unless you have set a break point there
9218 as well, of course).
9220 Further, the list of dummy arguments that is visible when the
9221 private procedure is active is going to be the expanded version
9222 of the list for whichever particular entry point is active,
9223 as explained above, and the way in which return values are
9224 handled might well be different from how they would be handled
9225 for an equivalent single-entry function.
9227 @node Alternate Returns
9228 @section Alternate Returns (SUBROUTINE and RETURN)
9230 @cindex alternate returns
9231 @cindex SUBROUTINE statement
9232 @cindex statements, SUBROUTINE
9233 @cindex RETURN statement
9234 @cindex statements, RETURN
9236 Subroutines with alternate returns (e.g. @samp{SUBROUTINE X(*)} and
9237 @samp{CALL X(*50)}) are implemented by @code{g77} as functions returning
9238 the C @code{int} type.
9239 The actual alternate-return arguments are omitted from the calling sequence.
9240 Instead, the caller uses
9241 the return value to do a rough equivalent of the Fortran
9242 computed-@code{GOTO} statement, as in @samp{GOTO (50), X()} in the
9243 example above (where @samp{X} is quietly declared as an @code{INTEGER(KIND=1)}
9244 function), and the callee just returns whatever integer
9245 is specified in the @code{RETURN} statement for the subroutine
9246 For example, @samp{RETURN 1} is implemented as @samp{X = 1} followed
9248 in C, and @samp{RETURN} by itself is @samp{X = 0} and @samp{RETURN}).
9250 @node Assigned Statement Labels
9251 @section Assigned Statement Labels (ASSIGN and GOTO)
9252 @cindex assigned statement labels
9253 @cindex statement labels, assigned
9254 @cindex ASSIGN statement
9255 @cindex statements, ASSIGN
9256 @cindex GOTO statement
9257 @cindex statements, GOTO
9259 For portability to machines where a pointer (such as to a label,
9260 which is how @code{g77} implements @code{ASSIGN} and its relatives,
9261 the assigned-@code{GOTO} and assigned-@code{FORMAT}-I/O statements)
9262 is wider (bitwise) than an @code{INTEGER(KIND=1)}, @code{g77}
9263 uses a different memory location to hold the @code{ASSIGN}ed value of a variable
9264 than it does the numerical value in that variable, unless the
9265 variable is wide enough (can hold enough bits).
9267 In particular, while @code{g77} implements
9274 as, in C notation, @samp{i = 10;}, it implements
9281 as, in GNU's extended C notation (for the label syntax),
9282 @samp{__g77_ASSIGN_I = &&L10;} (where @samp{L10} is just a massaging
9283 of the Fortran label @samp{10} to make the syntax C-like; @code{g77} doesn't
9284 actually generate the name @samp{L10} or any other name like that,
9285 since debuggers cannot access labels anyway).
9287 While this currently means that an @code{ASSIGN} statement does not
9288 overwrite the numeric contents of its target variable, @emph{do not}
9289 write any code depending on this feature.
9290 @code{g77} has already changed this implementation across
9291 versions and might do so in the future.
9292 This information is provided only to make debugging Fortran programs
9293 compiled with the current version of @code{g77} somewhat easier.
9294 If there's no debugger-visible variable named @samp{__g77_ASSIGN_I}
9295 in a program unit that does @samp{ASSIGN 10 TO I}, that probably
9296 means @code{g77} has decided it can store the pointer to the label directly
9297 into @samp{I} itself.
9299 @xref{Ugly Assigned Labels}, for information on a command-line option
9300 to force @code{g77} to use the same storage for both normal and
9301 assigned-label uses of a variable.
9303 @node Run-time Library Errors
9304 @section Run-time Library Errors
9306 @cindex error values
9307 @cindex error messages
9308 @cindex messages, run-time
9311 The @code{libg2c} library currently has the following table to relate
9312 error code numbers, returned in @code{IOSTAT=} variables, to messages.
9313 This information should, in future versions of this document, be
9314 expanded upon to include detailed descriptions of each message.
9316 In line with good coding practices, any of the numbers in the
9317 list below should @emph{not} be directly written into Fortran
9319 Instead, make a separate @code{INCLUDE} file that defines
9320 @code{PARAMETER} names for them, and use those in your code,
9321 so you can more easily change the actual numbers in the future.
9323 The information below is culled from the definition
9324 of @samp{F_err} in @file{f/runtime/libI77/err.c} in the
9325 @code{g77} source tree.
9328 100: "error in format"
9329 101: "illegal unit number"
9330 102: "formatted io not allowed"
9331 103: "unformatted io not allowed"
9332 104: "direct io not allowed"
9333 105: "sequential io not allowed"
9334 106: "can't backspace file"
9335 107: "null file name"
9336 108: "can't stat file"
9337 109: "unit not connected"
9338 110: "off end of record"
9339 111: "truncation failed in endfile"
9340 112: "incomprehensible list input"
9341 113: "out of free space"
9342 114: "unit not connected"
9343 115: "read unexpected character"
9344 116: "bad logical input field"
9345 117: "bad variable type"
9346 118: "bad namelist name"
9347 119: "variable not in namelist"
9348 120: "no end record"
9349 121: "variable count incorrect"
9350 122: "subscript for scalar variable"
9351 123: "invalid array section"
9352 124: "substring out of bounds"
9353 125: "subscript out of bounds"
9354 126: "can't read file"
9355 127: "can't write file"
9356 128: "'new' file exists"
9357 129: "can't append to file"
9358 130: "non-positive record number"
9359 131: "I/O started while already doing I/O"
9362 @node Collected Fortran Wisdom
9363 @chapter Collected Fortran Wisdom
9366 @cindex code, legacy
9367 @cindex writing code
9368 @cindex code, writing
9370 Most users of @code{g77} can be divided into two camps:
9374 Those writing new Fortran code to be compiled by @code{g77}.
9377 Those using @code{g77} to compile existing, ``legacy'' code.
9380 Users writing new code generally understand most of the necessary
9381 aspects of Fortran to write ``mainstream'' code, but often need
9382 help deciding how to handle problems, such as the construction
9383 of libraries containing @code{BLOCK DATA}.
9385 Users dealing with ``legacy'' code sometimes don't have much
9386 experience with Fortran, but believe that the code they're compiling
9387 already works when compiled by other compilers (and might
9388 not understand why, as is sometimes the case, it doesn't work
9389 when compiled by @code{g77}).
9391 The following information is designed to help users do a better job
9392 coping with existing, ``legacy'' Fortran code, and with writing
9396 * Advantages Over f2c:: If @code{f2c} is so great, why @code{g77}?
9397 * Block Data and Libraries:: How @code{g77} solves a common problem.
9398 * Loops:: Fortran @code{DO} loops surprise many people.
9399 * Working Programs:: Getting programs to work should be done first.
9400 * Overly Convenient Options:: Temptations to avoid, habits to not form.
9401 * Faster Programs:: Everybody wants these, but at what cost?
9404 @node Advantages Over f2c
9405 @section Advantages Over f2c
9407 Without @code{f2c}, @code{g77} would have taken much longer to
9408 do and probably not been as good for quite a while.
9409 Sometimes people who notice how much @code{g77} depends on, and
9410 documents encouragement to use, @code{f2c} ask why @code{g77}
9411 was created if @code{f2c} already existed.
9413 This section gives some basic answers to these questions, though it
9414 is not intended to be comprehensive.
9417 * Language Extensions:: Features used by Fortran code.
9418 * Compiler Options:: Features helpful during development.
9419 * Compiler Speed:: Speed of the compilation process.
9420 * Program Speed:: Speed of the generated, optimized code.
9421 * Ease of Debugging:: Debugging ease-of-use at the source level.
9422 * Character and Hollerith Constants:: A byte saved is a byte earned.
9425 @node Language Extensions
9426 @subsection Language Extensions
9428 @code{g77} offers several extensions to the Fortran language that @code{f2c}
9431 However, @code{f2c} offers a few that @code{g77} doesn't, like
9432 fairly complete support for @code{INTEGER*2}.
9433 It is expected that @code{g77} will offer some or all of these missing
9434 features at some time in the future.
9435 (Version 0.5.18 of @code{g77} offers some rudimentary support for some
9438 @node Compiler Options
9439 @subsection Compiler Options
9441 @code{g77} offers a whole bunch of compiler options that @code{f2c} doesn't.
9443 However, @code{f2c} offers a few that @code{g77} doesn't, like an
9444 option to generate code to check array subscripts at run time.
9445 It is expected that @code{g77} will offer some or all of these
9446 missing options at some time in the future.
9448 @node Compiler Speed
9449 @subsection Compiler Speed
9451 Saving the steps of writing and then rereading C code is a big reason
9452 why @code{g77} should be able to compile code much faster than using
9453 @code{f2c} in conjunction with the equivalent invocation of @code{gcc}.
9455 However, due to @code{g77}'s youth, lots of self-checking is still being
9457 As a result, this improvement is as yet unrealized
9458 (though the potential seems to be there for quite a big speedup
9460 It is possible that, as of version 0.5.18, @code{g77}
9461 is noticeably faster compiling many Fortran source files than using
9462 @code{f2c} in conjunction with @code{gcc}.
9465 @subsection Program Speed
9467 @code{g77} has the potential to better optimize code than @code{f2c},
9468 even when @code{gcc} is used to compile the output of @code{f2c},
9469 because @code{f2c} must necessarily
9470 translate Fortran into a somewhat lower-level language (C) that cannot
9471 preserve all the information that is potentially useful for optimization,
9472 while @code{g77} can gather, preserve, and transmit that information directly
9475 For example, @code{g77} implements @code{ASSIGN} and assigned
9476 @code{GOTO} using direct assignment of pointers to labels and direct
9477 jumps to labels, whereas @code{f2c} maps the assigned labels to
9478 integer values and then uses a C @code{switch} statement to encode
9479 the assigned @code{GOTO} statements.
9481 However, as is typical, theory and reality don't quite match, at least
9482 not in all cases, so it is still the case that @code{f2c} plus @code{gcc}
9483 can generate code that is faster than @code{g77}.
9485 Version 0.5.18 of @code{g77} offered default
9486 settings and options, via patches to the @code{gcc}
9487 back end, that allow for better program speed, though
9488 some of these improvements also affected the performance
9489 of programs translated by @code{f2c} and then compiled
9490 by @code{g77}'s version of @code{gcc}.
9492 Version 0.5.20 of @code{g77} offers further performance
9493 improvements, at least one of which (alias analysis) is
9494 not generally applicable to @code{f2c} (though @code{f2c}
9495 could presumably be changed to also take advantage of
9496 this new capability of the @code{gcc} back end, assuming
9497 this is made available in an upcoming release of @code{gcc}).
9499 @node Ease of Debugging
9500 @subsection Ease of Debugging
9502 Because @code{g77} compiles directly to assembler code like @code{gcc},
9503 instead of translating to an intermediate language (C) as does @code{f2c},
9504 support for debugging can be better for @code{g77} than @code{f2c}.
9506 However, although @code{g77} might be somewhat more ``native'' in terms of
9507 debugging support than @code{f2c} plus @code{gcc}, there still are a lot
9508 of things ``not quite right''.
9509 Many of the important ones should be resolved in the near future.
9511 For example, @code{g77} doesn't have to worry about reserved names
9512 like @code{f2c} does.
9513 Given @samp{FOR = WHILE}, @code{f2c} must necessarily
9514 translate this to something @emph{other} than
9515 @samp{for = while;}, because C reserves those words.
9517 However, @code{g77} does still uses things like an extra level of indirection
9518 for @code{ENTRY}-laden procedures---in this case, because the back end doesn't
9519 yet support multiple entry points.
9521 Another example is that, given
9529 the @code{g77} user should be able to access the variables directly, by name,
9530 without having to traverse C-like structures and unions, while @code{f2c}
9531 is unlikely to ever offer this ability (due to limitations in the
9534 However, due to apparent bugs in the back end, @code{g77} currently doesn't
9535 take advantage of this facility at all---it doesn't emit any debugging
9536 information for @code{COMMON} and @code{EQUIVALENCE} areas,
9537 other than information
9538 on the array of @code{char} it creates (and, in the case
9539 of local @code{EQUIVALENCE}, names) for each such area.
9541 Yet another example is arrays.
9542 @code{g77} represents them to the debugger
9543 using the same ``dimensionality'' as in the source code, while @code{f2c}
9544 must necessarily convert them all to one-dimensional arrays to fit
9545 into the confines of the C language.
9546 However, the level of support
9547 offered by debuggers for interactive Fortran-style access to arrays
9548 as compiled by @code{g77} can vary widely.
9549 In some cases, it can actually
9550 be an advantage that @code{f2c} converts everything to widely supported
9553 In fairness, @code{g77} could do many of the things @code{f2c} does
9554 to get things working at least as well as @code{f2c}---for now,
9555 the developers prefer making @code{g77} work the
9556 way they think it is supposed to, and finding help improving the
9557 other products (the back end of @code{gcc}; @code{gdb}; and so on)
9558 to get things working properly.
9560 @node Character and Hollerith Constants
9561 @subsection Character and Hollerith Constants
9562 @cindex character constants
9563 @cindex constants, character
9564 @cindex Hollerith constants
9565 @cindex constants, Hollerith
9566 @cindex trailing null byte
9567 @cindex null byte, trailing
9568 @cindex zero byte, trailing
9570 To avoid the extensive hassle that would be needed to avoid this,
9571 @code{f2c} uses C character constants to encode character and Hollerith
9573 That means a constant like @samp{'HELLO'} is translated to
9574 @samp{"hello"} in C, which further means that an extra null byte is
9575 present at the end of the constant.
9576 This null byte is superfluous.
9578 @code{g77} does not generate such null bytes.
9579 This represents significant
9580 savings of resources, such as on systems where @file{/dev/null} or
9581 @file{/dev/zero} represent bottlenecks in the systems' performance,
9582 because @code{g77} simply asks for fewer zeros from the operating
9583 system than @code{f2c}.
9584 (Avoiding spurious use of zero bytes, each byte typically have
9585 eight zero bits, also reduces the liabilities in case
9586 Microsoft's rumored patent on the digits 0 and 1 is upheld.)
9588 @node Block Data and Libraries
9589 @section Block Data and Libraries
9590 @cindex block data and libraries
9591 @cindex BLOCK DATA statement
9592 @cindex statements, BLOCK DATA
9593 @cindex libraries, containing BLOCK DATA
9594 @cindex f2c compatibility
9595 @cindex compatibility, f2c
9597 To ensure that block data program units are linked, especially a concern
9598 when they are put into libraries, give each one a name (as in
9599 @samp{BLOCK DATA FOO}) and make sure there is an @samp{EXTERNAL FOO}
9600 statement in every program unit that uses any common block
9601 initialized by the corresponding @code{BLOCK DATA}.
9602 @code{g77} currently compiles a @code{BLOCK DATA} as if it were a
9604 that is, it generates an actual procedure having the appropriate name.
9605 The procedure does nothing but return immediately if it happens to be
9607 For @samp{EXTERNAL FOO}, where @samp{FOO} is not otherwise referenced in the
9608 same program unit, @code{g77} assumes there exists a @samp{BLOCK DATA FOO}
9609 in the program and ensures that by generating a
9610 reference to it so the linker will make sure it is present.
9611 (Specifically, @code{g77} outputs in the data section a static pointer to the
9612 external name @samp{FOO}.)
9614 The implementation @code{g77} currently uses to make this work is
9615 one of the few things not compatible with @code{f2c} as currently
9617 @code{f2c} currently does nothing with @samp{EXTERNAL FOO} except
9618 issue a warning that @samp{FOO} is not otherwise referenced,
9619 and, for @samp{BLOCK DATA FOO},
9620 @code{f2c} doesn't generate a dummy procedure with the name @samp{FOO}.
9621 The upshot is that you shouldn't mix @code{f2c} and @code{g77} in
9622 this particular case.
9623 If you use @code{f2c} to compile @samp{BLOCK DATA FOO},
9624 then any @code{g77}-compiled program unit that says @samp{EXTERNAL FOO}
9625 will result in an unresolved reference when linked.
9627 opposite, then @samp{FOO} might not be linked in under various
9628 circumstances (such as when @samp{FOO} is in a library, or you're
9629 using a ``clever'' linker---so clever, it produces a broken program
9630 with little or no warning by omitting initializations of global data
9631 because they are contained in unreferenced procedures).
9633 The changes you make to your code to make @code{g77} handle this situation,
9634 however, appear to be a widely portable way to handle it.
9635 That is, many systems permit it (as they should, since the
9636 FORTRAN 77 standard permits @samp{EXTERNAL FOO} when @samp{FOO}
9637 is a block data program unit), and of the ones
9638 that might not link @samp{BLOCK DATA FOO} under some circumstances, most of
9639 them appear to do so once @samp{EXTERNAL FOO} is present in the appropriate
9642 Here is the recommended approach to modifying a program containing
9643 a program unit such as the following:
9647 COMMON /VARS/ X, Y, Z
9648 DATA X, Y, Z / 3., 4., 5. /
9653 If the above program unit might be placed in a library module, then
9654 ensure that every program unit in every program that references that
9655 particular @code{COMMON} area uses the @code{EXTERNAL} statement
9656 to force the area to be initialized.
9658 For example, change a program unit that starts with
9661 INTEGER FUNCTION CURX()
9662 COMMON /VARS/ X, Y, Z
9668 so that it uses the @code{EXTERNAL} statement, as in:
9671 INTEGER FUNCTION CURX()
9672 COMMON /VARS/ X, Y, Z
9679 That way, @samp{CURX} is compiled by @code{g77} (and many other
9680 compilers) so that the linker knows it must include @samp{FOO},
9681 the @code{BLOCK DATA} program unit that sets the initial values
9682 for the variables in @samp{VAR}, in the executable program.
9686 @cindex DO statement
9687 @cindex statements, DO
9688 @cindex trips, number of
9689 @cindex number of trips
9691 The meaning of a @code{DO} loop in Fortran is precisely specified
9692 in the Fortran standard@dots{}and is quite different from what
9693 many programmers might expect.
9695 In particular, Fortran iterative @code{DO} loops are implemented as if
9696 the number of trips through the loop is calculated @emph{before}
9697 the loop is entered.
9699 The number of trips for a loop is calculated from the @var{start},
9700 @var{end}, and @var{increment} values specified in a statement such as:
9703 DO @var{iter} = @var{start}, @var{end}, @var{increment}
9707 The trip count is evaluated using a fairly simple formula
9708 based on the three values following the @samp{=} in the
9709 statement, and it is that trip count that is effectively
9710 decremented during each iteration of the loop.
9711 If, at the beginning of an iteration of the loop, the
9712 trip count is zero or negative, the loop terminates.
9713 The per-loop-iteration modifications to @var{iter} are not
9714 related to determining whether to terminate the loop.
9716 There are two important things to remember about the trip
9721 It can be @emph{negative}, in which case it is
9722 treated as if it was zero---meaning the loop is
9723 not executed at all.
9726 The type used to @emph{calculate} the trip count
9727 is the same type as @var{iter}, but the final
9728 calculation, and thus the type of the trip
9729 count itself, always is @code{INTEGER(KIND=1)}.
9732 These two items mean that there are loops that cannot
9733 be written in straightforward fashion using the Fortran @code{DO}.
9735 For example, on a system with the canonical 32-bit two's-complement
9736 implementation of @code{INTEGER(KIND=1)}, the following loop will not work:
9739 DO I = -2000000000, 2000000000
9743 Although the @var{start} and @var{end} values are well within
9744 the range of @code{INTEGER(KIND=1)}, the @emph{trip count} is not.
9745 The expected trip count is 40000000001, which is outside
9746 the range of @code{INTEGER(KIND=1)} on many systems.
9748 Instead, the above loop should be constructed this way:
9753 IF (I .GT. 2000000000) EXIT
9760 The simple @code{DO} construct and the @code{EXIT} statement
9761 (used to leave the innermost loop)
9762 are F90 features that @code{g77} supports.
9764 Some Fortran compilers have buggy implementations of @code{DO},
9765 in that they don't follow the standard.
9766 They implement @code{DO} as a straightforward translation
9767 to what, in C, would be a @code{for} statement.
9768 Instead of creating a temporary variable to hold the trip count
9769 as calculated at run time, these compilers
9770 use the iteration variable @var{iter} to control
9771 whether the loop continues at each iteration.
9773 The bug in such an implementation shows up when the
9774 trip count is within the range of the type of @var{iter},
9775 but the magnitude of @samp{ABS(@var{end}) + ABS(@var{incr})}
9776 exceeds that range. For example:
9779 DO I = 2147483600, 2147483647
9783 A loop started by the above statement will work as implemented
9784 by @code{g77}, but the use, by some compilers, of a
9785 more C-like implementation akin to
9788 for (i = 2147483600; i <= 2147483647; ++i)
9792 produces a loop that does not terminate, because @samp{i}
9793 can never be greater than 2147483647, since incrementing it
9794 beyond that value overflows @samp{i}, setting it to -2147483648.
9795 This is a large, negative number that still is less than 2147483647.
9797 Another example of unexpected behavior of @code{DO} involves
9798 using a nonintegral iteration variable @var{iter}, that is,
9799 a @code{REAL} variable.
9800 Consider the following program:
9803 DATA BEGIN, END, STEP /.1, .31, .007/
9804 DO 10 R = BEGIN, END, STEP
9805 IF (R .GT. END) PRINT *, R, ' .GT. ', END, '!!'
9809 IF (R .LE. END) PRINT *, R, ' .LE. ', END, '!!'
9814 A C-like view of @code{DO} would hold that the two ``exclamatory''
9815 @code{PRINT} statements are never executed.
9816 However, this is the output of running the above program
9817 as compiled by @code{g77} on a GNU/Linux ix86 system:
9829 .310000002 .LE. .310000002!!
9832 Note that one of the two checks in the program turned up
9833 an apparent violation of the programmer's expectation---yet,
9834 the loop is correctly implemented by @code{g77}, in that
9835 it has 30 iterations.
9836 This trip count of 30 is correct when evaluated using
9837 the floating-point representations for the @var{begin},
9838 @var{end}, and @var{incr} values (.1, .31, .007) on GNU/Linux
9840 On other systems, an apparently more accurate trip count
9841 of 31 might result, but, nevertheless, @code{g77} is
9842 faithfully following the Fortran standard, and the result
9843 is not what the author of the sample program above
9844 apparently expected.
9845 (Such other systems might, for different values in the @code{DATA}
9846 statement, violate the other programmer's expectation,
9849 Due to this combination of imprecise representation
9850 of floating-point values and the often-misunderstood
9851 interpretation of @code{DO} by standard-conforming
9852 compilers such as @code{g77}, use of @code{DO} loops
9853 with @code{REAL} iteration
9854 variables is not recommended.
9855 Such use can be caught by specifying @samp{-Wsurprising}.
9856 @xref{Warning Options}, for more information on this
9859 @node Working Programs
9860 @section Working Programs
9862 Getting Fortran programs to work in the first place can be
9863 quite a challenge---even when the programs already work on
9864 other systems, or when using other compilers.
9866 @code{g77} offers some facilities that might be useful for
9867 tracking down bugs in such programs.
9871 * Variables Assumed To Be Zero::
9872 * Variables Assumed To Be Saved::
9873 * Unwanted Variables::
9874 * Unused Arguments::
9875 * Surprising Interpretations of Code::
9876 * Aliasing Assumed To Work::
9877 * Output Assumed To Flush::
9878 * Large File Unit Numbers::
9879 * Floating-point precision::
9880 * Inconsistent Calling Sequences::
9884 @subsection Not My Type
9885 @cindex mistyped variables
9886 @cindex variables, mistyped
9887 @cindex mistyped functions
9888 @cindex functions, mistyped
9889 @cindex implicit typing
9891 A fruitful source of bugs in Fortran source code is use, or
9892 mis-use, of Fortran's implicit-typing feature, whereby the
9893 type of a variable, array, or function is determined by the
9894 first character of its name.
9896 Simple cases of this include statements like @samp{LOGX=9.227},
9897 without a statement such as @samp{REAL LOGX}.
9898 In this case, @samp{LOGX} is implicitly given @code{INTEGER(KIND=1)}
9899 type, with the result of the assignment being that it is given
9902 More involved cases include a function that is defined starting
9903 with a statement like @samp{DOUBLE PRECISION FUNCTION IPS(@dots{})}.
9904 Any caller of this function that does not also declare @samp{IPS}
9905 as type @code{DOUBLE PRECISION} (or, in GNU Fortran, @code{REAL(KIND=2)})
9906 is likely to assume it returns
9907 @code{INTEGER}, or some other type, leading to invalid results
9908 or even program crashes.
9910 The @samp{-Wimplicit} option might catch failures to
9911 properly specify the types of
9912 variables, arrays, and functions in the code.
9914 However, in code that makes heavy use of Fortran's
9915 implicit-typing facility, this option might produce so
9916 many warnings about cases that are working, it would be
9917 hard to find the one or two that represent bugs.
9918 This is why so many experienced Fortran programmers strongly
9919 recommend widespread use of the @code{IMPLICIT NONE} statement,
9920 despite it not being standard FORTRAN 77, to completely turn
9921 off implicit typing.
9922 (@code{g77} supports @code{IMPLICIT NONE}, as do almost all
9923 FORTRAN 77 compilers.)
9925 Note that @samp{-Wimplicit} catches only implicit typing of
9927 It does not catch implicit typing of expressions such
9929 Such expressions can be buggy as well---in fact, @samp{X**(2/3)}
9930 is equivalent to @samp{X**0}, due to the way Fortran expressions
9931 are given types and then evaluated.
9932 (In this particular case, the programmer probably wanted
9935 @node Variables Assumed To Be Zero
9936 @subsection Variables Assumed To Be Zero
9937 @cindex zero-initialized variables
9938 @cindex variables, assumed to be zero
9939 @cindex uninitialized variables
9941 Many Fortran programs were developed on systems that provided
9942 automatic initialization of all, or some, variables and arrays
9944 As a result, many of these programs depend, sometimes
9945 inadvertently, on this behavior, though to do so violates
9946 the Fortran standards.
9948 You can ask @code{g77} for this behavior by specifying the
9949 @samp{-finit-local-zero} option when compiling Fortran code.
9950 (You might want to specify @samp{-fno-automatic} as well,
9951 to avoid code-size inflation for non-optimized compilations.)
9953 Note that a program that works better when compiled with the
9954 @samp{-finit-local-zero} option
9955 is almost certainly depending on a particular system's,
9956 or compiler's, tendency to initialize some variables to zero.
9957 It might be worthwhile finding such cases and fixing them,
9958 using techniques such as compiling with the @samp{-O -Wuninitialized}
9959 options using @code{g77}.
9961 @node Variables Assumed To Be Saved
9962 @subsection Variables Assumed To Be Saved
9963 @cindex variables, retaining values across calls
9964 @cindex saved variables
9965 @cindex static variables
9967 Many Fortran programs were developed on systems that
9968 saved the values of all, or some, variables and arrays
9969 across procedure calls.
9970 As a result, many of these programs depend, sometimes
9971 inadvertently, on being able to assign a value to a
9972 variable, perform a @code{RETURN} to a calling procedure,
9973 and, upon subsequent invocation, reference the previously
9974 assigned variable to obtain the value.
9976 They expect this despite not using the @code{SAVE} statement
9977 to specify that the value in a variable is expected to survive
9978 procedure returns and calls.
9979 Depending on variables and arrays to retain values across
9980 procedure calls without using @code{SAVE} to require it violates
9981 the Fortran standards.
9983 You can ask @code{g77} to assume @code{SAVE} is specified for all
9984 relevant (local) variables and arrays by using the
9985 @samp{-fno-automatic} option.
9987 Note that a program that works better when compiled with the
9988 @samp{-fno-automatic} option
9989 is almost certainly depending on not having to use
9990 the @code{SAVE} statement as required by the Fortran standard.
9991 It might be worthwhile finding such cases and fixing them,
9992 using techniques such as compiling with the @samp{-O -Wuninitialized}
9993 options using @code{g77}.
9995 @node Unwanted Variables
9996 @subsection Unwanted Variables
9998 The @samp{-Wunused} option can find bugs involving
9999 implicit typing, sometimes
10000 more easily than using @samp{-Wimplicit} in code that makes
10001 heavy use of implicit typing.
10002 An unused variable or array might indicate that the
10003 spelling for its declaration is different from that of
10006 Other than cases involving typos, unused variables rarely
10007 indicate actual bugs in a program.
10008 However, investigating such cases thoroughly has, on occasion,
10009 led to the discovery of code that had not been completely
10010 written---where the programmer wrote declarations as needed
10011 for the whole algorithm, wrote some or even most of the code
10012 for that algorithm, then got distracted and forgot that the
10013 job was not complete.
10015 @node Unused Arguments
10016 @subsection Unused Arguments
10017 @cindex unused arguments
10018 @cindex arguments, unused
10020 As with unused variables, It is possible that unused arguments
10021 to a procedure might indicate a bug.
10022 Compile with @samp{-W -Wunused} option to catch cases of
10025 Note that @samp{-W} also enables warnings regarding overflow
10026 of floating-point constants under certain circumstances.
10028 @node Surprising Interpretations of Code
10029 @subsection Surprising Interpretations of Code
10031 The @samp{-Wsurprising} option can help find bugs involving
10032 expression evaluation or in
10033 the way @code{DO} loops with non-integral iteration variables
10035 Cases found by this option might indicate a difference of
10036 interpretation between the author of the code involved, and
10037 a standard-conforming compiler such as @code{g77}.
10038 Such a difference might produce actual bugs.
10040 In any case, changing the code to explicitly do what the
10041 programmer might have expected it to do, so @code{g77} and
10042 other compilers are more likely to follow the programmer's
10043 expectations, might be worthwhile, especially if such changes
10044 make the program work better.
10046 @node Aliasing Assumed To Work
10047 @subsection Aliasing Assumed To Work
10048 @cindex -falias-check option
10049 @cindex options, -falias-check
10050 @cindex -fargument-alias option
10051 @cindex options, -fargument-alias
10052 @cindex -fargument-noalias option
10053 @cindex options, -fargument-noalias
10054 @cindex -fno-argument-noalias-global option
10055 @cindex options, -fno-argument-noalias-global
10057 @cindex anti-aliasing
10058 @cindex overlapping arguments
10060 @cindex association, storage
10061 @cindex storage association
10062 @cindex scheduling of reads and writes
10063 @cindex reads and writes, scheduling
10065 The @samp{-falias-check}, @samp{-fargument-alias},
10066 @samp{-fargument-noalias},
10067 and @samp{-fno-argument-noalias-global} options,
10068 introduced in version 0.5.20 and
10069 @code{g77}'s version 2.7.2.2.f.2 of @code{gcc},
10070 were withdrawn as of @code{g77} version 0.5.23
10071 due to their not being supported by @code{gcc} version 2.8.
10073 These options, which control the assumptions regarding aliasing
10074 (overlapping) of writes and reads to main memory (core) made
10075 by the @code{gcc} back end,
10076 might well be added back (in some form) in a future version
10079 However, these options @emph{are} supported by @code{egcs}.
10081 The information below still is useful, but applies to
10082 only those versions of @code{g77} that support the
10083 alias analysis implied by support for these options.
10085 These options are effective only when compiling with @samp{-O}
10086 (specifying any level other than @samp{-O0})
10087 or with @samp{-falias-check}.
10089 The default for Fortran code is @samp{-fargument-noalias-global}.
10090 (The default for C code and code written in other C-based languages
10091 is @samp{-fargument-alias}.
10092 These defaults apply regardless of whether you use @code{g77} or
10093 @code{gcc} to compile your code.)
10095 Note that, on some systems, compiling with @samp{-fforce-addr} in
10096 effect can produce more optimal code when the default aliasing
10097 options are in effect (and when optimization is enabled).
10099 If your program is not working when compiled with optimization,
10100 it is possible it is violating the Fortran standards (77 and 90)
10101 by relying on the ability to ``safely'' modify variables and
10102 arrays that are aliased, via procedure calls, to other variables
10103 and arrays, without using @code{EQUIVALENCE} to explicitly
10104 set up this kind of aliasing.
10106 (The FORTRAN 77 standard's prohibition of this sort of
10107 overlap, generally referred to therein as ``storage
10108 assocation'', appears in Sections 15.9.3.6.
10109 This prohibition allows implementations, such as @code{g77},
10110 to, for example, implement the passing of procedures and
10111 even values in @code{COMMON} via copy operations into local,
10112 perhaps more efficiently accessed temporaries at entry to a
10113 procedure, and, where appropriate, via copy operations back
10114 out to their original locations in memory at exit from that
10115 procedure, without having to take into consideration the
10116 order in which the local copies are updated by the code,
10117 among other things.)
10119 To test this hypothesis, try compiling your program with
10120 the @samp{-fargument-alias} option, which causes the
10121 compiler to revert to assumptions essentially the same as
10122 made by versions of @code{g77} prior to 0.5.20.
10124 If the program works using this option, that strongly suggests
10125 that the bug is in your program.
10126 Finding and fixing the bug(s) should result in a program that
10127 is more standard-conforming and that can be compiled by @code{g77}
10128 in a way that results in a faster executable.
10130 (You might want to try compiling with @samp{-fargument-noalias},
10131 a kind of half-way point, to see if the problem is limited to
10132 aliasing between dummy arguments and @code{COMMON} variables---this
10133 option assumes that such aliasing is not done, while still allowing
10134 aliasing among dummy arguments.)
10136 An example of aliasing that is invalid according to the standards
10137 is shown in the following program, which might @emph{not} produce
10138 the expected results when executed:
10146 SUBROUTINE FOO(J, K)
10153 The above program attempts to use the temporary aliasing of the
10154 @samp{J} and @samp{K} arguments in @samp{FOO} to effect a
10155 pathological behavior---the simultaneous changing of the values
10156 of @emph{both} @samp{J} and @samp{K} when either one of them
10159 The programmer likely expects the program to print these values:
10166 However, since the program is not standard-conforming, an
10167 implementation's behavior when running it is undefined, because
10168 subroutine @samp{FOO} modifies at least one of the arguments,
10169 and they are aliased with each other.
10170 (Even if one of the assignment statements was deleted, the
10171 program would still violate these rules.
10172 This kind of on-the-fly aliasing is permitted by the standard
10173 only when none of the aliased items are defined, or written,
10174 while the aliasing is in effect.)
10176 As a practical example, an optimizing compiler might schedule
10177 the @samp{J =} part of the second line of @samp{FOO} @emph{after}
10178 the reading of @samp{J} and @samp{K} for the @samp{J * K} expression,
10179 resulting in the following output:
10186 Essentially, compilers are promised (by the standard and, therefore,
10187 by programmers who write code they claim to be standard-conforming)
10188 that if they cannot detect aliasing via static analysis of a single
10189 program unit's @code{EQUIVALENCE} and @code{COMMON} statements, no
10190 such aliasing exists.
10191 In such cases, compilers are free to assume that an assignment to
10192 one variable will not change the value of another variable, allowing
10193 it to avoid generating code to re-read the value of the other
10194 variable, to re-schedule reads and writes, and so on, to produce
10195 a faster executable.
10197 The same promise holds true for arrays (as seen by the called
10198 procedure)---an element of one dummy array cannot be aliased
10199 with, or overlap, any element of another dummy array or be
10200 in a @code{COMMON} area known to the procedure.
10202 (These restrictions apply only when the procedure defines, or
10203 writes to, one of the aliased variables or arrays.)
10205 Unfortunately, there is no way to find @emph{all} possible cases of
10206 violations of the prohibitions against aliasing in Fortran code.
10207 Static analysis is certainly imperfect, as is run-time analysis,
10208 since neither can catch all violations.
10209 (Static analysis can catch all likely violations, and some that
10210 might never actually happen, while run-time analysis can catch
10211 only those violations that actually happen during a particular run.
10212 Neither approach can cope with programs mixing Fortran code with
10213 routines written in other languages, however.)
10215 Currently, @code{g77} provides neither static nor run-time facilities
10216 to detect any cases of this problem, although other products might.
10217 Run-time facilities are more likely to be offered by future
10218 versions of @code{g77}, though patches improving @code{g77} so that
10219 it provides either form of detection are welcome.
10221 @node Output Assumed To Flush
10222 @subsection Output Assumed To Flush
10223 @cindex ALWAYS_FLUSH
10224 @cindex synchronous write errors
10226 @cindex flushing output
10228 @cindex I/O, flushing
10229 @cindex output, flushing
10230 @cindex writes, flushing
10232 @cindex network file system
10234 For several versions prior to 0.5.20, @code{g77} configured its
10235 version of the @code{libf2c} run-time library so that one of
10236 its configuration macros, @samp{ALWAYS_FLUSH}, was defined.
10238 This was done as a result of a belief that many programs expected
10239 output to be flushed to the operating system (under UNIX, via
10240 the @code{fflush()} library call) with the result that errors,
10241 such as disk full, would be immediately flagged via the
10242 relevant @code{ERR=} and @code{IOSTAT=} mechanism.
10244 Because of the adverse effects this approach had on the performance
10245 of many programs, @code{g77} no longer configures @code{libf2c}
10246 (now named @code{libg2c} in its @code{g77} incarnation)
10247 to always flush output.
10249 If your program depends on this behavior, either insert the
10250 appropriate @samp{CALL FLUSH} statements, or modify the sources
10251 to the @code{libg2c}, rebuild and reinstall @code{g77}, and
10252 relink your programs with the modified library.
10254 (Ideally, @code{libg2c} would offer the choice at run-time, so
10255 that a compile-time option to @code{g77} or @code{f2c} could
10256 result in generating the appropriate calls to flushing or
10257 non-flushing library routines.)
10259 @xref{Always Flush Output}, for information on how to modify
10260 the @code{g77} source tree so that a version of @code{libg2c}
10261 can be built and installed with the @samp{ALWAYS_FLUSH} macro defined.
10263 @node Large File Unit Numbers
10264 @subsection Large File Unit Numbers
10266 @cindex unit numbers
10267 @cindex maximum unit number
10268 @cindex illegal unit number
10269 @cindex increasing maximum unit number
10271 If your program crashes at run time with a message including
10272 the text @samp{illegal unit number}, that probably is
10273 a message from the run-time library, @code{libg2c}.
10275 The message means that your program has attempted to use a
10276 file unit number that is out of the range accepted by
10278 Normally, this range is 0 through 99, and the high end
10279 of the range is controlled by a @code{libg2c} source-file
10280 macro named @samp{MXUNIT}.
10282 If you can easily change your program to use unit numbers
10283 in the range 0 through 99, you should do so.
10285 Otherwise, see @ref{Larger File Unit Numbers}, for information on how
10286 to change @samp{MXUNIT} in @code{libg2c} so you can build and
10287 install a new version of @code{libg2c} that supports the larger
10288 unit numbers you need.
10290 @emph{Note:} While @code{libg2c} places a limit on the range
10291 of Fortran file-unit numbers, the underlying library and operating
10292 system might impose different kinds of limits.
10293 For example, some systems limit the number of files simultaneously
10294 open by a running program.
10295 Information on how to increase these limits should be found
10296 in your system's documentation.
10298 @node Floating-point precision
10299 @subsection Floating-point precision
10301 @cindex IEEE 754 conformance
10302 @cindex conformance, IEEE 754
10303 @cindex floating-point, precision
10304 @cindex ix86 floating-point
10305 @cindex x86 floating-point
10306 If your program depends on exact IEEE 754 floating-point handling it may
10307 help on some systems---specifically x86 or m68k hardware---to use
10308 the @code{-ffloat-store} option or to reset the precision flag on the
10309 floating-point unit @xref{Optimize Options}.
10311 However, it might be better simply to put the FPU into double precision
10312 mode and not take the performance hit of @code{-ffloat-store}. On x86
10313 and m68k GNU systems you can do this with a technique similar to that
10314 for turning on floating-point exceptions @xref{Floating-point Exception
10315 Handling}. The control word could be set to double precision by
10316 replacing the @code{__setfpucw} call with one like this:
10318 __setfpucw ((_FPU_DEFAULT & ~_FPU_EXTENDED) | _FPU_DOUBLE);
10320 (It is not clear whether this has any effect on the operation of the GNU
10321 maths library, but we have no evidence of it causing trouble.)
10323 Some targets (such as the Alpha) may need special options for full IEEE
10324 conformance @xref{Submodel Options,,Hardware Models and
10325 Configurations,gcc,Using and Porting GNU CC}.
10327 @node Inconsistent Calling Sequences
10328 @subsection Inconsistent Calling Sequences
10331 @cindex floating-point, errors
10332 @cindex ix86 FPU stack
10333 @cindex x86 FPU stack
10334 Code containing inconsistent calling sequences in the same file is
10335 normally rejected @xref{GLOBALS}. (Use, say, @code{ftnchek} to ensure
10336 consistency across source files
10337 @c makeinfo 1.68 objects to the nested parens
10339 @xref{f2c Skeletons and Prototypes}.)
10342 @xref{f2c Skeletons and Prototypes,,
10343 {Generating Skeletons and Prototypes with @code{f2c}}}.)
10346 Mysterious errors, which may appear to be code generation problems, can
10347 appear specifically on the x86 architecture with some such
10348 inconsistencies. On x86 hardware, floating-point return values of
10349 functions are placed on the floating-point unit's register stack, not
10350 the normal stack. Thus calling a @code{REAL} or @code{DOUBLE PRECISION}
10351 @code{FUNCTION} as some other sort of procedure, or vice versa,
10352 scrambles the floating-point stack. This may break unrelated code
10353 executed later. Similarly if, say, external C routines are written
10356 @node Overly Convenient Options
10357 @section Overly Convenient Command-line Options
10358 @cindex overly convenient options
10359 @cindex options, overly convenient
10361 These options should be used only as a quick-and-dirty way to determine
10362 how well your program will run under different compilation models
10363 without having to change the source.
10364 Some are more problematic
10365 than others, depending on how portable and maintainable you want the
10366 program to be (and, of course, whether you are allowed to change it
10367 at all is crucial).
10369 You should not continue to use these command-line options to compile
10370 a given program, but rather should make changes to the source code:
10373 @cindex -finit-local-zero option
10374 @cindex options, -finit-local-zero
10375 @item -finit-local-zero
10376 (This option specifies that any uninitialized local variables
10377 and arrays have default initialization to binary zeros.)
10379 Many other compilers do this automatically, which means lots of
10380 Fortran code developed with those compilers depends on it.
10382 It is safer (and probably
10383 would produce a faster program) to find the variables and arrays that
10384 need such initialization and provide it explicitly via @code{DATA}, so that
10385 @samp{-finit-local-zero} is not needed.
10387 Consider using @samp{-Wuninitialized} (which requires @samp{-O}) to
10388 find likely candidates, but
10389 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10390 or this technique won't work.
10392 @cindex -fno-automatic option
10393 @cindex options, -fno-automatic
10394 @item -fno-automatic
10395 (This option specifies that all local variables and arrays
10396 are to be treated as if they were named in @code{SAVE} statements.)
10398 Many other compilers do this automatically, which means lots of
10399 Fortran code developed with those compilers depends on it.
10401 The effect of this is that all non-automatic variables and arrays
10402 are made static, that is, not placed on the stack or in heap storage.
10403 This might cause a buggy program to appear to work better.
10404 If so, rather than relying on this command-line option (and hoping all
10405 compilers provide the equivalent one), add @code{SAVE}
10406 statements to some or all program unit sources, as appropriate.
10407 Consider using @samp{-Wuninitialized} (which requires @samp{-O})
10408 to find likely candidates, but
10409 do not specify @samp{-finit-local-zero} or @samp{-fno-automatic},
10410 or this technique won't work.
10412 The default is @samp{-fautomatic}, which tells @code{g77} to try
10413 and put variables and arrays on the stack (or in fast registers)
10414 where possible and reasonable.
10415 This tends to make programs faster.
10417 @cindex automatic arrays
10418 @cindex arrays, automatic
10419 @emph{Note:} Automatic variables and arrays are not affected
10421 These are variables and arrays that are @emph{necessarily} automatic,
10422 either due to explicit statements, or due to the way they are
10424 Examples include local variables and arrays not given the
10425 @code{SAVE} attribute in procedures declared @code{RECURSIVE},
10426 and local arrays declared with non-constant bounds (automatic
10428 Currently, @code{g77} supports only automatic arrays, not
10429 @code{RECURSIVE} procedures or other means of explicitly
10430 specifying that variables or arrays are automatic.
10432 @cindex -fugly option
10433 @cindex options, -fugly
10435 Fix the source code so that @samp{-fno-ugly} will work.
10436 Note that, for many programs, it is difficult to practically
10437 avoid using the features enabled via @samp{-fugly-init}, and these
10438 features pose the lowest risk of writing nonportable code, among the
10439 various ``ugly'' features.
10441 @cindex -f@var{group}-intrinsics-hide option
10442 @cindex options, -f@var{group}-intrinsics-hide
10443 @item -f@var{group}-intrinsics-hide
10444 Change the source code to use @code{EXTERNAL} for any external procedure
10445 that might be the name of an intrinsic.
10446 It is easy to find these using @samp{-f@var{group}-intrinsics-disable}.
10449 @node Faster Programs
10450 @section Faster Programs
10451 @cindex speed, of programs
10452 @cindex programs, speeding up
10454 Aside from the usual @code{gcc} options, such as @samp{-O},
10455 @samp{-ffast-math}, and so on, consider trying some of the
10456 following approaches to speed up your program (once you get
10461 * Prefer Automatic Uninitialized Variables::
10462 * Avoid f2c Compatibility::
10463 * Use Submodel Options::
10467 @subsection Aligned Data
10469 @cindex data, aligned
10470 @cindex stack, aligned
10471 @cindex aligned data
10472 @cindex aligned stack
10473 @cindex Pentium optimizations
10474 @cindex optimization, for Pentium
10476 On some systems, such as those with Pentium Pro CPUs, programs
10477 that make heavy use of @code{REAL(KIND=2)} (@code{DOUBLE PRECISION})
10478 might run much slower
10479 than possible due to the compiler not aligning these 64-bit
10480 values to 64-bit boundaries in memory.
10481 (The effect also is present, though
10482 to a lesser extent, on the 586 (Pentium) architecture.)
10484 The Intel x86 architecture generally ensures that these programs will
10485 work on all its implementations,
10486 but particular implementations (such as Pentium Pro)
10487 perform better with more strict alignment.
10488 (Such behavior isn't unique to the Intel x86 architecture.)
10489 Other architectures might @emph{demand} 64-bit alignment
10492 There are a variety of approaches to use to address this problem:
10496 @cindex @code{COMMON} layout
10497 @cindex layout of @code{COMMON} blocks
10498 Order your @code{COMMON} and @code{EQUIVALENCE} areas such
10499 that the variables and arrays with the widest alignment
10500 guidelines come first.
10502 For example, on most systems, this would mean placing
10503 @code{COMPLEX(KIND=2)}, @code{REAL(KIND=2)}, and
10504 @code{INTEGER(KIND=2)} entities first, followed by @code{REAL(KIND=1)},
10505 @code{INTEGER(KIND=1)}, and @code{LOGICAL(KIND=1)} entities, then
10506 @code{INTEGER(KIND=6)} entities, and finally @code{CHARACTER}
10507 and @code{INTEGER(KIND=3)} entities.
10509 The reason to use such placement is it makes it more likely
10510 that your data will be aligned properly, without requiring
10511 you to do detailed analysis of each aggregate (@code{COMMON}
10512 and @code{EQUIVALENCE}) area.
10514 Specifically, on systems where the above guidelines are
10515 appropriate, placing @code{CHARACTER} entities before
10516 @code{REAL(KIND=2)} entities can work just as well,
10517 but only if the number of bytes occupied by the @code{CHARACTER}
10518 entities is divisible by the recommended alignment for
10519 @code{REAL(KIND=2)}.
10521 By ordering the placement of entities in aggregate
10522 areas according to the simple guidelines above, you
10523 avoid having to carefully count the number of bytes
10524 occupied by each entity to determine whether the
10525 actual alignment of each subsequent entity meets the
10526 alignment guidelines for the type of that entity.
10528 If you don't ensure correct alignment of @code{COMMON} elements, the
10529 compiler may be forced by some systems to violate the Fortran semantics by
10530 adding padding to get @code{DOUBLE PRECISION} data properly aligned.
10531 If the unfortunate practice is employed of overlaying different types of
10532 data in the @code{COMMON} block, the different variants
10533 of this block may become misaligned with respect to each other.
10534 Even if your platform doesn't require strict alignment,
10535 @code{COMMON} should be laid out as above for portability.
10536 (Unfortunately the FORTRAN 77 standard didn't anticipate this
10537 possible requirement, which is compiler-independent on a given platform.)
10540 @cindex -malign-double option
10541 @cindex options, -malign-double
10542 Use the (x86-specific) @samp{-malign-double} option when compiling
10543 programs for the Pentium and Pentium Pro architectures (called 586
10544 and 686 in the @code{gcc} configuration subsystem).
10545 The warning about this in the @code{gcc} manual isn't
10546 generally relevant to Fortran,
10547 but using it will force @code{COMMON} to be padded if necessary to align
10548 @code{DOUBLE PRECISION} data.
10550 When @code{DOUBLE PRECISION} data is forcibly aligned
10551 in @code{COMMON} by @code{g77} due to specifying @samp{-malign-double},
10552 @code{g77} issues a warning about the need to
10555 In this case, each and every program unit that uses
10556 the same @code{COMMON} area
10557 must specify the same layout of variables and their types
10559 and be compiled with @samp{-malign-double} as well.
10560 @code{g77} will issue warnings in each case,
10561 but as long as every program unit using that area
10562 is compiled with the same warnings,
10563 the resulting object files should work when linked together
10564 unless the program makes additional assumptions about
10565 @code{COMMON} area layouts that are outside the scope
10566 of the FORTRAN 77 standard,
10567 or uses @code{EQUIVALENCE} or different layouts
10568 in ways that assume no padding is ever inserted by the compiler.
10571 Ensure that @file{crt0.o} or @file{crt1.o}
10572 on your system guarantees a 64-bit
10573 aligned stack for @code{main()}.
10574 The recent one from GNU (@code{glibc2}) will do this on x86 systems,
10575 but we don't know of any other x86 setups where it will be right.
10576 Read your system's documentation to determine if
10577 it is appropriate to upgrade to a more recent version
10578 to obtain the optimal alignment.
10581 Progress is being made on making this work
10582 ``out of the box'' on future versions of @code{g77},
10583 @code{gcc}, and some of the relevant operating systems
10584 (such as GNU/Linux).
10586 @cindex alignment testing
10587 @cindex testing alignment
10588 A package that tests the degree to which a Fortran compiler
10589 (such as @code{g77})
10590 aligns 64-bit floating-point variables and arrays
10591 is available at @uref{ftp://alpha.gnu.org/gnu/g77/align/}.
10593 @node Prefer Automatic Uninitialized Variables
10594 @subsection Prefer Automatic Uninitialized Variables
10596 If you're using @samp{-fno-automatic} already, you probably
10597 should change your code to allow compilation with @samp{-fautomatic}
10598 (the default), to allow the program to run faster.
10600 Similarly, you should be able to use @samp{-fno-init-local-zero}
10601 (the default) instead of @samp{-finit-local-zero}.
10602 This is because it is rare that every variable affected by these
10603 options in a given program actually needs to
10606 For example, @samp{-fno-automatic}, which effectively @code{SAVE}s
10607 every local non-automatic variable and array, affects even things like
10608 @code{DO} iteration
10609 variables, which rarely need to be @code{SAVE}d, and this often reduces
10610 run-time performances.
10611 Similarly, @samp{-fno-init-local-zero} forces such
10612 variables to be initialized to zero---when @code{SAVE}d (such as when
10613 @samp{-fno-automatic}), this by itself generally affects only
10614 startup time for a program, but when not @code{SAVE}d,
10615 it can slow down the procedure every time it is called.
10617 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
10618 for information on the @samp{-fno-automatic} and
10619 @samp{-finit-local-zero} options and how to convert
10620 their use into selective changes in your own code.
10622 @node Avoid f2c Compatibility
10623 @subsection Avoid f2c Compatibility
10624 @cindex -fno-f2c option
10625 @cindex options, -fno-f2c
10626 @cindex @code{f2c} compatibility
10627 @cindex compatibility, @code{f2c}
10629 If you aren't linking with any code compiled using
10630 @code{f2c}, try using the @samp{-fno-f2c} option when
10631 compiling @emph{all} the code in your program.
10632 (Note that @code{libf2c} is @emph{not} an example of code
10633 that is compiled using @code{f2c}---it is compiled by a C
10634 compiler, typically @code{gcc}.)
10636 @node Use Submodel Options
10637 @subsection Use Submodel Options
10638 @cindex Pentium optimizations
10639 @cindex optimization, for Pentium
10640 @cindex 586/686 CPUs
10643 Using an appropriate @samp{-m} option to generate specific code for your
10644 CPU may be worthwhile, though it may mean the executable won't run on
10645 other versions of the CPU that don't support the same instruction set.
10646 @xref{Submodel Options,,Hardware Models and Configurations,gcc,Using and
10649 For recent CPUs that don't have explicit support in
10650 the released version of @code{gcc}, it may still be possible to get
10652 For instance, the flags recommended for 586/686
10653 (Pentium(Pro)) chips for building the Linux kernel are:
10656 -m486 -malign-loops=2 -malign-jumps=2 -malign-functions=2
10657 -fomit-frame-pointer
10660 @noindent @samp{-fomit-frame-pointer} will, however, inhibit debugging
10664 @chapter Known Causes of Trouble with GNU Fortran
10665 @cindex bugs, known
10666 @cindex installation trouble
10667 @cindex known causes of trouble
10669 This section describes known problems that affect users of GNU Fortran.
10670 Most of these are not GNU Fortran bugs per se---if they were, we would
10672 But the result for a user might be like the result of a bug.
10674 Some of these problems are due to bugs in other software, some are
10675 missing features that are too much work to add, and some are places
10676 where people's opinions differ as to what is best.
10678 Information on bugs that show up when configuring, porting, building,
10679 or installing @code{g77} is not provided here.
10680 @xref{Problems Installing}.
10682 To find out about major bugs discovered in the current release and
10683 possible workarounds for them, see
10684 @uref{ftp://alpha.gnu.org/g77.plan}.
10686 (Note that some of this portion of the manual is lifted
10687 directly from the @code{gcc} manual, with minor modifications
10688 to tailor it to users of @code{g77}.
10689 Anytime a bug seems to have more to do with the @code{gcc}
10690 portion of @code{g77},
10691 @xref{Trouble,,Known Causes of Trouble with GNU CC,
10692 gcc,Using and Porting GNU CC}.)
10695 * But-bugs:: Bugs really in other programs or elsewhere.
10696 * Known Bugs:: Bugs known to be in this version of @code{g77}.
10697 * Missing Features:: Features we already know we want to add later.
10698 * Disappointments:: Regrettable things we can't change.
10699 * Non-bugs:: Things we think are right, but some others disagree.
10700 * Warnings and Errors:: Which problems in your code get warnings,
10701 and which get errors.
10705 @section Bugs Not In GNU Fortran
10708 These are bugs to which the maintainers often have to reply,
10709 ``but that isn't a bug in @code{g77}@dots{}''.
10710 Some of these already are fixed in new versions of other
10711 software; some still need to be fixed; some are problems
10712 with how @code{g77} is installed or is being used;
10713 some are the result of bad hardware that causes software
10714 to misbehave in sometimes bizarre ways;
10715 some just cannot be addressed at this time until more
10716 is known about the problem.
10718 Please don't re-report these bugs to the @code{g77} maintainers---if
10719 you must remind someone how important it is to you that the problem
10720 be fixed, talk to the people responsible for the other products
10721 identified below, but preferably only after you've tried the
10722 latest versions of those products.
10723 The @code{g77} maintainers have their hands full working on
10724 just fixing and improving @code{g77}, without serving as a
10725 clearinghouse for all bugs that happen to affect @code{g77}
10728 @xref{Collected Fortran Wisdom}, for information on behavior
10729 of Fortran programs, and the programs that compile them, that
10730 might be @emph{thought} to indicate bugs.
10733 * Signal 11 and Friends:: Strange behavior by any software.
10734 * Cannot Link Fortran Programs:: Unresolved references.
10735 * Large Common Blocks:: Problems on older GNU/Linux systems.
10736 * Debugger Problems:: When the debugger crashes.
10737 * NeXTStep Problems:: Misbehaving executables.
10738 * Stack Overflow:: More misbehaving executables.
10739 * Nothing Happens:: Less behaving executables.
10740 * Strange Behavior at Run Time:: Executables misbehaving due to
10741 bugs in your program.
10742 * Floating-point Errors:: The results look wrong, but@dots{}.
10745 @node Signal 11 and Friends
10746 @subsection Signal 11 and Friends
10748 @cindex hardware errors
10750 A whole variety of strange behaviors can occur when the
10751 software, or the way you are using the software,
10752 stresses the hardware in a way that triggers hardware bugs.
10753 This might seem hard to believe, but it happens frequently
10754 enough that there exist documents explaining in detail
10755 what the various causes of the problems are, what
10756 typical symptoms look like, and so on.
10758 Generally these problems are referred to in this document
10759 as ``signal 11'' crashes, because the Linux kernel, running
10760 on the most popular hardware (the Intel x86 line), often
10761 stresses the hardware more than other popular operating
10763 When hardware problems do occur under GNU/Linux on x86
10764 systems, these often manifest themselves as ``signal 11''
10765 problems, as illustrated by the following diagnostic:
10768 sh# @kbd{g77 myprog.f}
10769 gcc: Internal compiler error: program f771 got fatal signal 11
10773 It is @emph{very} important to remember that the above
10774 message is @emph{not} the only one that indicates a
10775 hardware problem, nor does it always indicate a hardware
10778 In particular, on systems other than those running the Linux
10779 kernel, the message might appear somewhat or very different,
10780 as it will if the error manifests itself while running a
10781 program other than the @code{g77} compiler.
10783 it will appear somewhat different when running your program,
10784 when running Emacs, and so on.
10786 How to cope with such problems is well beyond the scope
10789 However, users of Linux-based systems (such as GNU/Linux)
10790 should review @uref{http://www.bitwizard.nl/sig11}, a source
10791 of detailed information on diagnosing hardware problems,
10792 by recognizing their common symptoms.
10794 Users of other operating systems and hardware might
10795 find this reference useful as well.
10796 If you know of similar material for another hardware/software
10797 combination, please let us know so we can consider including
10798 a reference to it in future versions of this manual.
10800 @node Cannot Link Fortran Programs
10801 @subsection Cannot Link Fortran Programs
10802 @cindex unresolved reference (various)
10803 @cindex linking error for user code
10805 @cindex @code{ld}, error linking user code
10806 @cindex @code{ld}, can't find strange names
10807 On some systems, perhaps just those with out-of-date (shared?)
10808 libraries, unresolved-reference errors happen when linking @code{g77}-compiled
10809 programs (which should be done using @code{g77}).
10811 If this happens to you, try appending @samp{-lc} to the command you
10812 use to link the program, e.g. @samp{g77 foo.f -lc}.
10813 @code{g77} already specifies @samp{-lg2c -lm} when it calls the linker,
10814 but it cannot also specify @samp{-lc} because not all systems have a
10815 file named @file{libc.a}.
10817 It is unclear at this point whether there are legitimately installed
10818 systems where @samp{-lg2c -lm} is insufficient to resolve code produced
10821 @cindex undefined reference (_main)
10822 @cindex linking error, user code
10823 @cindex @code{ld}, error linking user code
10825 @cindex @code{ld}, can't find @samp{_main}
10826 If your program doesn't link due to unresolved references to names
10827 like @samp{_main}, make sure you're using the @code{g77} command to do the
10828 link, since this command ensures that the necessary libraries are
10829 loaded by specifying @samp{-lg2c -lm} when it invokes the @code{gcc}
10830 command to do the actual link.
10831 (Use the @samp{-v} option to discover
10832 more about what actually happens when you use the @code{g77} and @code{gcc}
10835 Also, try specifying @samp{-lc} as the last item on the @code{g77}
10836 command line, in case that helps.
10838 @node Large Common Blocks
10839 @subsection Large Common Blocks
10840 @cindex common blocks, large
10841 @cindex large common blocks
10842 @cindex linking, errors
10843 @cindex @code{ld}, errors
10844 @cindex errors, linker
10845 On some older GNU/Linux systems, programs with common blocks larger
10846 than 16MB cannot be linked without some kind of error
10847 message being produced.
10849 This is a bug in older versions of @code{ld}, fixed in
10850 more recent versions of @code{binutils}, such as version 2.6.
10852 @node Debugger Problems
10853 @subsection Debugger Problems
10854 @cindex @code{gdb}, support
10855 @cindex support, @code{gdb}
10856 There are some known problems when using @code{gdb} on code
10857 compiled by @code{g77}.
10858 Inadequate investigation as of the release of 0.5.16 results in not
10859 knowing which products are the culprit, but @file{gdb-4.14} definitely
10860 crashes when, for example, an attempt is made to print the contents
10861 of a @code{COMPLEX(KIND=2)} dummy array, on at least some GNU/Linux
10862 machines, plus some others.
10863 Attempts to access assumed-size arrays are
10864 also known to crash recent versions of @code{gdb}.
10865 (@code{gdb}'s Fortran support was done for a different compiler
10866 and isn't properly compatible with @code{g77}.)
10868 @node NeXTStep Problems
10869 @subsection NeXTStep Problems
10870 @cindex NeXTStep problems
10872 @cindex segmentation violation
10873 Developers of Fortran code on NeXTStep (all architectures) have to
10874 watch out for the following problem when writing programs with
10875 large, statically allocated (i.e. non-stack based) data structures
10876 (common blocks, saved arrays).
10878 Due to the way the native loader (@file{/bin/ld}) lays out
10879 data structures in virtual memory, it is very easy to create an
10880 executable wherein the @samp{__DATA} segment overlaps (has addresses in
10881 common) with the @samp{UNIX STACK} segment.
10883 This leads to all sorts of trouble, from the executable simply not
10884 executing, to bus errors.
10885 The NeXTStep command line tool @code{ebadexec} points to
10886 the problem as follows:
10889 % @kbd{/bin/ebadexec a.out}
10890 /bin/ebadexec: __LINKEDIT segment (truncated address = 0x3de000
10891 rounded size = 0x2a000) of executable file: a.out overlaps with UNIX
10892 STACK segment (truncated address = 0x400000 rounded size =
10893 0x3c00000) of executable file: a.out
10896 (In the above case, it is the @samp{__LINKEDIT} segment that overlaps the
10899 This can be cured by assigning the @samp{__DATA} segment
10900 (virtual) addresses beyond the stack segment.
10902 estimate for this is from address 6000000 (hexadecimal) onwards---this
10903 has always worked for me [Toon Moene]:
10906 % @kbd{g77 -segaddr __DATA 6000000 test.f}
10907 % @kbd{ebadexec a.out}
10908 ebadexec: file: a.out appears to be executable
10912 Browsing through @file{@value{path-g77}/Makefile.in},
10913 you will find that the @code{f771} program itself also has to be
10914 linked with these flags---it has large statically allocated
10916 (Version 0.5.18 reduces this somewhat, but probably
10919 (The above item was contributed by Toon Moene
10920 (@email{toon@@moene.indiv.nluug.nl}).)
10922 @node Stack Overflow
10923 @subsection Stack Overflow
10924 @cindex stack, overflow
10925 @cindex segmentation violation
10926 @code{g77} code might fail at runtime (probably with a ``segmentation
10927 violation'') due to overflowing the stack.
10928 This happens most often on systems with an environment
10929 that provides substantially more heap space (for use
10930 when arbitrarily allocating and freeing memory) than stack
10933 Often this can be cured by
10934 increasing or removing your shell's limit on stack usage, typically
10935 using @kbd{limit stacksize} (in @code{csh} and derivatives) or
10936 @kbd{ulimit -s} (in @code{sh} and derivatives).
10938 Increasing the allowed stack size might, however, require
10939 changing some operating system or system configuration parameters.
10941 You might be able to work around the problem by compiling with the
10942 @samp{-fno-automatic} option to reduce stack usage, probably at the
10945 @xref{Maximum Stackable Size}, for information on patching
10946 @code{g77} to use different criteria for placing local
10947 non-automatic variables and arrays on the stack.
10949 @cindex automatic arrays
10950 @cindex arrays, automatic
10951 However, if your program uses large automatic arrays
10952 (for example, has declarations like @samp{REAL A(N)} where
10953 @samp{A} is a local array and @samp{N} is a dummy or
10954 @code{COMMON} variable that can have a large value),
10955 neither use of @samp{-fno-automatic},
10956 nor changing the cut-off point for @code{g77} for using the stack,
10957 will solve the problem by changing the placement of these
10958 large arrays, as they are @emph{necessarily} automatic.
10960 @code{g77} currently provides no means to specify that
10961 automatic arrays are to be allocated on the heap instead
10963 So, other than increasing the stack size, your best bet is to
10964 change your source code to avoid large automatic arrays.
10965 Methods for doing this currently are outside the scope of
10968 (@emph{Note:} If your system puts stack and heap space in the
10969 same memory area, such that they are effectively combined, then
10970 a stack overflow probably indicates a program that is either
10971 simply too large for the system, or buggy.)
10973 @node Nothing Happens
10974 @subsection Nothing Happens
10975 @cindex nothing happens
10976 @cindex naming programs
10977 @cindex @samp{test} programs
10978 @cindex programs, @samp{test}
10979 It is occasionally reported that a ``simple'' program,
10980 such as a ``Hello, World!'' program, does nothing when
10981 it is run, even though the compiler reported no errors,
10982 despite the program containing nothing other than a
10983 simple @code{PRINT} statement.
10985 This most often happens because the program has been
10986 compiled and linked on a UNIX system and named @samp{test},
10987 though other names can lead to similarly unexpected
10988 run-time behavior on various systems.
10990 Essentially this problem boils down to giving
10991 your program a name that is already known to
10992 the shell you are using to identify some other program,
10993 which the shell continues to execute instead of your
10994 program when you invoke it via, for example:
11001 Under UNIX and many other system, a simple command name
11002 invokes a searching mechanism that might well not choose
11003 the program located in the current working directory if
11004 there is another alternative (such as the @code{test}
11005 command commonly installed on UNIX systems).
11007 The reliable way to invoke a program you just linked in
11008 the current directory under UNIX is to specify it using
11009 an explicit pathname, as in:
11017 Users who encounter this problem should take the time to
11018 read up on how their shell searches for commands, how to
11019 set their search path, and so on.
11020 The relevant UNIX commands to learn about include
11021 @code{man}, @code{info} (on GNU systems), @code{setenv} (or
11022 @code{set} and @code{env}), @code{which}, and @code{find}.
11024 @node Strange Behavior at Run Time
11025 @subsection Strange Behavior at Run Time
11026 @cindex segmentation violation
11028 @cindex overwritten data
11029 @cindex data, overwritten
11030 @code{g77} code might fail at runtime with ``segmentation violation'',
11031 ``bus error'', or even something as subtle as a procedure call
11032 overwriting a variable or array element that it is not supposed
11035 These can be symptoms of a wide variety of actual bugs that
11036 occurred earlier during the program's run, but manifested
11037 themselves as @emph{visible} problems some time later.
11039 Overflowing the bounds of an array---usually by writing beyond
11040 the end of it---is one of two kinds of bug that often occurs
11043 The other kind of bug is a mismatch between the actual arguments
11044 passed to a procedure and the dummy arguments as declared by that
11047 Both of these kinds of bugs, and some others as well, can be
11048 difficult to track down, because the bug can change its behavior,
11049 or even appear to not occur, when using a debugger.
11051 That is, these bugs can be quite sensitive to data, including
11052 data representing the placement of other data in memory (that is,
11053 pointers, such as the placement of stack frames in memory).
11055 Plans call for improving @code{g77} so that it can offer the
11056 ability to catch and report some of these problems at compile, link, or
11057 run time, such as by generating code to detect references to
11058 beyond the bounds of an array, or checking for agreement between
11059 calling and called procedures.
11061 In the meantime, finding and fixing the programming
11062 bugs that lead to these behaviors is, ultimately, the user's
11063 responsibility, as difficult as that task can sometimes be.
11065 @cindex infinite spaces printed
11066 @cindex space, endless printing of
11067 @cindex libc, non-ANSI or non-default
11069 @cindex linking against non-standard library
11071 One runtime problem that has been observed might have a simple solution.
11072 If a formatted @code{WRITE} produces an endless stream of spaces, check
11073 that your program is linked against the correct version of the C library.
11074 The configuration process takes care to account for your
11075 system's normal @file{libc} not being ANSI-standard, which will
11076 otherwise cause this behaviour.
11077 If your system's default library is
11078 ANSI-standard and you subsequently link against a non-ANSI one, there
11079 might be problems such as this one.
11081 Specifically, on Solaris2 systems,
11082 avoid picking up the @code{BSD} library from @file{/usr/ucblib}.
11084 @node Floating-point Errors
11085 @subsection Floating-point Errors
11086 @cindex floating-point errors
11087 @cindex rounding errors
11088 @cindex inconsistent floating-point results
11089 @cindex results, inconsistent
11090 Some programs appear to produce inconsistent floating-point
11091 results compiled by @code{g77} versus by other compilers.
11093 Often the reason for this behavior is the fact that floating-point
11094 values are represented on almost all Fortran systems by
11095 @emph{approximations}, and these approximations are inexact
11096 even for apparently simple values like 0.1, 0.2, 0.3, 0.4, 0.6,
11097 0.7, 0.8, 0.9, 1.1, and so on.
11098 Most Fortran systems, including all current ports of @code{g77},
11099 use binary arithmetic to represent these approximations.
11101 Therefore, the exact value of any floating-point approximation
11102 as manipulated by @code{g77}-compiled code is representable by
11103 adding some combination of the values 1.0, 0.5, 0.25, 0.125, and
11104 so on (just keep dividing by two) through the precision of the
11105 fraction (typically around 23 bits for @code{REAL(KIND=1)}, 52 for
11106 @code{REAL(KIND=2)}), then multiplying the sum by a integral
11107 power of two (in Fortran, by @samp{2**N}) that typically is between
11108 -127 and +128 for @code{REAL(KIND=1)} and -1023 and +1024 for
11109 @code{REAL(KIND=2)}, then multiplying by -1 if the number
11112 So, a value like 0.2 is exactly represented in decimal---since
11113 it is a fraction, @samp{2/10}, with a denominator that is compatible
11114 with the base of the number system (base 10).
11115 However, @samp{2/10} cannot be represented by any finite number
11116 of sums of any of 1.0, 0.5, 0.25, and so on, so 0.2 cannot
11117 be exactly represented in binary notation.
11119 (On the other hand, decimal notation can represent any binary
11120 number in a finite number of digits.
11121 Decimal notation cannot do so with ternary, or base-3,
11122 notation, which would represent floating-point numbers as
11123 sums of any of @samp{1/1}, @samp{1/3}, @samp{1/9}, and so on.
11124 After all, no finite number of decimal digits can exactly
11125 represent @samp{1/3}.
11126 Fortunately, few systems use ternary notation.)
11128 Moreover, differences in the way run-time I/O libraries convert
11129 between these approximations and the decimal representation often
11130 used by programmers and the programs they write can result in
11131 apparent differences between results that do not actually exist,
11132 or exist to such a small degree that they usually are not worth
11135 For example, consider the following program:
11142 When compiled by @code{g77}, the above program might output
11143 @samp{0.20000003}, while another compiler might produce a
11144 executable that outputs @samp{0.2}.
11146 This particular difference is due to the fact that, currently,
11147 conversion of floating-point values by the @code{libg2c} library,
11148 used by @code{g77}, handles only double-precision values.
11150 Since @samp{0.2} in the program is a single-precision value, it
11151 is converted to double precision (still in binary notation)
11152 before being converted back to decimal.
11153 The conversion to binary appends _binary_ zero digits to the
11154 original value---which, again, is an inexact approximation of
11155 0.2---resulting in an approximation that is much less exact
11156 than is connoted by the use of double precision.
11158 (The appending of binary zero digits has essentially the same
11159 effect as taking a particular decimal approximation of
11160 @samp{1/3}, such as @samp{0.3333333}, and appending decimal
11161 zeros to it, producing @samp{0.33333330000000000}.
11162 Treating the resulting decimal approximation as if it really
11163 had 18 or so digits of valid precision would make it seem
11164 a very poor approximation of @samp{1/3}.)
11166 As a result of converting the single-precision approximation
11167 to double precision by appending binary zeros, the conversion
11168 of the resulting double-precision
11169 value to decimal produces what looks like an incorrect
11170 result, when in fact the result is @emph{inexact}, and
11171 is probably no less inaccurate or imprecise an approximation
11172 of 0.2 than is produced by other compilers that happen to output
11173 the converted value as ``exactly'' @samp{0.2}.
11174 (Some compilers behave in a way that can make them appear
11175 to retain more accuracy across a conversion of a single-precision
11176 constant to double precision.
11177 @xref{Context-Sensitive Constants}, to see why
11178 this practice is illusory and even dangerous.)
11180 Note that a more exact approximation of the constant is
11181 computed when the program is changed to specify a
11182 double-precision constant:
11189 Future versions of @code{g77} and/or @code{libg2c} might convert
11190 single-precision values directly to decimal,
11191 instead of converting them to double precision first.
11192 This would tend to result in output that is more consistent
11193 with that produced by some other Fortran implementations.
11195 A useful source of information on floating-point computation is David
11196 Goldberg, `What Every Computer Scientist Should Know About
11197 Floating-Point Arithmetic', Computing Surveys, 23, March 1991, pp.@:
11199 An online version is available at
11200 @uref{http://docs.sun.com},
11201 and there is a supplemented version, in PostScript form, at
11202 @uref{http://www.validgh.com/goldberg/paper.ps}.
11204 Information related to the IEEE 754
11205 floating-point standard by a leading light can be found at
11206 @uref{http://http.cs.berkeley.edu/%7Ewkahan/ieee754status};
11207 see also slides from the short course referenced from
11208 @uref{http://http.cs.berkeley.edu/%7Efateman/}.
11209 @uref{http://www.linuxsupportline.com/%7Ebillm/} has a brief
11210 guide to IEEE 754, a somewhat x86-GNU/Linux-specific FAQ,
11211 and library code for GNU/Linux x86 systems.
11213 The supplement to the PostScript-formatted Goldberg document,
11214 referenced above, is available in HTML format.
11215 See `Differences Among IEEE 754 Implementations' by Doug Priest,
11216 available online at
11217 @uref{http://www.validgh.com/goldberg/addendum.html}.
11218 This document explores some of the issues surrounding computing
11219 of extended (80-bit) results on processors such as the x86,
11220 especially when those results are arbitrarily truncated
11221 to 32-bit or 64-bit values by the compiler
11224 @cindex spills of floating-point results
11225 @cindex 80-bit spills
11226 @cindex truncation, of floating-point values
11227 (@emph{Note:} @code{g77} specifically, and @code{gcc} generally,
11228 does arbitrarily truncate 80-bit results during spills
11229 as of this writing.
11230 It is not yet clear whether a future version of
11231 the GNU compiler suite will offer 80-bit spills
11232 as an option, or perhaps even as the default behavior.)
11234 @c xref would be different between editions:
11235 The GNU C library provides routines for controlling the FPU, and other
11236 documentation about this.
11238 @xref{Floating-point precision}, regarding IEEE 754 conformance.
11242 @node Missing Features
11243 @section Missing Features
11245 This section lists features we know are missing from @code{g77},
11246 and which we want to add someday.
11247 (There is no priority implied in the ordering below.)
11250 GNU Fortran language:
11251 * Better Source Model::
11252 * Fortran 90 Support::
11253 * Intrinsics in PARAMETER Statements::
11254 * SELECT CASE on CHARACTER Type::
11255 * RECURSIVE Keyword::
11256 * Popular Non-standard Types::
11257 * Full Support for Compiler Types::
11258 * Array Bounds Expressions::
11259 * POINTER Statements::
11260 * Sensible Non-standard Constructs::
11261 * FLUSH Statement::
11262 * Expressions in FORMAT Statements::
11263 * Explicit Assembler Code::
11264 * Q Edit Descriptor::
11266 GNU Fortran dialects:
11267 * Old-style PARAMETER Statements::
11268 * TYPE and ACCEPT I/O Statements::
11269 * STRUCTURE UNION RECORD MAP::
11270 * OPEN CLOSE and INQUIRE Keywords::
11271 * ENCODE and DECODE::
11272 * AUTOMATIC Statement::
11273 * Suppressing Space Padding::
11274 * Fortran Preprocessor::
11275 * Bit Operations on Floating-point Data::
11279 * Floating-point Exception Handling::
11280 * Nonportable Conversions::
11281 * Large Automatic Arrays::
11282 * Support for Threads::
11283 * Increasing Precision/Range::
11285 Better diagnostics:
11286 * Gracefully Handle Sensible Bad Code::
11287 * Non-standard Conversions::
11288 * Non-standard Intrinsics::
11289 * Modifying DO Variable::
11290 * Better Pedantic Compilation::
11291 * Warn About Implicit Conversions::
11292 * Invalid Use of Hollerith Constant::
11293 * Dummy Array Without Dimensioning Dummy::
11294 * Invalid FORMAT Specifiers::
11295 * Ambiguous Dialects::
11297 * Informational Messages::
11299 Run-time facilities:
11300 * Uninitialized Variables at Run Time::
11301 * Bounds Checking at Run Time::
11302 * Portable Unformatted Files::
11305 * Labels Visible to Debugger::
11308 @node Better Source Model
11309 @subsection Better Source Model
11311 @code{g77} needs to provide, as the default source-line model,
11312 a ``pure visual'' mode, where
11313 the interpretation of a source program in this mode can be accurately
11314 determined by a user looking at a traditionally displayed rendition
11315 of the program (assuming the user knows whether the program is fixed
11318 The design should assume the user cannot tell tabs from spaces
11319 and cannot see trailing spaces on lines, but has canonical tab stops
11320 and, for fixed-form source, has the ability to always know exactly
11321 where column 72 is (since the Fortran standard itself requires
11322 this for fixed-form source).
11324 This would change the default treatment of fixed-form source
11325 to not treat lines with tabs as if they were infinitely long---instead,
11326 they would end at column 72 just as if the tabs were replaced
11327 by spaces in the canonical way.
11329 As part of this, provide common alternate models (Digital, @code{f2c},
11330 and so on) via command-line options.
11331 This includes allowing arbitrarily long
11332 lines for free-form source as well as fixed-form source and providing
11333 various limits and diagnostics as appropriate.
11335 @cindex sequence numbers
11336 @cindex columns 73 through 80
11337 Also, @code{g77} should offer, perhaps even default to, warnings
11338 when characters beyond the last valid column are anything other
11340 This would mean code with ``sequence numbers'' in columns 73 through 80
11341 would be rejected, and there's a lot of that kind of code around,
11342 but one of the most frequent bugs encountered by new users is
11343 accidentally writing fixed-form source code into and beyond
11345 So, maybe the users of old code would be able to more easily handle
11346 having to specify, say, a @code{-Wno-col73to80} option.
11348 @node Fortran 90 Support
11349 @subsection Fortran 90 Support
11350 @cindex Fortran 90, support
11351 @cindex support, Fortran 90
11353 @code{g77} does not support many of the features that
11354 distinguish Fortran 90 (and, now, Fortran 95) from
11357 Some Fortran 90 features are supported, because they
11358 make sense to offer even to die-hard users of F77.
11359 For example, many of them codify various ways F77 has
11360 been extended to meet users' needs during its tenure,
11361 so @code{g77} might as well offer them as the primary
11362 way to meet those same needs, even if it offers compatibility
11363 with one or more of the ways those needs were met
11364 by other F77 compilers in the industry.
11366 Still, many important F90 features are not supported,
11367 because no attempt has been made to research each and
11368 every feature and assess its viability in @code{g77}.
11369 In the meantime, users who need those features must
11370 use Fortran 90 compilers anyway, and the best approach
11371 to adding some F90 features to GNU Fortran might well be
11372 to fund a comprehensive project to create GNU Fortran 95.
11374 @node Intrinsics in PARAMETER Statements
11375 @subsection Intrinsics in @code{PARAMETER} Statements
11376 @cindex PARAMETER statement
11377 @cindex statements, PARAMETER
11379 @code{g77} doesn't allow intrinsics in @code{PARAMETER} statements.
11380 This feature is considered to be absolutely vital, even though it
11381 is not standard-conforming, and is scheduled for version 0.6.
11383 Related to this, @code{g77} doesn't allow non-integral
11384 exponentiation in @code{PARAMETER} statements, such as
11385 @samp{PARAMETER (R=2**.25)}.
11386 It is unlikely @code{g77} will ever support this feature,
11387 as doing it properly requires complete emulation of
11388 a target computer's floating-point facilities when
11389 building @code{g77} as a cross-compiler.
11390 But, if the @code{gcc} back end is enhanced to provide
11391 such a facility, @code{g77} will likely use that facility
11392 in implementing this feature soon afterwards.
11394 @node SELECT CASE on CHARACTER Type
11395 @subsection @code{SELECT CASE} on @code{CHARACTER} Type
11397 Character-type selector/cases for @code{SELECT CASE} currently
11400 @node RECURSIVE Keyword
11401 @subsection @code{RECURSIVE} Keyword
11402 @cindex RECURSIVE keyword
11403 @cindex keywords, RECURSIVE
11404 @cindex recursion, lack of
11405 @cindex lack of recursion
11407 @code{g77} doesn't support the @code{RECURSIVE} keyword that
11409 Nor does it provide any means for compiling procedures
11410 designed to do recursion.
11412 All recursive code can be rewritten to not use recursion,
11413 but the result is not pretty.
11415 @node Increasing Precision/Range
11416 @subsection Increasing Precision/Range
11418 @cindex -qrealsize=8
11421 @cindex increasing precision
11422 @cindex precision, increasing
11423 @cindex increasing range
11424 @cindex range, increasing
11428 Some compilers, such as @code{f2c}, have an option (@samp{-r8},
11429 @samp{-qrealsize=8} or
11430 similar) that provides automatic treatment of @code{REAL}
11431 entities such that they have twice the storage size, and
11432 a corresponding increase in the range and precision, of what
11433 would normally be the @code{REAL(KIND=1)} (default @code{REAL}) type.
11434 (This affects @code{COMPLEX} the same way.)
11436 They also typically offer another option (@samp{-i8}) to increase
11437 @code{INTEGER} entities so they are twice as large
11438 (with roughly twice as much range).
11440 (There are potential pitfalls in using these options.)
11442 @code{g77} does not yet offer any option that performs these
11443 kinds of transformations.
11444 Part of the problem is the lack of detailed specifications regarding
11445 exactly how these options affect the interpretation of constants,
11446 intrinsics, and so on.
11448 Until @code{g77} addresses this need, programmers could improve
11449 the portability of their code by modifying it to not require
11450 compile-time options to produce correct results.
11451 Some free tools are available which may help, specifically
11452 in Toolpack (which one would expect to be sound) and the @file{fortran}
11453 section of the Netlib repository.
11455 Use of preprocessors can provide a fairly portable means
11456 to work around the lack of widely portable methods in the Fortran
11457 language itself (though increasing acceptance of Fortran 90 would
11458 alleviate this problem).
11460 @node Popular Non-standard Types
11461 @subsection Popular Non-standard Types
11462 @cindex @code{INTEGER*2} support
11463 @cindex types, @code{INTEGER*2}
11464 @cindex @code{LOGICAL*1} support
11465 @cindex types, @code{LOGICAL*1}
11467 @code{g77} doesn't fully support @code{INTEGER*2}, @code{LOGICAL*1},
11469 Version 0.6 will provide full support for this very
11470 popular set of features.
11471 In the meantime, version 0.5.18 provides rudimentary support
11474 @node Full Support for Compiler Types
11475 @subsection Full Support for Compiler Types
11477 @cindex @code{REAL*16} support
11478 @cindex types, @code{REAL*16}
11479 @cindex @code{INTEGER*8} support
11480 @cindex types, @code{INTEGER*8}
11481 @code{g77} doesn't support @code{INTEGER}, @code{REAL}, and @code{COMPLEX} equivalents
11482 for @emph{all} applicable back-end-supported types (@code{char}, @code{short int},
11483 @code{int}, @code{long int}, @code{long long int}, and @code{long double}).
11484 This means providing intrinsic support, and maybe constant
11485 support (using F90 syntax) as well, and, for most
11486 machines will result in automatic support of @code{INTEGER*1},
11487 @code{INTEGER*2}, @code{INTEGER*8}, maybe even @code{REAL*16},
11489 This is scheduled for version 0.6.
11491 @node Array Bounds Expressions
11492 @subsection Array Bounds Expressions
11493 @cindex array elements, in adjustable array bounds
11494 @cindex function references, in adjustable array bounds
11495 @cindex array bounds, adjustable
11496 @cindex @code{DIMENSION} statement
11497 @cindex statements, @code{DIMENSION}
11499 @code{g77} doesn't support more general expressions to dimension
11500 arrays, such as array element references, function
11503 For example, @code{g77} currently does not accept the following:
11507 INTEGER N(10), M(N(2), N(1))
11510 @node POINTER Statements
11511 @subsection POINTER Statements
11512 @cindex POINTER statement
11513 @cindex statements, POINTER
11514 @cindex Cray pointers
11516 @code{g77} doesn't support pointers or allocatable objects
11517 (other than automatic arrays).
11518 This set of features is
11519 probably considered just behind intrinsics
11520 in @code{PARAMETER} statements on the list of large,
11521 important things to add to @code{g77}.
11523 In the meantime, consider using the @code{INTEGER(KIND=7)}
11524 declaration to specify that a variable must be
11525 able to hold a pointer.
11526 This construct is not portable to other non-GNU compilers,
11527 but it is portable to all machines GNU Fortran supports
11528 when @code{g77} is used.
11530 @xref{Functions and Subroutines}, for information on
11531 @code{%VAL()}, @code{%REF()}, and @code{%DESCR()}
11532 constructs, which are useful for passing pointers to
11533 procedures written in languages other than Fortran.
11535 @node Sensible Non-standard Constructs
11536 @subsection Sensible Non-standard Constructs
11538 @code{g77} rejects things other compilers accept,
11539 like @samp{INTRINSIC SQRT,SQRT}.
11540 As time permits in the future, some of these things that are easy for
11541 humans to read and write and unlikely to be intended to mean something
11542 else will be accepted by @code{g77} (though @samp{-fpedantic} should
11543 trigger warnings about such non-standard constructs).
11545 Until @code{g77} no longer gratuitously rejects sensible code,
11546 you might as well fix your code
11547 to be more standard-conforming and portable.
11549 The kind of case that is important to except from the
11550 recommendation to change your code is one where following
11551 good coding rules would force you to write non-standard
11552 code that nevertheless has a clear meaning.
11554 For example, when writing an @code{INCLUDE} file that
11555 defines a common block, it might be appropriate to
11556 include a @code{SAVE} statement for the common block
11557 (such as @samp{SAVE /CBLOCK/}), so that variables
11558 defined in the common block retain their values even
11559 when all procedures declaring the common block become
11560 inactive (return to their callers).
11562 However, putting @code{SAVE} statements in an @code{INCLUDE}
11563 file would prevent otherwise standard-conforming code
11564 from also specifying the @code{SAVE} statement, by itself,
11565 to indicate that all local variables and arrays are to
11566 have the @code{SAVE} attribute.
11568 For this reason, @code{g77} already has been changed to
11569 allow this combination, because although the general
11570 problem of gratuitously rejecting unambiguous and
11571 ``safe'' constructs still exists in @code{g77}, this
11572 particular construct was deemed useful enough that
11573 it was worth fixing @code{g77} for just this case.
11575 So, while there is no need to change your code
11576 to avoid using this particular construct, there
11577 might be other, equally appropriate but non-standard
11578 constructs, that you shouldn't have to stop using
11579 just because @code{g77} (or any other compiler)
11580 gratuitously rejects it.
11582 Until the general problem is solved, if you have
11583 any such construct you believe is worthwhile
11584 using (e.g. not just an arbitrary, redundant
11585 specification of an attribute), please submit a
11586 bug report with an explanation, so we can consider
11587 fixing @code{g77} just for cases like yours.
11589 @node FLUSH Statement
11590 @subsection @code{FLUSH} Statement
11592 @code{g77} could perhaps use a @code{FLUSH} statement that
11593 does what @samp{CALL FLUSH} does,
11594 but that supports @samp{*} as the unit designator (same unit as for
11595 @code{PRINT}) and accepts @code{ERR=} and/or @code{IOSTAT=}
11598 @node Expressions in FORMAT Statements
11599 @subsection Expressions in @code{FORMAT} Statements
11600 @cindex FORMAT statement
11601 @cindex statements, FORMAT
11603 @code{g77} doesn't support @samp{FORMAT(I<J>)} and the like.
11604 Supporting this requires a significant redesign or replacement
11607 However, @code{g77} does support
11608 this construct when the expression is constant
11609 (as of version 0.5.22).
11613 PARAMETER (IWIDTH = 12)
11614 10 FORMAT (I<IWIDTH>)
11617 Otherwise, at least for output (@code{PRINT} and
11618 @code{WRITE}), Fortran code making use of this feature can
11619 be rewritten to avoid it by constructing the @code{FORMAT}
11620 string in a @code{CHARACTER} variable or array, then
11621 using that variable or array in place of the @code{FORMAT}
11622 statement label to do the original @code{PRINT} or @code{WRITE}.
11624 Many uses of this feature on input can be rewritten this way
11625 as well, but not all can.
11626 For example, this can be rewritten:
11633 However, this cannot, in general, be rewritten, especially
11634 when @code{ERR=} and @code{END=} constructs are employed:
11641 @node Explicit Assembler Code
11642 @subsection Explicit Assembler Code
11644 @code{g77} needs to provide some way, a la @code{gcc}, for @code{g77}
11645 code to specify explicit assembler code.
11647 @node Q Edit Descriptor
11648 @subsection Q Edit Descriptor
11649 @cindex FORMAT statement
11650 @cindex Q edit descriptor
11651 @cindex edit descriptor, Q
11653 The @code{Q} edit descriptor in @code{FORMAT}s isn't supported.
11654 (This is meant to get the number of characters remaining in an input record.)
11655 Supporting this requires a significant redesign or replacement
11658 A workaround might be using internal I/O or the stream-based intrinsics.
11659 @xref{FGetC Intrinsic (subroutine)}.
11661 @node Old-style PARAMETER Statements
11662 @subsection Old-style PARAMETER Statements
11663 @cindex PARAMETER statement
11664 @cindex statements, PARAMETER
11666 @code{g77} doesn't accept @samp{PARAMETER I=1}.
11667 Supporting this obsolete form of
11668 the @code{PARAMETER} statement would not be particularly hard, as most of the
11669 parsing code is already in place and working.
11671 Until time/money is
11672 spent implementing it, you might as well fix your code to use the
11673 standard form, @samp{PARAMETER (I=1)} (possibly needing
11674 @samp{INTEGER I} preceding the @code{PARAMETER} statement as well,
11675 otherwise, in the obsolete form of @code{PARAMETER}, the
11676 type of the variable is set from the type of the constant being
11679 @node TYPE and ACCEPT I/O Statements
11680 @subsection @code{TYPE} and @code{ACCEPT} I/O Statements
11681 @cindex TYPE statement
11682 @cindex statements, TYPE
11683 @cindex ACCEPT statement
11684 @cindex statements, ACCEPT
11686 @code{g77} doesn't support the I/O statements @code{TYPE} and
11688 These are common extensions that should be easy to support,
11689 but also are fairly easy to work around in user code.
11691 Generally, any @samp{TYPE fmt,list} I/O statement can be replaced
11692 by @samp{PRINT fmt,list}.
11693 And, any @samp{ACCEPT fmt,list} statement can be
11694 replaced by @samp{READ fmt,list}.
11696 @node STRUCTURE UNION RECORD MAP
11697 @subsection @code{STRUCTURE}, @code{UNION}, @code{RECORD}, @code{MAP}
11698 @cindex STRUCTURE statement
11699 @cindex statements, STRUCTURE
11700 @cindex UNION statement
11701 @cindex statements, UNION
11702 @cindex RECORD statement
11703 @cindex statements, RECORD
11704 @cindex MAP statement
11705 @cindex statements, MAP
11707 @code{g77} doesn't support @code{STRUCTURE}, @code{UNION}, @code{RECORD},
11709 This set of extensions is quite a bit
11710 lower on the list of large, important things to add to @code{g77}, partly
11711 because it requires a great deal of work either upgrading or
11712 replacing @code{libg2c}.
11714 @node OPEN CLOSE and INQUIRE Keywords
11715 @subsection @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} Keywords
11716 @cindex disposition of files
11717 @cindex OPEN statement
11718 @cindex statements, OPEN
11719 @cindex CLOSE statement
11720 @cindex statements, CLOSE
11721 @cindex INQUIRE statement
11722 @cindex statements, INQUIRE
11724 @code{g77} doesn't have support for keywords such as @code{DISP='DELETE'} in
11725 the @code{OPEN}, @code{CLOSE}, and @code{INQUIRE} statements.
11726 These extensions are easy to add to @code{g77} itself, but
11727 require much more work on @code{libg2c}.
11729 @cindex FORM='PRINT'
11730 @cindex ANS carriage control
11731 @cindex carriage control
11734 @code{g77} doesn't support @code{FORM='PRINT'} or an equivalent to
11735 translate the traditional `carriage control' characters in column 1 of
11736 output to use backspaces, carriage returns and the like. However
11737 programs exist to translate them in output files (or standard output).
11738 These are typically called either @code{fpr} or @code{asa}. You can get
11739 a version of @code{asa} from
11740 @uref{ftp://sunsite.unc.edu/pub/Linux/devel/lang/fortran} for GNU
11741 systems which will probably build easily on other systems.
11742 Alternatively, @code{fpr} is in BSD distributions in various archive
11745 @c (Can both programs can be used in a pipeline,
11746 @c with a named input file,
11747 @c and/or with a named output file???)
11749 @node ENCODE and DECODE
11750 @subsection @code{ENCODE} and @code{DECODE}
11751 @cindex ENCODE statement
11752 @cindex statements, ENCODE
11753 @cindex DECODE statement
11754 @cindex statements, DECODE
11756 @code{g77} doesn't support @code{ENCODE} or @code{DECODE}.
11758 These statements are best replaced by READ and WRITE statements
11759 involving internal files (CHARACTER variables and arrays).
11761 For example, replace a code fragment like
11766 DECODE (80, 9000, LINE) A, B, C
11768 9000 FORMAT (1X, 3(F10.5))
11777 READ (UNIT=LINE, FMT=9000) A, B, C
11779 9000 FORMAT (1X, 3(F10.5))
11782 Similarly, replace a code fragment like
11787 ENCODE (80, 9000, LINE) A, B, C
11789 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11798 WRITE (UNIT=LINE, FMT=9000) A, B, C
11800 9000 FORMAT (1X, 'OUTPUT IS ', 3(F10.5))
11803 It is entirely possible that @code{ENCODE} and @code{DECODE} will
11804 be supported by a future version of @code{g77}.
11806 @node AUTOMATIC Statement
11807 @subsection @code{AUTOMATIC} Statement
11808 @cindex @code{AUTOMATIC} statement
11809 @cindex statements, @code{AUTOMATIC}
11810 @cindex automatic variables
11811 @cindex variables, automatic
11813 @code{g77} doesn't support the @code{AUTOMATIC} keyword that
11816 It is not yet clear exactly what this statement would achieve.
11817 The semantic equivalent would be provided by @code{RECURSIVE}
11818 combined with lack of @code{SAVE}.
11819 In that sense, perhaps all it would provide is an
11820 overriding of an unadorned (blanket) @code{SAVE} statement
11821 for specific variables.
11823 It might also serve as a hint to the compiler that placing
11824 even a very large array on the stack is acceptable.
11826 Perhaps it should disallow @code{DATA}
11827 or other specification of any initial values
11828 for affected variables as well.
11830 @node Suppressing Space Padding
11831 @subsection Suppressing Space Padding of Source Lines
11833 @code{g77} should offer VXT-Fortran-style suppression of virtual
11834 spaces at the end of a source line
11835 if an appropriate command-line option is specified.
11837 This affects cases where
11838 a character constant is continued onto the next line in a fixed-form
11839 source file, as in the following example:
11842 10 PRINT *,'HOW MANY
11847 @code{g77}, and many other compilers, virtually extend
11848 the continued line through column 72 with spaces that become part
11849 of the character constant, but Digital Fortran normally didn't,
11850 leaving only one space between @samp{MANY} and @samp{SPACES?}
11851 in the output of the above statement.
11853 Fairly recently, at least one version of Digital Fortran
11854 was enhanced to provide the other behavior when a
11855 command-line option is specified, apparently due to demand
11856 from readers of the USENET group @file{comp.lang.fortran}
11857 to offer conformance to this widespread practice in the
11859 @code{g77} should return the favor by offering conformance
11860 to Digital's approach to handling the above example.
11862 @node Fortran Preprocessor
11863 @subsection Fortran Preprocessor
11865 @code{g77} should offer a preprocessor designed specifically
11866 for Fortran to replace @samp{cpp -traditional}.
11867 There are several out there worth evaluating, at least.
11869 Such a preprocessor would recognize Hollerith constants,
11870 properly parse comments and character constants, and so on.
11871 It might also recognize, process, and thus preprocess
11872 files included via the @code{INCLUDE} directive.
11874 @node Bit Operations on Floating-point Data
11875 @subsection Bit Operations on Floating-point Data
11876 @cindex @code{And} intrinsic
11877 @cindex intrinsics, @code{And}
11878 @cindex @code{Or} intrinsic
11879 @cindex intrinsics, @code{Or}
11880 @cindex @code{Shift} intrinsic
11881 @cindex intrinsics, @code{Shift}
11883 @code{g77} does not allow @code{REAL} and other non-integral types for
11884 arguments to intrinsics like @code{And}, @code{Or}, and @code{Shift}.
11886 For example, this program is rejected by @code{g77}, because
11887 the intrinsic @code{Iand} does not accept @code{REAL} arguments:
11890 DATA A/7.54/, B/9.112/
11891 PRINT *, IAND(A, B)
11895 @node POSIX Standard
11896 @subsection @code{POSIX} Standard
11898 @code{g77} should support the POSIX standard for Fortran.
11900 @node Floating-point Exception Handling
11901 @subsection Floating-point Exception Handling
11902 @cindex floating-point, exceptions
11903 @cindex exceptions, floating-point
11904 @cindex FPE handling
11907 The @code{gcc} backend and, consequently, @code{g77}, currently provides no
11908 general control over whether or not floating-point exceptions are trapped or
11910 (Ignoring them typically results in NaN values being
11911 propagated in systems that conform to IEEE 754.)
11912 The behaviour is normally inherited from the system-dependent startup
11913 code, though some targets, such as the Alpha, have code generation
11914 options which change the behaviour.
11916 Most systems provide some C-callable mechanism to change this; this can
11917 be invoked at startup using @code{gcc}'s @code{constructor} attribute.
11918 For example, just compiling and linking the following C code with your
11919 program will turn on exception trapping for the ``common'' exceptions
11920 on an x86-based GNU system:
11923 #include <fpu_control.h>
11924 static void __attribute__ ((constructor))
11927 __setfpucw (_FPU_DEFAULT &
11928 ~(_FPU_MASK_IM | _FPU_MASK_ZM | _FPU_MASK_OM));
11932 A convenient trick is to compile this something like:
11934 gcc -o libtrapfpe.a trapfpe.c
11936 and then use it by adding @code{-trapfpe} to the @code{g77} command line
11939 @node Nonportable Conversions
11940 @subsection Nonportable Conversions
11941 @cindex nonportable conversions
11942 @cindex conversions, nonportable
11944 @code{g77} doesn't accept some particularly nonportable,
11945 silent data-type conversions such as @code{LOGICAL}
11946 to @code{REAL} (as in @samp{A=.FALSE.}, where @samp{A}
11947 is type @code{REAL}), that other compilers might
11950 Some of these conversions are accepted by @code{g77}
11951 when the @samp{-fugly} option is specified.
11952 Perhaps it should accept more or all of them.
11954 @node Large Automatic Arrays
11955 @subsection Large Automatic Arrays
11956 @cindex automatic arrays
11957 @cindex arrays, automatic
11959 Currently, automatic arrays always are allocated on the stack.
11960 For situations where the stack cannot be made large enough,
11961 @code{g77} should offer a compiler option that specifies
11962 allocation of automatic arrays in heap storage.
11964 @node Support for Threads
11965 @subsection Support for Threads
11967 @cindex parallel processing
11969 Neither the code produced by @code{g77} nor the @code{libg2c} library
11970 are thread-safe, nor does @code{g77} have support for parallel processing
11971 (other than the instruction-level parallelism available on some
11973 A package such as PVM might help here.
11975 @node Gracefully Handle Sensible Bad Code
11976 @subsection Gracefully Handle Sensible Bad Code
11978 @code{g77} generally should continue processing for
11979 warnings and recoverable (user) errors whenever possible---that
11980 is, it shouldn't gratuitously make bad or useless code.
11991 When compiling the above with @samp{-ff2c-intrinsics-disable},
11992 @code{g77} should indeed complain about passing @code{ZABS},
11993 but it still should compile, instead of rejecting
11994 the entire @code{CALL} statement.
11995 (Some of this is related to improving
11996 the compiler internals to improve how statements are analyzed.)
11998 @node Non-standard Conversions
11999 @subsection Non-standard Conversions
12001 @samp{-Wconversion} and related should flag places where non-standard
12002 conversions are found.
12003 Perhaps much of this would be part of @samp{-Wugly*}.
12005 @node Non-standard Intrinsics
12006 @subsection Non-standard Intrinsics
12008 @code{g77} needs a new option, like @samp{-Wintrinsics}, to warn about use of
12009 non-standard intrinsics without explicit @code{INTRINSIC} statements for them.
12010 This would help find code that might fail silently when ported to another
12013 @node Modifying DO Variable
12014 @subsection Modifying @code{DO} Variable
12016 @code{g77} should warn about modifying @code{DO} variables
12017 via @code{EQUIVALENCE}.
12018 (The internal information gathered to produce this warning
12019 might also be useful in setting the
12020 internal ``doiter'' flag for a variable or even array
12021 reference within a loop, since that might produce faster code someday.)
12023 For example, this code is invalid, so @code{g77} should warn about
12024 the invalid assignment to @samp{NOTHER}:
12027 EQUIVALENCE (I, NOTHER)
12029 IF (I.EQ. 10) NOTHER = 20
12033 @node Better Pedantic Compilation
12034 @subsection Better Pedantic Compilation
12036 @code{g77} needs to support @samp{-fpedantic} more thoroughly,
12037 and use it only to generate
12038 warnings instead of rejecting constructs outright.
12040 if a variable that dimensions an array is not a dummy or placed
12041 explicitly in @code{COMMON} (F77 does not allow it to be
12042 placed in @code{COMMON} via @code{EQUIVALENCE}); if specification statements
12043 follow statement-function-definition statements; about all sorts of
12044 syntactic extensions.
12046 @node Warn About Implicit Conversions
12047 @subsection Warn About Implicit Conversions
12049 @code{g77} needs a @samp{-Wpromotions} option to warn if source code appears
12050 to expect automatic, silent, and
12051 somewhat dangerous compiler-assisted conversion of @code{REAL(KIND=1)}
12052 constants to @code{REAL(KIND=2)} based on context.
12054 For example, it would warn about cases like this:
12057 DOUBLE PRECISION FOO
12058 PARAMETER (TZPHI = 9.435784839284958)
12062 @node Invalid Use of Hollerith Constant
12063 @subsection Invalid Use of Hollerith Constant
12065 @code{g77} should disallow statements like @samp{RETURN 2HAB},
12066 which are invalid in both source forms
12067 (unlike @samp{RETURN (2HAB)},
12068 which probably still makes no sense but at least can
12069 be reliably parsed).
12070 Fixed-form processing rejects it, but not free-form, except
12071 in a way that is a bit difficult to understand.
12073 @node Dummy Array Without Dimensioning Dummy
12074 @subsection Dummy Array Without Dimensioning Dummy
12076 @code{g77} should complain when a list of dummy arguments containing an
12077 adjustable dummy array does
12078 not also contain every variable listed in the dimension list of the
12081 Currently, @code{g77} does complain about a variable that
12082 dimensions an array but doesn't appear in any dummy list or @code{COMMON}
12083 area, but this needs to be extended to catch cases where it doesn't appear in
12084 every dummy list that also lists any arrays it dimensions.
12086 For example, @code{g77} should warn about the entry point @samp{ALT}
12087 below, since it includes @samp{ARRAY} but not @samp{ISIZE} in its
12091 SUBROUTINE PRIMARY(ARRAY, ISIZE)
12096 @node Invalid FORMAT Specifiers
12097 @subsection Invalid FORMAT Specifiers
12099 @code{g77} should check @code{FORMAT} specifiers for validity
12100 as it does @code{FORMAT} statements.
12102 For example, a diagnostic would be produced for:
12105 PRINT 'HI THERE!' !User meant PRINT *, 'HI THERE!'
12108 @node Ambiguous Dialects
12109 @subsection Ambiguous Dialects
12111 @code{g77} needs a set of options such as @samp{-Wugly*}, @samp{-Wautomatic},
12112 @samp{-Wvxt}, @samp{-Wf90}, and so on.
12113 These would warn about places in the user's source where ambiguities
12114 are found, helpful in resolving ambiguities in the program's
12115 dialect or dialects.
12117 @node Unused Labels
12118 @subsection Unused Labels
12120 @code{g77} should warn about unused labels when @samp{-Wunused} is in effect.
12122 @node Informational Messages
12123 @subsection Informational Messages
12125 @code{g77} needs an option to suppress information messages (notes).
12126 @samp{-w} does this but also suppresses warnings.
12127 The default should be to suppress info messages.
12129 Perhaps info messages should simply be eliminated.
12131 @node Uninitialized Variables at Run Time
12132 @subsection Uninitialized Variables at Run Time
12134 @code{g77} needs an option to initialize everything (not otherwise
12135 explicitly initialized) to ``weird''
12136 (machine-dependent) values, e.g. NaNs, bad (non-@code{NULL}) pointers, and
12137 largest-magnitude integers, would help track down references to
12138 some kinds of uninitialized variables at run time.
12140 Note that use of the options @samp{-O -Wuninitialized} can catch
12141 many such bugs at compile time.
12143 @node Bounds Checking at Run Time
12144 @subsection Bounds Checking at Run Time
12146 @code{g77} should offer run-time bounds-checking of array/subscript references
12147 in a fashion similar to @code{f2c}.
12149 Note that @code{g77} already warns about references to out-of-bounds
12150 elements of arrays when it detects these at compile time.
12152 @node Portable Unformatted Files
12153 @subsection Portable Unformatted Files
12155 @cindex unformatted files
12156 @cindex file formats
12157 @cindex binary data
12158 @cindex byte ordering
12159 @code{g77} has no facility for exchanging unformatted files with systems
12160 using different number formats---even differing only in endianness (byte
12161 order)---or written by other compilers. Some compilers provide
12162 facilities at least for doing byte-swapping during unformatted I/O.
12164 It is unrealistic to expect to cope with exchanging unformatted files
12165 with arbitrary other compiler runtimes, but the @code{g77} runtime
12166 should at least be able to read files written by @code{g77} on systems
12167 with different number formats, particularly if they differ only in byte
12170 In case you do need to write a program to translate to or from
12171 @code{g77} (@code{libf2c}) unformatted files, they are written as
12175 Unformatted sequential records consist of
12178 A number giving the length of the record contents;
12180 the length of record contents again (for backspace).
12183 The record length is of C type
12184 @code{long}; this means that it is 8 bytes on 64-bit systems such as
12185 Alpha GNU/Linux and 4 bytes on other systems, such as x86 GNU/Linux.
12186 Consequently such files cannot be exchanged between 64-bit and 32-bit
12187 systems, even with the same basic number format.
12188 @item Direct access
12189 Unformatted direct access files form a byte stream of length
12190 @var{records}*@var{recl} bytes, where @var{records} is the maximum
12191 record number (@code{REC=@var{records}}) written and @var{recl} is the
12192 record length in bytes specified in the @code{OPEN} statement
12193 (@code{RECL=@var{recl}}). Data appear in the records as determined by
12194 the relevant @code{WRITE} statement. Dummy records with arbitrary
12195 contents appear in the file in place of records which haven't been
12199 Thus for exchanging a sequential or direct access unformatted file
12200 between big- and little-endian 32-bit systems using IEEE 754 floating
12201 point it would be sufficient to reverse the bytes in consecutive words
12202 in the file if, and @emph{only} if, only @code{REAL*4}, @code{COMPLEX},
12203 @code{INTEGER*4} and/or @code{LOGICAL*4} data have been written to it by
12206 If necessary, it is possible to do byte-oriented i/o with @code{g77}'s
12207 @code{FGETC} and @code{FPUTC} intrinsics. Byte-swapping can be done in
12208 Fortran by equivalencing larger sized variables to an @code{INTEGER*1}
12209 array or a set of scalars.
12213 If you need to exchange binary data between arbitrary system and
12214 compiler variations, we recommend using a portable binary format with
12215 Fortran bindings, such as NCSA's HDF (@uref{http://hdf.ncsa.uiuc.edu/})
12216 or PACT's PDB@footnote{No, not @emph{that} one.}
12217 (@uref{http://www.llnl.gov/def_sci/pact/pact_homepage.html}). (Unlike,
12218 say, CDF or XDR, HDF-like systems write in the native number formats and
12219 only incur overhead when they are read on a system with a different
12220 format.) A future @code{g77} runtime library should use such
12223 @node Labels Visible to Debugger
12224 @subsection Labels Visible to Debugger
12226 @code{g77} should output debugging information for statements labels,
12227 for use by debuggers that know how to support them.
12228 Same with weirder things like construct names.
12229 It is not yet known if any debug formats or debuggers support these.
12231 @node Disappointments
12232 @section Disappointments and Misunderstandings
12234 These problems are perhaps regrettable, but we don't know any practical
12235 way around them for now.
12238 * Mangling of Names:: @samp{SUBROUTINE FOO} is given
12239 external name @samp{foo_}.
12240 * Multiple Definitions of External Names:: No doing both @samp{COMMON /FOO/}
12241 and @samp{SUBROUTINE FOO}.
12242 * Limitation on Implicit Declarations:: No @samp{IMPLICIT CHARACTER*(*)}.
12245 @node Mangling of Names
12246 @subsection Mangling of Names in Source Code
12247 @cindex naming issues
12248 @cindex external names
12249 @cindex common blocks
12253 The current external-interface design, which includes naming of
12254 external procedures, COMMON blocks, and the library interface,
12255 has various usability problems, including things like adding
12256 underscores where not really necessary (and preventing easier
12257 inter-language operability) and yet not providing complete
12258 namespace freedom for user C code linked with Fortran apps (due
12259 to the naming of functions in the library, among other things).
12261 Project GNU should at least get all this ``right'' for systems
12262 it fully controls, such as the Hurd, and provide defaults and
12263 options for compatibility with existing systems and interoperability
12264 with popular existing compilers.
12266 @node Multiple Definitions of External Names
12267 @subsection Multiple Definitions of External Names
12269 @cindex BLOCK DATA statement
12270 @cindex statements, BLOCK DATA
12271 @cindex @code{COMMON} statement
12272 @cindex statements, @code{COMMON}
12273 @cindex naming conflicts
12275 @code{g77} doesn't allow a common block and an external procedure or
12276 @code{BLOCK DATA} to have the same name.
12277 Some systems allow this, but @code{g77} does not,
12278 to be compatible with @code{f2c}.
12280 @code{g77} could special-case the way it handles
12281 @code{BLOCK DATA}, since it is not compatible with @code{f2c} in this
12282 particular area (necessarily, since @code{g77} offers an
12283 important feature here), but
12284 it is likely that such special-casing would be very annoying to people
12285 with programs that use @samp{EXTERNAL FOO}, with no other mention of
12286 @samp{FOO} in the same program unit, to refer to external procedures, since
12287 the result would be that @code{g77} would treat these references as requests to
12288 force-load BLOCK DATA program units.
12290 In that case, if @code{g77} modified
12291 names of @code{BLOCK DATA} so they could have the same names as
12292 @code{COMMON}, users
12293 would find that their programs wouldn't link because the @samp{FOO} procedure
12294 didn't have its name translated the same way.
12296 (Strictly speaking,
12297 @code{g77} could emit a null-but-externally-satisfying definition of
12298 @samp{FOO} with its name transformed as if it had been a
12299 @code{BLOCK DATA}, but that probably invites more trouble than it's
12302 @node Limitation on Implicit Declarations
12303 @subsection Limitation on Implicit Declarations
12304 @cindex IMPLICIT CHARACTER*(*) statement
12305 @cindex statements, IMPLICIT CHARACTER*(*)
12307 @code{g77} disallows @code{IMPLICIT CHARACTER*(*)}.
12308 This is not standard-conforming.
12311 @section Certain Changes We Don't Want to Make
12313 This section lists changes that people frequently request, but which
12314 we do not make because we think GNU Fortran is better without them.
12317 * Backslash in Constants:: Why @samp{'\\'} is a constant that
12318 is one, not two, characters long.
12319 * Initializing Before Specifying:: Why @samp{DATA VAR/1/} can't precede
12321 * Context-Sensitive Intrinsicness:: Why @samp{CALL SQRT} won't work.
12322 * Context-Sensitive Constants:: Why @samp{9.435784839284958} is a
12323 single-precision constant,
12324 and might be interpreted as
12325 @samp{9.435785} or similar.
12326 * Equivalence Versus Equality:: Why @samp{.TRUE. .EQ. .TRUE.} won't work.
12327 * Order of Side Effects:: Why @samp{J = IFUNC() - IFUNC()} might
12328 not behave as expected.
12331 @node Backslash in Constants
12332 @subsection Backslash in Constants
12334 @cindex @code{f77} support
12335 @cindex support, @code{f77}
12337 In the opinion of many experienced Fortran users,
12338 @samp{-fno-backslash} should be the default, not @samp{-fbackslash},
12339 as currently set by @code{g77}.
12341 First of all, you can always specify
12342 @samp{-fno-backslash} to turn off this processing.
12344 Despite not being within the spirit (though apparently within the
12345 letter) of the ANSI FORTRAN 77 standard, @code{g77} defaults to
12346 @samp{-fbackslash} because that is what most UNIX @code{f77} commands
12347 default to, and apparently lots of code depends on this feature.
12349 This is a particularly troubling issue.
12350 The use of a C construct in the midst of Fortran code
12351 is bad enough, worse when it makes existing Fortran
12352 programs stop working (as happens when programs written
12353 for non-UNIX systems are ported to UNIX systems with
12354 compilers that provide the @samp{-fbackslash} feature
12355 as the default---sometimes with no option to turn it off).
12357 The author of GNU Fortran wished, for reasons of linguistic
12358 purity, to make @samp{-fno-backslash} the default for GNU
12359 Fortran and thus require users of UNIX @code{f77} and @code{f2c}
12360 to specify @samp{-fbackslash} to get the UNIX behavior.
12362 However, the realization that @code{g77} is intended as
12363 a replacement for @emph{UNIX} @code{f77}, caused the author
12364 to choose to make @code{g77} as compatible with
12365 @code{f77} as feasible, which meant making @samp{-fbackslash}
12368 The primary focus on compatibility is at the source-code
12369 level, and the question became ``What will users expect
12370 a replacement for @code{f77} to do, by default?''
12371 Although at least one UNIX @code{f77} does not provide
12372 @samp{-fbackslash} as a default, it appears that
12373 the majority of them do, which suggests that
12374 the majority of code that is compiled by UNIX @code{f77}
12375 compilers expects @samp{-fbackslash} to be the default.
12377 It is probably the case that more code exists
12378 that would @emph{not} work with @samp{-fbackslash}
12379 in force than code that requires it be in force.
12381 However, most of @emph{that} code is not being compiled
12383 and when it is, new build procedures (shell scripts,
12384 makefiles, and so on) must be set up anyway so that
12385 they work under UNIX.
12386 That makes a much more natural and safe opportunity for
12387 non-UNIX users to adapt their build procedures for
12388 @code{g77}'s default of @samp{-fbackslash} than would
12389 exist for the majority of UNIX @code{f77} users who
12390 would have to modify existing, working build procedures
12391 to explicitly specify @samp{-fbackslash} if that was
12394 One suggestion has been to configure the default for
12395 @samp{-fbackslash} (and perhaps other options as well)
12396 based on the configuration of @code{g77}.
12398 This is technically quite straightforward, but will be avoided
12399 even in cases where not configuring defaults to be
12400 dependent on a particular configuration greatly inconveniences
12401 some users of legacy code.
12403 Many users appreciate the GNU compilers because they provide an
12404 environment that is uniform across machines.
12405 These users would be
12406 inconvenienced if the compiler treated things like the
12407 format of the source code differently on certain machines.
12409 Occasionally users write programs intended only for a particular machine
12411 On these occasions, the users would benefit if the GNU Fortran compiler
12412 were to support by default the same dialect as the other compilers on
12414 But such applications are rare.
12415 And users writing a
12416 program to run on more than one type of machine cannot possibly benefit
12417 from this kind of compatibility.
12418 (This is consistent with the design goals for @code{gcc}.
12419 To change them for @code{g77}, you must first change them
12421 Do not ask the maintainers of @code{g77} to do this for you,
12422 or to disassociate @code{g77} from the widely understood, if
12423 not widely agreed-upon, goals for GNU compilers in general.)
12425 This is why GNU Fortran does and will treat backslashes in the same
12426 fashion on all types of machines (by default).
12427 @xref{Direction of Language Development}, for more information on
12428 this overall philosophy guiding the development of the GNU Fortran
12431 Of course, users strongly concerned about portability should indicate
12432 explicitly in their build procedures which options are expected
12433 by their source code, or write source code that has as few such
12434 expectations as possible.
12436 For example, avoid writing code that depends on backslash (@samp{\})
12437 being interpreted either way in particular, such as by
12438 starting a program unit with:
12442 PARAMETER (BACKSL = '\\')
12446 Then, use concatenation of @samp{BACKSL} anyplace a backslash
12448 In this way, users can write programs which have the same meaning
12449 in many Fortran dialects.
12451 (However, this technique does not work for Hollerith constants---which
12452 is just as well, since the only generally portable uses for Hollerith
12453 constants are in places where character constants can and should
12454 be used instead, for readability.)
12456 @node Initializing Before Specifying
12457 @subsection Initializing Before Specifying
12458 @cindex initialization, statement placement
12459 @cindex placing initialization statements
12461 @code{g77} does not allow @samp{DATA VAR/1/} to appear in the
12462 source code before @samp{COMMON VAR},
12463 @samp{DIMENSION VAR(10)}, @samp{INTEGER VAR}, and so on.
12464 In general, @code{g77} requires initialization of a variable
12465 or array to be specified @emph{after} all other specifications
12466 of attributes (type, size, placement, and so on) of that variable
12467 or array are specified (though @emph{confirmation} of data type is
12470 It is @emph{possible} @code{g77} will someday allow all of this,
12471 even though it is not allowed by the FORTRAN 77 standard.
12473 Then again, maybe it is better to have
12474 @code{g77} always require placement of @code{DATA}
12475 so that it can possibly immediately write constants
12476 to the output file, thus saving time and space.
12478 That is, @samp{DATA A/1000000*1/} should perhaps always
12479 be immediately writable to canonical assembler, unless it's already known
12480 to be in a @code{COMMON} area following as-yet-uninitialized stuff,
12481 and to do this it cannot be followed by @samp{COMMON A}.
12483 @node Context-Sensitive Intrinsicness
12484 @subsection Context-Sensitive Intrinsicness
12485 @cindex intrinsics, context-sensitive
12486 @cindex context-sensitive intrinsics
12488 @code{g77} treats procedure references to @emph{possible} intrinsic
12489 names as always enabling their intrinsic nature, regardless of
12490 whether the @emph{form} of the reference is valid for that
12493 For example, @samp{CALL SQRT} is interpreted by @code{g77} as
12494 an invalid reference to the @code{SQRT} intrinsic function,
12495 because the reference is a subroutine invocation.
12497 First, @code{g77} recognizes the statement @samp{CALL SQRT}
12498 as a reference to a @emph{procedure} named @samp{SQRT}, not
12499 to a @emph{variable} with that name (as it would for a statement
12500 such as @samp{V = SQRT}).
12502 Next, @code{g77} establishes that, in the program unit being compiled,
12503 @code{SQRT} is an intrinsic---not a subroutine that
12504 happens to have the same name as an intrinsic (as would be
12505 the case if, for example, @samp{EXTERNAL SQRT} was present).
12507 Finally, @code{g77} recognizes that the @emph{form} of the
12508 reference is invalid for that particular intrinsic.
12509 That is, it recognizes that it is invalid for an intrinsic
12510 @emph{function}, such as @code{SQRT}, to be invoked as
12511 a @emph{subroutine}.
12513 At that point, @code{g77} issues a diagnostic.
12515 Some users claim that it is ``obvious'' that @samp{CALL SQRT}
12516 references an external subroutine of their own, not an
12517 intrinsic function.
12519 However, @code{g77} knows about intrinsic
12520 subroutines, not just functions, and is able to support both having
12521 the same names, for example.
12523 As a result of this, @code{g77} rejects calls
12524 to intrinsics that are not subroutines, and function invocations
12525 of intrinsics that are not functions, just as it (and most compilers)
12526 rejects invocations of intrinsics with the wrong number (or types)
12529 So, use the @samp{EXTERNAL SQRT} statement in a program unit that calls
12530 a user-written subroutine named @samp{SQRT}.
12532 @node Context-Sensitive Constants
12533 @subsection Context-Sensitive Constants
12534 @cindex constants, context-sensitive
12535 @cindex context-sensitive constants
12537 @code{g77} does not use context to determine the types of
12538 constants or named constants (@code{PARAMETER}), except
12539 for (non-standard) typeless constants such as @samp{'123'O}.
12541 For example, consider the following statement:
12544 PRINT *, 9.435784839284958 * 2D0
12548 @code{g77} will interpret the (truncated) constant
12549 @samp{9.435784839284958} as a @code{REAL(KIND=1)}, not @code{REAL(KIND=2)},
12550 constant, because the suffix @code{D0} is not specified.
12552 As a result, the output of the above statement when
12553 compiled by @code{g77} will appear to have ``less precision''
12554 than when compiled by other compilers.
12556 In these and other cases, some compilers detect the
12557 fact that a single-precision constant is used in
12558 a double-precision context and therefore interpret the
12559 single-precision constant as if it was @emph{explicitly}
12560 specified as a double-precision constant.
12561 (This has the effect of appending @emph{decimal}, not
12562 @emph{binary}, zeros to the fractional part of the
12563 number---producing different computational results.)
12565 The reason this misfeature is dangerous is that a slight,
12566 apparently innocuous change to the source code can change
12567 the computational results.
12572 DOUBLE PRECISION FIVE
12573 PARAMETER (ALMOST = 5.000000000001)
12575 CLOSE = 5.000000000001
12576 PRINT *, 5.000000000001 - FIVE
12577 PRINT *, ALMOST - FIVE
12578 PRINT *, CLOSE - FIVE
12583 Running the above program should
12584 result in the same value being
12585 printed three times.
12586 With @code{g77} as the compiler,
12589 However, compiled by many other compilers,
12590 running the above program would print
12591 two or three distinct values, because
12592 in two or three of the statements, the
12593 constant @samp{5.000000000001}, which
12594 on most systems is exactly equal to @samp{5.}
12595 when interpreted as a single-precision constant,
12596 is instead interpreted as a double-precision
12597 constant, preserving the represented
12599 However, this ``clever'' promotion of
12600 type does not extend to variables or,
12601 in some compilers, to named constants.
12603 Since programmers often are encouraged to replace manifest
12604 constants or permanently-assigned variables with named
12605 constants (@code{PARAMETER} in Fortran), and might need
12606 to replace some constants with variables having the same
12607 values for pertinent portions of code,
12608 it is important that compilers treat code so modified in the
12609 same way so that the results of such programs are the same.
12610 @code{g77} helps in this regard by treating constants just
12611 the same as variables in terms of determining their types
12612 in a context-independent way.
12614 Still, there is a lot of existing Fortran code that has
12615 been written to depend on the way other compilers freely
12616 interpret constants' types based on context, so anything
12617 @code{g77} can do to help flag cases of this in such code
12618 could be very helpful.
12620 @node Equivalence Versus Equality
12621 @subsection Equivalence Versus Equality
12622 @cindex .EQV., with integer operands
12623 @cindex comparing logical expressions
12624 @cindex logical expressions, comparing
12626 Use of @code{.EQ.} and @code{.NE.} on @code{LOGICAL} operands
12627 is not supported, except via @samp{-fugly}, which is not
12628 recommended except for legacy code (where the behavior expected
12629 by the @emph{code} is assumed).
12631 Legacy code should be changed, as resources permit, to use @code{.EQV.}
12632 and @code{.NEQV.} instead, as these are permitted by the various
12635 New code should never be written expecting @code{.EQ.} or @code{.NE.}
12636 to work if either of its operands is @code{LOGICAL}.
12638 The problem with supporting this ``feature'' is that there is
12639 unlikely to be consensus on how it works, as illustrated by the
12640 following sample program:
12644 DATA L,M,N /3*.FALSE./
12645 IF (L.AND.M.EQ.N) PRINT *,'L.AND.M.EQ.N'
12649 The issue raised by the above sample program is: what is the
12650 precedence of @code{.EQ.} (and @code{.NE.}) when applied to
12651 @code{LOGICAL} operands?
12653 Some programmers will argue that it is the same as the precedence
12654 for @code{.EQ.} when applied to numeric (such as @code{INTEGER})
12656 By this interpretation, the subexpression @samp{M.EQ.N} must be
12657 evaluated first in the above program, resulting in a program that,
12658 when run, does not execute the @code{PRINT} statement.
12660 Other programmers will argue that the precedence is the same as
12661 the precedence for @code{.EQV.}, which is restricted by the standards
12662 to @code{LOGICAL} operands.
12663 By this interpretation, the subexpression @samp{L.AND.M} must be
12664 evaluated first, resulting in a program that @emph{does} execute
12665 the @code{PRINT} statement.
12667 Assigning arbitrary semantic interpretations to syntactic expressions
12668 that might legitimately have more than one ``obvious'' interpretation
12669 is generally unwise.
12671 The creators of the various Fortran standards have done a good job
12672 in this case, requiring a distinct set of operators (which have their
12673 own distinct precedence) to compare @code{LOGICAL} operands.
12674 This requirement results in expression syntax with more certain
12675 precedence (without requiring substantial context), making it easier
12676 for programmers to read existing code.
12677 @code{g77} will avoid muddying up elements of the Fortran language
12678 that were well-designed in the first place.
12680 (Ask C programmers about the precedence of expressions such as
12681 @samp{(a) & (b)} and @samp{(a) - (b)}---they cannot even tell
12682 you, without knowing more context, whether the @samp{&} and @samp{-}
12683 operators are infix (binary) or unary!)
12685 @node Order of Side Effects
12686 @subsection Order of Side Effects
12687 @cindex side effects, order of evaluation
12688 @cindex order of evaluation, side effects
12690 @code{g77} does not necessarily produce code that, when run, performs
12691 side effects (such as those performed by function invocations)
12692 in the same order as in some other compiler---or even in the same
12693 order as another version, port, or invocation (using different
12694 command-line options) of @code{g77}.
12696 It is never safe to depend on the order of evaluation of side effects.
12697 For example, an expression like this may very well behave differently
12698 from one compiler to another:
12701 J = IFUNC() - IFUNC()
12705 There is no guarantee that @samp{IFUNC} will be evaluated in any particular
12707 Either invocation might happen first.
12708 If @samp{IFUNC} returns 5 the first time it is invoked, and
12709 returns 12 the second time, @samp{J} might end up with the
12710 value @samp{7}, or it might end up with @samp{-7}.
12712 Generally, in Fortran, procedures with side-effects intended to
12713 be visible to the caller are best designed as @emph{subroutines},
12715 Examples of such side-effects include:
12719 The generation of random numbers
12720 that are intended to influence return values.
12724 (other than internal I/O to local variables).
12727 Updating information in common blocks.
12730 An example of a side-effect that is not intended to be visible
12731 to the caller is a function that maintains a cache of recently
12732 calculated results, intended solely to speed repeated invocations
12733 of the function with identical arguments.
12734 Such a function can be safely used in expressions, because
12735 if the compiler optimizes away one or more calls to the
12736 function, operation of the program is unaffected (aside
12737 from being speeded up).
12739 @node Warnings and Errors
12740 @section Warning Messages and Error Messages
12742 @cindex error messages
12743 @cindex warnings vs errors
12744 @cindex messages, warning and error
12745 The GNU compiler can produce two kinds of diagnostics: errors and
12747 Each kind has a different purpose:
12751 @emph{Errors} report problems that make it impossible to compile your
12753 GNU Fortran reports errors with the source file name, line
12754 number, and column within the line where the problem is apparent.
12757 @emph{Warnings} report other unusual conditions in your code that
12758 @emph{might} indicate a problem, although compilation can (and does)
12760 Warning messages also report the source file name, line number,
12761 and column information,
12762 but include the text @samp{warning:} to distinguish them
12763 from error messages.
12766 Warnings might indicate danger points where you should check to make sure
12767 that your program really does what you intend; or the use of obsolete
12768 features; or the use of nonstandard features of GNU Fortran.
12769 Many warnings are issued only if you ask for them, with one of the
12770 @samp{-W} options (for instance, @samp{-Wall} requests a variety of
12773 @emph{Note:} Currently, the text of the line and a pointer to the column
12774 is printed in most @code{g77} diagnostics.
12775 Probably, as of version 0.6, @code{g77} will
12776 no longer print the text of the source line, instead printing
12777 the column number following the file name and line number in
12778 a form that GNU Emacs recognizes.
12779 This change is expected to speed up and reduce the memory usage
12780 of the @code{g77} compiler.
12782 @c Say this when it is true -- hopefully 0.6, maybe 0.7 or later. --burley
12784 @c GNU Fortran always tries to compile your program if possible; it never
12785 @c gratuitously rejects a program whose meaning is clear merely because
12786 @c (for instance) it fails to conform to a standard. In some cases,
12787 @c however, the Fortran standard specifies that certain extensions are
12788 @c forbidden, and a diagnostic @emph{must} be issued by a conforming
12789 @c compiler. The @samp{-pedantic} option tells GNU Fortran to issue warnings
12790 @c in such cases; @samp{-pedantic-errors} says to make them errors instead.
12791 @c This does not mean that @emph{all} non-ANSI constructs get warnings
12794 @xref{Warning Options,,Options to Request or Suppress Warnings}, for
12795 more detail on these and related command-line options.
12797 @node Open Questions
12798 @chapter Open Questions
12800 Please consider offering useful answers to these questions!
12804 @code{LOC()} and other intrinsics are probably somewhat misclassified.
12805 Is the a need for more precise classification of intrinsics, and if so,
12806 what are the appropriate groupings?
12807 Is there a need to individually
12808 enable/disable/delete/hide intrinsics from the command line?
12812 @chapter Reporting Bugs
12814 @cindex reporting bugs
12816 Your bug reports play an essential role in making GNU Fortran reliable.
12818 When you encounter a problem, the first thing to do is to see if it is
12821 If it isn't known, then you should report the problem.
12823 Reporting a bug might help you by bringing a solution to your problem, or
12825 (If it does not, look in the service directory; see
12827 In any case, the principal function of a bug report is
12828 to help the entire community by making the next version of GNU Fortran work
12830 Bug reports are your contribution to the maintenance of GNU Fortran.
12832 Since the maintainers are very overloaded, we cannot respond to every
12834 However, if the bug has not been fixed, we are likely to
12835 send you a patch and ask you to tell us whether it works.
12837 In order for a bug report to serve its purpose, you must include the
12838 information that makes for fixing the bug.
12841 * Criteria: Bug Criteria. Have you really found a bug?
12842 * Where: Bug Lists. Where to send your bug report.
12843 * Reporting: Bug Reporting. How to report a bug effectively.
12844 * Patches: Sending Patches. How to send a patch for GNU Fortran.
12847 @xref{Trouble,,Known Causes of Trouble with GNU Fortran},
12848 for information on problems we already know about.
12850 @xref{Service,,How To Get Help with GNU Fortran},
12851 for information on where to ask for help.
12854 @section Have You Found a Bug?
12855 @cindex bug criteria
12857 If you are not sure whether you have found a bug, here are some guidelines:
12860 @cindex fatal signal
12863 If the compiler gets a fatal signal, for any input whatever, that is a
12865 Reliable compilers never crash---they just remain obsolete.
12867 @cindex invalid assembly code
12868 @cindex assembly code, invalid
12870 If the compiler produces invalid assembly code, for any input whatever,
12871 @c (except an @code{asm} statement),
12872 that is a compiler bug, unless the
12873 compiler reports errors (not just warnings) which would ordinarily
12874 prevent the assembler from being run.
12876 @cindex undefined behavior
12877 @cindex undefined function value
12879 If the compiler produces valid assembly code that does not correctly
12880 execute the input source code, that is a compiler bug.
12882 However, you must double-check to make sure, because you might have run
12883 into an incompatibility between GNU Fortran and traditional Fortran.
12884 @c (@pxref{Incompatibilities}).
12885 These incompatibilities might be considered
12886 bugs, but they are inescapable consequences of valuable features.
12888 Or you might have a program whose behavior is undefined, which happened
12889 by chance to give the desired results with another Fortran compiler.
12890 It is best to check the relevant Fortran standard thoroughly if
12891 it is possible that the program indeed does something undefined.
12893 After you have localized the error to a single source line, it should
12894 be easy to check for these things.
12895 If your program is correct and well defined, you have found
12898 It might help if, in your submission, you identified the specific
12899 language in the relevant Fortran standard that specifies the
12900 desired behavior, if it isn't likely to be obvious and agreed-upon
12901 by all Fortran users.
12904 If the compiler produces an error message for valid input, that is a
12907 @cindex invalid input
12909 If the compiler does not produce an error message for invalid input,
12910 that is a compiler bug.
12911 However, you should note that your idea of
12912 ``invalid input'' might be someone else's idea
12913 of ``an extension'' or ``support for traditional practice''.
12916 If you are an experienced user of Fortran compilers, your suggestions
12917 for improvement of GNU Fortran are welcome in any case.
12920 Many, perhaps most, bug reports against @code{g77} turn out to
12921 be bugs in the user's code.
12922 While we find such bug reports educational, they sometimes take
12923 a considerable amount of time to track down or at least respond
12924 to---time we could be spending making @code{g77}, not some user's
12927 Some steps you can take to verify that the bug is not certainly
12928 in the code you're compiling with @code{g77}:
12932 Compile your code using the @code{g77} options @samp{-W -Wall -O}.
12933 These options enable many useful warning; the @samp{-O} option
12934 enables flow analysis that enables the uninitialized-variable
12937 If you investigate the warnings and find evidence of possible bugs
12938 in your code, fix them first and retry @code{g77}.
12941 Compile your code using the @code{g77} options @samp{-finit-local-zero},
12942 @samp{-fno-automatic}, @samp{-ffloat-store}, and various
12943 combinations thereof.
12945 If your code works with any of these combinations, that is not
12946 proof that the bug isn't in @code{g77}---a @code{g77} bug exposed
12947 by your code might simply be avoided, or have a different, more subtle
12948 effect, when different options are used---but it can be a
12949 strong indicator that your code is making unwarranted assumptions
12950 about the Fortran dialect and/or underlying machine it is
12951 being compiled and run on.
12953 @xref{Overly Convenient Options,,Overly Convenient Command-Line Options},
12954 for information on the @samp{-fno-automatic} and
12955 @samp{-finit-local-zero} options and how to convert
12956 their use into selective changes in your own code.
12960 Validate your code with @code{ftnchek} or a similar code-checking
12962 @code{ftnchek} can be found at @uref{ftp://ftp.netlib.org/fortran}
12963 or @uref{ftp://ftp.dsm.fordham.edu}.
12966 @cindex Makefile example
12967 Here are some sample @file{Makefile} rules using @code{ftnchek}
12968 ``project'' files to do cross-file checking and @code{sfmakedepend}
12969 (from @uref{ftp://ahab.rutgers.edu/pub/perl/sfmakedepend})
12970 to maintain dependencies automatically.
12971 These assume the use of GNU @code{make}.
12974 # Dummy suffix for ftnchek targets:
12978 # How to compile .f files (for implicit rule):
12980 # Assume `include' directory:
12981 FFLAGS = -Iinclude -g -O -Wall
12983 # Flags for ftnchek:
12984 CHEK1 = -array=0 -include=includes -noarray
12985 CHEK2 = -nonovice -usage=1 -notruncation
12986 CHEKFLAGS = $(CHEK1) $(CHEK2)
12988 # Run ftnchek with all the .prj files except the one corresponding
12989 # to the target's root:
12991 ftnchek $(filter-out $*.prj,$(PRJS)) $(CHEKFLAGS) \
12992 -noextern -library $<
12994 # Derive a project file from a source file:
12996 ftnchek $(CHEKFLAGS) -noextern -project -library $<
12998 # The list of objects is assumed to be in variable OBJS.
12999 # Sources corresponding to the objects:
13000 SRCS = $(OBJS:%.o=%.f)
13001 # ftnchek project files:
13002 PRJS = $(OBJS:%.o=%.prj)
13004 # Build the program
13006 $(FC) -o $@ $(OBJS)
13008 chekall: $(PRJS) ; \
13009 ftnchek $(CHEKFLAGS) $(PRJS)
13013 # For Emacs M-x find-tag:
13017 # Rebuild dependencies:
13019 sfmakedepend -I $(PLTLIBDIR) -I includes -a prj $(SRCS1)
13023 Try your code out using other Fortran compilers, such as @code{f2c}.
13024 If it does not work on at least one other compiler (assuming the
13025 compiler supports the features the code needs), that is a strong
13026 indicator of a bug in the code.
13028 However, even if your code works on many compilers @emph{except}
13029 @code{g77}, that does @emph{not} mean the bug is in @code{g77}.
13030 It might mean the bug is in your code, and that @code{g77} simply
13031 exposes it more readily than other compilers.
13035 @section Where to Report Bugs
13036 @cindex bug report mailing lists
13037 @kindex @value{email-bugs}
13038 Send bug reports for GNU Fortran to @email{@value{email-bugs}}.
13040 Often people think of posting bug reports to a newsgroup instead of
13042 This sometimes appears to work, but it has one problem which can be
13043 crucial: a newsgroup posting does not contain a mail path back to the
13045 Thus, if maintainers need more information, they might be unable
13046 to reach you. For this reason, you should always send bug reports by
13047 mail to the proper mailing list.
13049 As a last resort, send bug reports on paper to:
13053 Free Software Foundation
13054 59 Temple Place - Suite 330
13055 Boston, MA 02111-1307, USA
13058 @node Bug Reporting
13059 @section How to Report Bugs
13060 @cindex compiler bugs, reporting
13062 The fundamental principle of reporting bugs usefully is this:
13063 @strong{report all the facts}.
13064 If you are not sure whether to state a
13065 fact or leave it out, state it!
13067 Often people omit facts because they think they know what causes the
13068 problem and they conclude that some details don't matter.
13070 assume that the name of the variable you use in an example does not matter.
13071 Well, probably it doesn't, but one cannot be sure.
13072 Perhaps the bug is a
13073 stray memory reference which happens to fetch from the location where that
13074 name is stored in memory; perhaps, if the name were different, the contents
13075 of that location would fool the compiler into doing the right thing despite
13077 Play it safe and give a specific, complete example.
13079 easiest thing for you to do, and the most helpful.
13081 Keep in mind that the purpose of a bug report is to enable someone to
13082 fix the bug if it is not known.
13083 It isn't very important what happens if
13084 the bug is already known.
13085 Therefore, always write your bug reports on
13086 the assumption that the bug is not known.
13088 Sometimes people give a few sketchy facts and ask, ``Does this ring a
13090 This cannot help us fix a bug, so it is rarely helpful.
13091 We respond by asking for enough details to enable us to investigate.
13092 You might as well expedite matters by sending them to begin with.
13093 (Besides, there are enough bells ringing around here as it is.)
13095 Try to make your bug report self-contained.
13096 If we have to ask you for
13097 more information, it is best if you include all the previous information
13098 in your response, as well as the information that was missing.
13100 Please report each bug in a separate message.
13101 This makes it easier for
13102 us to track which bugs have been fixed and to forward your bugs reports
13103 to the appropriate maintainer.
13105 Do not compress and encode any part of your bug report using programs
13106 such as @file{uuencode}.
13107 If you do so it will slow down the processing
13109 If you must submit multiple large files, use @file{shar},
13110 which allows us to read your message without having to run any
13111 decompression programs.
13113 (As a special exception for GNU Fortran bug-reporting, at least
13114 for now, if you are sending more than a few lines of code, if
13115 your program's source file format contains ``interesting'' things
13116 like trailing spaces or strange characters, or if you need to
13117 include binary data files, it is acceptable to put all the
13118 files together in a @code{tar} archive, and, whether you need to
13119 do that, it is acceptable to then compress the single file (@code{tar}
13120 archive or source file)
13121 using @code{gzip} and encode it via @code{uuencode}.
13122 Do not use any MIME stuff---the current maintainer can't decode this.
13123 Using @code{compress} instead of @code{gzip} is acceptable, assuming
13124 you have licensed the use of the patented algorithm in
13125 @code{compress} from Unisys.)
13127 To enable someone to investigate the bug, you should include all these
13132 The version of GNU Fortran.
13133 You can get this by running @code{g77} with the @samp{-v} option.
13134 (Ignore any error messages that might be displayed
13135 when the linker is run.)
13137 Without this, we won't know whether there is any point in looking for
13138 the bug in the current version of GNU Fortran.
13141 @cindex preprocessor
13142 @cindex cpp program
13143 @cindex programs, cpp
13145 A complete input file that will reproduce the bug.
13147 If your source file(s) require preprocessing
13148 (for example, their names have suffixes like
13149 @samp{.F}, @samp{.fpp}, @samp{.FPP}, and @samp{.r}),
13150 and the bug is in the compiler proper (@file{f771})
13151 or in a subsequent phase of processing,
13152 run your source file through the C preprocessor
13153 by doing @samp{g77 -E @var{sourcefile} > @var{newfile}}.
13154 Then, include the contents of @var{newfile} in the bug report.
13155 (When you do this, use the same preprocessor options---such as
13156 @samp{-I}, @samp{-D}, and @samp{-U}---that you used in actual
13159 A single statement is not enough of an example.
13160 In order to compile it,
13161 it must be embedded in a complete file of compiler input.
13162 The bug might depend on the details of how this is done.
13164 Without a real example one can compile,
13165 all anyone can do about your bug report is wish you luck.
13166 It would be futile to try to guess how to provoke the bug.
13167 For example, bugs in register allocation and reloading
13168 can depend on every little detail of the source and include files
13172 @cindex included files
13173 @cindex INCLUDE directive
13174 @cindex directive, INCLUDE
13175 @cindex #include directive
13176 @cindex directive, #include
13177 Note that you should include with your bug report any files
13178 included by the source file
13179 (via the @code{#include} or @code{INCLUDE} directive)
13180 that you send, and any files they include, and so on.
13182 It is not necessary to replace
13183 the @code{#include} and @code{INCLUDE} directives
13184 with the actual files in the version of the source file that
13185 you send, but it might make submitting the bug report easier
13187 However, be sure to @emph{reproduce} the bug using the @emph{exact}
13188 version of the source material you submit, to avoid wild-goose
13192 The command arguments you gave GNU Fortran to compile that example
13193 and observe the bug. For example, did you use @samp{-O}? To guarantee
13194 you won't omit something important, list all the options.
13196 If we were to try to guess the arguments, we would probably guess wrong
13197 and then we would not encounter the bug.
13200 The type of machine you are using, and the operating system name and
13202 (Much of this information is printed by @samp{g77 -v}---if you
13203 include that, send along any additional info you have that you
13204 don't see clearly represented in that output.)
13207 The operands you gave to the @code{configure} command when you installed
13211 A complete list of any modifications you have made to the compiler
13212 source. (We don't promise to investigate the bug unless it happens in
13213 an unmodified compiler. But if you've made modifications and don't tell
13214 us, then you are sending us on a wild-goose chase.)
13216 Be precise about these changes. A description in English is not
13217 enough---send a context diff for them.
13219 Adding files of your own (such as a machine description for a machine we
13220 don't support) is a modification of the compiler source.
13223 Details of any other deviations from the standard procedure for installing
13227 A description of what behavior you observe that you believe is
13228 incorrect. For example, ``The compiler gets a fatal signal,'' or,
13229 ``The assembler instruction at line 208 in the output is incorrect.''
13231 Of course, if the bug is that the compiler gets a fatal signal, then one
13232 can't miss it. But if the bug is incorrect output, the maintainer might
13233 not notice unless it is glaringly wrong. None of us has time to study
13234 all the assembler code from a 50-line Fortran program just on the chance that
13235 one instruction might be wrong. We need @emph{you} to do this part!
13237 Even if the problem you experience is a fatal signal, you should still
13238 say so explicitly. Suppose something strange is going on, such as, your
13239 copy of the compiler is out of synch, or you have encountered a bug in
13240 the C library on your system. (This has happened!) Your copy might
13241 crash and the copy here would not. If you @i{said} to expect a crash,
13242 then when the compiler here fails to crash, we would know that the bug
13243 was not happening. If you don't say to expect a crash, then we would
13244 not know whether the bug was happening. We would not be able to draw
13245 any conclusion from our observations.
13247 If the problem is a diagnostic when building GNU Fortran with some other
13248 compiler, say whether it is a warning or an error.
13250 Often the observed symptom is incorrect output when your program is run.
13251 Sad to say, this is not enough information unless the program is short
13252 and simple. None of us has time to study a large program to figure out
13253 how it would work if compiled correctly, much less which line of it was
13254 compiled wrong. So you will have to do that. Tell us which source line
13255 it is, and what incorrect result happens when that line is executed. A
13256 person who understands the program can find this as easily as finding a
13257 bug in the program itself.
13260 If you send examples of assembler code output from GNU Fortran,
13261 please use @samp{-g} when you make them. The debugging information
13262 includes source line numbers which are essential for correlating the
13263 output with the input.
13266 If you wish to mention something in the GNU Fortran source, refer to it by
13267 context, not by line number.
13269 The line numbers in the development sources don't match those in your
13270 sources. Your line numbers would convey no convenient information to the
13274 Additional information from a debugger might enable someone to find a
13275 problem on a machine which he does not have available. However, you
13276 need to think when you collect this information if you want it to have
13277 any chance of being useful.
13279 @cindex backtrace for bug reports
13280 For example, many people send just a backtrace, but that is never
13281 useful by itself. A simple backtrace with arguments conveys little
13282 about GNU Fortran because the compiler is largely data-driven; the same
13283 functions are called over and over for different RTL insns, doing
13284 different things depending on the details of the insn.
13286 Most of the arguments listed in the backtrace are useless because they
13287 are pointers to RTL list structure. The numeric values of the
13288 pointers, which the debugger prints in the backtrace, have no
13289 significance whatever; all that matters is the contents of the objects
13290 they point to (and most of the contents are other such pointers).
13292 In addition, most compiler passes consist of one or more loops that
13293 scan the RTL insn sequence. The most vital piece of information about
13294 such a loop---which insn it has reached---is usually in a local variable,
13295 not in an argument.
13298 What you need to provide in addition to a backtrace are the values of
13299 the local variables for several stack frames up. When a local
13300 variable or an argument is an RTX, first print its value and then use
13301 the GDB command @code{pr} to print the RTL expression that it points
13302 to. (If GDB doesn't run on your machine, use your debugger to call
13303 the function @code{debug_rtx} with the RTX as an argument.) In
13304 general, whenever a variable is a pointer, its value is no use
13305 without the data it points to.
13308 Here are some things that are not necessary:
13312 A description of the envelope of the bug.
13314 Often people who encounter a bug spend a lot of time investigating
13315 which changes to the input file will make the bug go away and which
13316 changes will not affect it.
13318 This is often time consuming and not very useful, because the way we
13319 will find the bug is by running a single example under the debugger with
13320 breakpoints, not by pure deduction from a series of examples. You might
13321 as well save your time for something else.
13323 Of course, if you can find a simpler example to report @emph{instead} of
13324 the original one, that is a convenience. Errors in the output will be
13325 easier to spot, running under the debugger will take less time, etc.
13326 Most GNU Fortran bugs involve just one function, so the most straightforward
13327 way to simplify an example is to delete all the function definitions
13328 except the one where the bug occurs. Those earlier in the file may be
13329 replaced by external declarations if the crucial function depends on
13330 them. (Exception: inline functions might affect compilation of functions
13331 defined later in the file.)
13333 However, simplification is not vital; if you don't want to do this,
13334 report the bug anyway and send the entire test case you used.
13337 In particular, some people insert conditionals @samp{#ifdef BUG} around
13338 a statement which, if removed, makes the bug not happen. These are just
13339 clutter; we won't pay any attention to them anyway. Besides, you should
13340 send us preprocessor output, and that can't have conditionals.
13343 A patch for the bug.
13345 A patch for the bug is useful if it is a good one. But don't omit the
13346 necessary information, such as the test case, on the assumption that a
13347 patch is all we need. We might see problems with your patch and decide
13348 to fix the problem another way, or we might not understand it at all.
13350 Sometimes with a program as complicated as GNU Fortran it is very hard to
13351 construct an example that will make the program follow a certain path
13352 through the code. If you don't send the example, we won't be able to
13353 construct one, so we won't be able to verify that the bug is fixed.
13355 And if we can't understand what bug you are trying to fix, or why your
13356 patch should be an improvement, we won't install it. A test case will
13357 help us to understand.
13359 @xref{Sending Patches}, for guidelines on how to make it easy for us to
13360 understand and install your patches.
13363 A guess about what the bug is or what it depends on.
13365 Such guesses are usually wrong. Even the maintainer can't guess right
13366 about such things without first using the debugger to find the facts.
13371 We have no way of examining a core dump for your type of machine
13372 unless we have an identical system---and if we do have one,
13373 we should be able to reproduce the crash ourselves.
13376 @node Sending Patches
13377 @section Sending Patches for GNU Fortran
13379 If you would like to write bug fixes or improvements for the GNU Fortran
13380 compiler, that is very helpful.
13381 Send suggested fixes to the bug report
13382 mailing list, @email{@value{email-bugs}}.
13384 Please follow these guidelines so we can study your patches efficiently.
13385 If you don't follow these guidelines, your information might still be
13386 useful, but using it will take extra work. Maintaining GNU Fortran is a lot
13387 of work in the best of circumstances, and we can't keep up unless you do
13392 Send an explanation with your changes of what problem they fix or what
13393 improvement they bring about. For a bug fix, just include a copy of the
13394 bug report, and explain why the change fixes the bug.
13396 (Referring to a bug report is not as good as including it, because then
13397 we will have to look it up, and we have probably already deleted it if
13398 we've already fixed the bug.)
13401 Always include a proper bug report for the problem you think you have
13402 fixed. We need to convince ourselves that the change is right before
13403 installing it. Even if it is right, we might have trouble judging it if
13404 we don't have a way to reproduce the problem.
13407 Include all the comments that are appropriate to help people reading the
13408 source in the future understand why this change was needed.
13411 Don't mix together changes made for different reasons.
13412 Send them @emph{individually}.
13414 If you make two changes for separate reasons, then we might not want to
13415 install them both. We might want to install just one. If you send them
13416 all jumbled together in a single set of diffs, we have to do extra work
13417 to disentangle them---to figure out which parts of the change serve
13418 which purpose. If we don't have time for this, we might have to ignore
13419 your changes entirely.
13421 If you send each change as soon as you have written it, with its own
13422 explanation, then the two changes never get tangled up, and we can
13423 consider each one properly without any extra work to disentangle them.
13425 Ideally, each change you send should be impossible to subdivide into
13426 parts that we might want to consider separately, because each of its
13427 parts gets its motivation from the other parts.
13430 Send each change as soon as that change is finished. Sometimes people
13431 think they are helping us by accumulating many changes to send them all
13432 together. As explained above, this is absolutely the worst thing you
13435 Since you should send each change separately, you might as well send it
13436 right away. That gives us the option of installing it immediately if it
13440 Use @samp{diff -c} to make your diffs. Diffs without context are hard
13441 for us to install reliably. More than that, they make it hard for us to
13442 study the diffs to decide whether we want to install them. Unidiff
13443 format is better than contextless diffs, but not as easy to read as
13446 If you have GNU @code{diff}, use @samp{diff -cp}, which shows the name of the
13447 function that each change occurs in.
13448 (The maintainer of GNU Fortran currently uses @samp{diff -rcp2N}.)
13451 Write the change log entries for your changes. We get lots of changes,
13452 and we don't have time to do all the change log writing ourselves.
13454 Read the @file{ChangeLog} file to see what sorts of information to put
13455 in, and to learn the style that we use. The purpose of the change log
13456 is to show people where to find what was changed. So you need to be
13457 specific about what functions you changed; in large functions, it's
13458 often helpful to indicate where within the function the change was.
13460 On the other hand, once you have shown people where to find the change,
13461 you need not explain its purpose. Thus, if you add a new function, all
13462 you need to say about it is that it is new. If you feel that the
13463 purpose needs explaining, it probably does---but the explanation will be
13464 much more useful if you put it in comments in the code.
13466 If you would like your name to appear in the header line for who made
13467 the change, send us the header line.
13470 When you write the fix, keep in mind that we can't install a change that
13471 would break other systems.
13473 People often suggest fixing a problem by changing machine-independent
13474 files such as @file{toplev.c} to do something special that a particular
13475 system needs. Sometimes it is totally obvious that such changes would
13476 break GNU Fortran for almost all users. We can't possibly make a change like
13477 that. At best it might tell us how to write another patch that would
13478 solve the problem acceptably.
13480 Sometimes people send fixes that @emph{might} be an improvement in
13481 general---but it is hard to be sure of this. It's hard to install
13482 such changes because we have to study them very carefully. Of course,
13483 a good explanation of the reasoning by which you concluded the change
13484 was correct can help convince us.
13486 The safest changes are changes to the configuration files for a
13487 particular machine. These are safe because they can't create new bugs
13490 Please help us keep up with the workload by designing the patch in a
13491 form that is good to install.
13495 @chapter How To Get Help with GNU Fortran
13497 If you need help installing, using or changing GNU Fortran, there are two
13502 Look in the service directory for someone who might help you for a fee.
13503 The service directory is found in the file named @file{SERVICE} in the
13504 GNU CC distribution.
13507 Send a message to @email{@value{email-general}}.
13512 @node Adding Options
13513 @chapter Adding Options
13514 @cindex options, adding
13515 @cindex adding options
13517 To add a new command-line option to @code{g77}, first decide
13518 what kind of option you wish to add.
13519 Search the @code{g77} and @code{gcc} documentation for one
13520 or more options that is most closely like the one you want to add
13521 (in terms of what kind of effect it has, and so on) to
13522 help clarify its nature.
13526 @emph{Fortran options} are options that apply only
13527 when compiling Fortran programs.
13528 They are accepted by @code{g77} and @code{gcc}, but
13529 they apply only when compiling Fortran programs.
13532 @emph{Compiler options} are options that apply
13533 when compiling most any kind of program.
13536 @emph{Fortran options} are listed in the file
13537 @file{@value{path-g77}/lang-options.h},
13538 which is used during the build of @code{gcc} to
13539 build a list of all options that are accepted by
13540 at least one language's compiler.
13541 This list goes into the @samp{lang_options} array
13542 in @file{gcc/toplev.c}, which uses this array to
13543 determine whether a particular option should be
13544 offered to the linked-in front end for processing
13545 by calling @samp{lang_option_decode}, which, for
13546 @code{g77}, is in @file{@value{path-g77}/com.c} and just
13547 calls @samp{ffe_decode_option}.
13549 If the linked-in front end ``rejects'' a
13550 particular option passed to it, @file{toplev.c}
13551 just ignores the option, because @emph{some}
13552 language's compiler is willing to accept it.
13554 This allows commands like @samp{gcc -fno-asm foo.c bar.f}
13555 to work, even though Fortran compilation does
13556 not currently support the @samp{-fno-asm} option;
13557 even though the @code{f771} version of @samp{lang_decode_option}
13558 rejects @samp{-fno-asm}, @file{toplev.c} doesn't
13559 produce a diagnostic because some other language (C)
13562 This also means that commands like
13563 @samp{g77 -fno-asm foo.f} yield no diagnostics,
13564 despite the fact that no phase of the command was
13565 able to recognize and process @samp{-fno-asm}---perhaps
13566 a warning about this would be helpful if it were
13569 Code that processes Fortran options is found in
13570 @file{@value{path-g77}/top.c}, function @samp{ffe_decode_option}.
13571 This code needs to check positive and negative forms
13574 The defaults for Fortran options are set in their
13575 global definitions, also found in @file{@value{path-g77}/top.c}.
13576 Many of these defaults are actually macros defined
13577 in @file{@value{path-g77}/target.h}, since they might be
13579 However, since, in practice, GNU compilers
13580 should behave the same way on all configurations
13581 (especially when it comes to language constructs),
13582 the practice of setting defaults in @file{target.h}
13583 is likely to be deprecated and, ultimately, stopped
13584 in future versions of @code{g77}.
13586 Accessor macros for Fortran options, used by code
13587 in the @code{g77} FFE, are defined in @file{@value{path-g77}/top.h}.
13589 @emph{Compiler options} are listed in @file{gcc/toplev.c}
13590 in the array @samp{f_options}.
13591 An option not listed in @samp{lang_options} is
13592 looked up in @samp{f_options} and handled from there.
13594 The defaults for compiler options are set in the
13595 global definitions for the corresponding variables,
13596 some of which are in @file{gcc/toplev.c}.
13598 You can set different defaults for @emph{Fortran-oriented}
13599 or @emph{Fortran-reticent} compiler options by changing
13600 the source code of @code{g77} and rebuilding.
13601 How to do this depends on the version of @code{g77}:
13606 Change the way @code{f771} handles the @samp{-fset-g77-defaults}
13607 option, which is always provided as the first option when
13608 called by @code{g77} or @code{gcc}.
13610 This code is in @samp{ffe_decode_options} in @file{@value{path-g77}/top.c}.
13611 Have it change just the variables that you want to default
13612 to a different setting for Fortran compiles compared to
13613 compiles of other languages.
13615 The @samp{-fset-g77-defaults} option is passed to @code{f771}
13616 automatically because of the specification information
13617 kept in @file{@value{path-g77}/lang-specs.h}.
13618 This file tells the @code{gcc} command how to recognize,
13619 in this case, Fortran source files (those to be preprocessed,
13620 and those that are not), and further, how to invoke the
13621 appropriate programs (including @code{f771}) to process
13622 those source files.
13624 It is in @file{@value{path-g77}/lang-specs.h} that @samp{-fset-g77-defaults},
13625 @samp{-fversion}, and other options are passed, as appropriate,
13626 even when the user has not explicitly specified them.
13627 Other ``internal'' options such as @samp{-quiet} also
13628 are passed via this mechanism.
13632 Change the @samp{lang_init_options} routine in @file{egcs/gcc/f/com.c}.
13634 (Note that these versions of @code{g77}
13635 perform internal consistency checking automatically
13636 when the @samp{-fversion} option is specified.)
13643 If you want to contribute to @code{g77} by doing research,
13644 design, specification, documentation, coding, or testing,
13645 the following information should give you some ideas.
13646 More relevant information might be available from
13647 @uref{ftp://alpha.gnu.org/gnu/g77/projects/}.
13650 * Efficiency:: Make @code{g77} itself compile code faster.
13651 * Better Optimization:: Teach @code{g77} to generate faster code.
13652 * Simplify Porting:: Make @code{g77} easier to configure, build,
13654 * More Extensions:: Features many users won't know to ask for.
13655 * Machine Model:: @code{g77} should better leverage @code{gcc}.
13656 * Internals Documentation:: Make maintenance easier.
13657 * Internals Improvements:: Make internals more robust.
13658 * Better Diagnostics:: Make using @code{g77} on new code easier.
13662 @section Improve Efficiency
13665 Don't bother doing any performance analysis until most of the
13666 following items are taken care of, because there's no question
13667 they represent serious space/time problems, although some of
13668 them show up only given certain kinds of (popular) input.
13672 Improve @samp{malloc} package and its uses to specify more info about
13673 memory pools and, where feasible, use obstacks to implement them.
13676 Skip over uninitialized portions of aggregate areas (arrays,
13677 @code{COMMON} areas, @code{EQUIVALENCE} areas) so zeros need not be output.
13678 This would reduce memory usage for large initialized aggregate
13679 areas, even ones with only one initialized element.
13681 As of version 0.5.18, a portion of this item has already been
13685 Prescan the statement (in @file{sta.c}) so that the nature of the statement
13686 is determined as much as possible by looking entirely at its form,
13687 and not looking at any context (previous statements, including types
13689 This would allow ripping out of the statement-confirmation,
13690 symbol retraction/confirmation, and diagnostic inhibition
13692 Plus, it would result in much-improved diagnostics.
13693 For example, @samp{CALL some-intrinsic(@dots{})}, where the intrinsic
13694 is not a subroutine intrinsic, would result actual error instead of the
13695 unimplemented-statement catch-all.
13698 Throughout @code{g77}, don't pass line/column pairs where
13699 a simple @samp{ffewhere} type, which points to the error as much as is
13700 desired by the configuration, will do, and don't pass @samp{ffelexToken} types
13701 where a simple @samp{ffewhere} type will do.
13702 Then, allow new default
13703 configuration of @samp{ffewhere} such that the source line text is not
13704 preserved, and leave it to things like Emacs' next-error function
13705 to point to them (now that @samp{next-error} supports column,
13706 or, perhaps, character-offset, numbers).
13707 The change in calling sequences should improve performance somewhat,
13708 as should not having to save source lines.
13709 (Whether this whole
13710 item will improve performance is questionable, but it should
13711 improve maintainability.)
13714 Handle @samp{DATA (A(I),I=1,1000000)/1000000*2/} more efficiently, especially
13715 as regards the assembly output.
13716 Some of this might require improving
13717 the back end, but lots of improvement in space/time required in @code{g77}
13718 itself can be fairly easily obtained without touching the back end.
13719 Maybe type-conversion, where necessary, can be speeded up as well in
13720 cases like the one shown (converting the @samp{2} into @samp{2.}).
13723 If analysis shows it to be worthwhile, optimize @file{lex.c}.
13726 Consider redesigning @file{lex.c} to not need any feedback
13727 during tokenization, by keeping track of enough parse state on its
13731 @node Better Optimization
13732 @section Better Optimization
13733 @cindex optimization, better
13734 @cindex code generation, improving
13736 Much of this work should be put off until after @code{g77} has
13737 all the features necessary for its widespread acceptance as a
13738 useful F77 compiler.
13739 However, perhaps this work can be done in parallel during
13740 the feature-adding work.
13744 Do the equivalent of the trick of putting @samp{extern inline} in front
13745 of every function definition in @code{libg2c} and #include'ing the resulting
13746 file in @code{f2c}+@code{gcc}---that is, inline all run-time-library functions
13747 that are at all worth inlining.
13748 (Some of this has already been done, such as for integral exponentiation.)
13751 When doing @samp{CHAR_VAR = CHAR_FUNC(@dots{})},
13752 and it's clear that types line up
13753 and @samp{CHAR_VAR} is addressable or not a @samp{VAR_DECL},
13754 make @samp{CHAR_VAR}, not a
13755 temporary, be the receiver for @samp{CHAR_FUNC}.
13756 (This is now done for @code{COMPLEX} variables.)
13759 Design and implement Fortran-specific optimizations that don't
13760 really belong in the back end, or where the front end needs to
13761 give the back end more info than it currently does.
13764 Design and implement a new run-time library interface, with the
13765 code going into @code{libgcc} so no special linking is required to
13766 link Fortran programs using standard language features.
13768 would speed up lots of things, from I/O (using precompiled formats,
13769 doing just one, or, at most, very few, calls for arrays or array sections,
13770 and so on) to general computing (array/section implementations of
13771 various intrinsics, implementation of commonly performed loops that
13772 aren't likely to be optimally compiled otherwise, etc.).
13774 Among the important things the library would do are:
13778 Be a one-stop-shop-type
13779 library, hence shareable and usable by all, in that what are now
13780 library-build-time options in @code{libg2c} would be moved at least to the
13781 @code{g77} compile phase, if not to finer grains (such as choosing how
13782 list-directed I/O formatting is done by default at @code{OPEN} time, for
13783 preconnected units via options or even statements in the main program
13784 unit, maybe even on a per-I/O basis with appropriate pragma-like
13789 Probably requiring the new library design, change interface to
13790 normally have @code{COMPLEX} functions return their values in the way
13791 @code{gcc} would if they were declared @code{__complex__ float},
13793 the mechanism currently used by @code{CHARACTER} functions (whereby the
13794 functions are compiled as returning void and their first arg is
13795 a pointer to where to store the result).
13796 (Don't append underscores to
13797 external names for @code{COMPLEX} functions in some cases once @code{g77} uses
13798 @code{gcc} rather than @code{f2c} calling conventions.)
13801 Do something useful with @samp{doiter} references where possible.
13802 For example, @samp{CALL FOO(I)} cannot modify @samp{I} if within
13803 a @code{DO} loop that uses @samp{I} as the
13804 iteration variable, and the back end might find that info useful
13805 in determining whether it needs to read @samp{I} back into a register after
13807 (It normally has to do that, unless it knows @samp{FOO} never
13808 modifies its passed-by-reference argument, which is rarely the case
13809 for Fortran-77 code.)
13812 @node Simplify Porting
13813 @section Simplify Porting
13814 @cindex porting, simplify
13815 @cindex simplify porting
13817 Making @code{g77} easier to configure, port, build, and install, either
13818 as a single-system compiler or as a cross-compiler, would be
13823 A new library (replacing @code{libg2c}) should improve portability as well as
13824 produce more optimal code.
13825 Further, @code{g77} and the new library should
13826 conspire to simplify naming of externals, such as by removing unnecessarily
13827 added underscores, and to reduce/eliminate the possibility of naming
13828 conflicts, while making debugger more straightforward.
13831 make multi-language applications more feasible, such as by providing
13832 Fortran intrinsics that get Fortran unit numbers given C @code{FILE *}
13836 Possibly related to a new library, @code{g77} should produce the equivalent
13837 of a @code{gcc} @samp{main(argc, argv)} function when it compiles a
13838 main program unit, instead of compiling something that must be
13839 called by a library
13840 implementation of @code{main()}.
13842 This would do many useful things such as
13843 provide more flexibility in terms of setting up exception handling,
13844 not requiring programmers to start their debugging sessions with
13845 @kbd{breakpoint MAIN__} followed by @kbd{run}, and so on.
13848 The GBE needs to understand the difference between alignment
13849 requirements and desires.
13850 For example, on Intel x86 machines, @code{g77} currently imposes
13851 overly strict alignment requirements, due to the back end, but it
13852 would be useful for Fortran and C programmers to be able to override
13853 these @emph{recommendations} as long as they don't violate the actual
13854 processor @emph{requirements}.
13857 @node More Extensions
13858 @section More Extensions
13859 @cindex extensions, more
13861 These extensions are not the sort of things users ask for ``by name'',
13862 but they might improve the usability of @code{g77}, and Fortran in
13863 general, in the long run.
13864 Some of these items really pertain to improving @code{g77} internals
13865 so that some popular extensions can be more easily supported.
13869 Look through all the documentation on the GNU Fortran language,
13870 dialects, compiler, missing features, bugs, and so on.
13871 Many mentions of incomplete or missing features are
13872 sprinkled throughout.
13873 It is not worth repeating them here.
13876 @cindex concatenation
13877 @cindex CHARACTER*(*)
13878 @cindex run-time, dynamic allocation
13879 Support arbitrary operands for concatenation, even in contexts where
13880 run-time allocation is required.
13886 CALL FOO(A // 'suffix')
13890 Consider adding a @code{NUMERIC} type to designate typeless numeric constants,
13892 The idea is to provide a forward-looking, effective
13893 replacement for things like the old-style @code{PARAMETER} statement
13895 really need typelessness in a maintainable, portable, clearly documented
13897 Maybe @code{TYPELESS} would include @code{CHARACTER}, @code{POINTER},
13898 and whatever else might come along.
13899 (This is not really a call for polymorphism per se, just
13900 an ability to express limited, syntactic polymorphism.)
13903 Support @samp{OPEN(@dots{},KEY=(@dots{}),@dots{})}.
13906 Support arbitrary file unit numbers, instead of limiting them
13907 to 0 through @samp{MXUNIT-1}.
13908 (This is a @code{libg2c} issue.)
13911 @samp{OPEN(NOSPANBLOCKS,@dots{})} is treated as
13912 @samp{OPEN(UNIT=NOSPANBLOCKS,@dots{})}, so a
13913 later @code{UNIT=} in the first example is invalid.
13914 Make sure this is what users of this feature would expect.
13917 Currently @code{g77} disallows @samp{READ(1'10)} since
13918 it is an obnoxious syntax, but
13919 supporting it might be pretty easy if needed.
13920 More details are needed, such
13921 as whether general expressions separated by an apostrophe are supported,
13922 or maybe the record number can be a general expression, and so on.
13925 Support @code{STRUCTURE}, @code{UNION}, @code{MAP}, and @code{RECORD}
13927 Currently there is no support at all
13928 for @code{%FILL} in @code{STRUCTURE} and related syntax,
13929 whereas the rest of the
13930 stuff has at least some parsing support.
13931 This requires either major
13932 changes to @code{libg2c} or its replacement.
13935 F90 and @code{g77} probably disagree about label scoping relative to
13936 @code{INTERFACE} and @code{END INTERFACE}, and their contained
13937 procedure interface bodies (blocks?).
13940 @code{ENTRY} doesn't support F90 @code{RESULT()} yet,
13941 since that was added after S8.112.
13944 Empty-statement handling (10 ;;CONTINUE;;) probably isn't consistent
13945 with the final form of the standard (it was vague at S8.112).
13948 It seems to be an ``open'' question whether a file, immediately after being
13949 @code{OPEN}ed,is positioned at the beginning, the end, or wherever---it
13950 might be nice to offer an option of opening to ``undefined'' status, requiring
13951 an explicit absolute-positioning operation to be performed before any
13952 other (besides @code{CLOSE}) to assist in making applications port to systems
13953 (some IBM?) that @code{OPEN} to the end of a file or some such thing.
13956 @node Machine Model
13957 @section Machine Model
13959 This items pertain to generalizing @code{g77}'s view of
13960 the machine model to more fully accept whatever the GBE
13961 provides it via its configuration.
13965 Switch to using @samp{REAL_VALUE_TYPE} to represent floating-point constants
13966 exclusively so the target float format need not be required.
13968 means changing the way @code{g77} handles initialization of aggregate areas
13969 having more than one type, such as @code{REAL} and @code{INTEGER},
13971 it initializes them as if they were arrays of @code{char} and uses the
13972 bit patterns of the constants of the various types in them to determine
13973 what to stuff in elements of the arrays.
13976 Rely more and more on back-end info and capabilities, especially in the
13977 area of constants (where having the @code{g77} front-end's IL just store
13978 the appropriate tree nodes containing constants might be best).
13981 Suite of C and Fortran programs that a user/administrator can run on a
13982 machine to help determine the configuration for @code{g77} before building
13983 and help determine if the compiler works (especially with whatever
13984 libraries are installed) after building.
13987 @node Internals Documentation
13988 @section Internals Documentation
13990 Better info on how @code{g77} works and how to port it is needed.
13991 Much of this should be done only after the redesign planned for
13994 @node Internals Improvements
13995 @section Internals Improvements
13997 Some more items that would make @code{g77} more reliable
13998 and easier to maintain:
14002 Generally make expression handling focus
14003 more on critical syntax stuff, leaving semantics to callers.
14005 anything a caller can check, semantically, let it do so, rather
14006 than having @file{expr.c} do it.
14007 (Exceptions might include things like
14008 diagnosing @samp{FOO(I--K:)=BAR} where @samp{FOO} is a @code{PARAMETER}---if
14010 important to preserve the left-to-right-in-source order of production
14014 Come up with better naming conventions for @samp{-D} to establish requirements
14015 to achieve desired implementation dialect via @file{proj.h}.
14018 Clean up used tokens and @samp{ffewhere}s in @samp{ffeglobal_terminate_1}.
14021 Replace @file{sta.c} @samp{outpooldisp} mechanism with @samp{malloc_pool_use}.
14024 Check for @samp{opANY} in more places in @file{com.c}, @file{std.c},
14025 and @file{ste.c}, and get rid of the @samp{opCONVERT(opANY)} kludge
14026 (after determining if there is indeed no real need for it).
14029 Utility to read and check @file{bad.def} messages and their references in the
14030 code, to make sure calls are consistent with message templates.
14033 Search and fix @samp{&ffe@dots{}} and similar so that
14034 @samp{ffe@dots{}ptr@dots{}} macros are
14035 available instead (a good argument for wishing this could have written all
14036 this stuff in C++, perhaps).
14037 On the other hand, it's questionable whether this sort of
14038 improvement is really necessary, given the availability of
14039 tools such as Emacs and Perl, which make finding any
14040 address-taking of structure members easy enough?
14043 Some modules truly export the member names of their structures (and the
14044 structures themselves), maybe fix this, and fix other modules that just
14045 appear to as well (by appending @samp{_}, though it'd be ugly and probably
14046 not worth the time).
14049 Implement C macros @samp{RETURNS(value)} and @samp{SETS(something,value)}
14051 and use them throughout @code{g77} source code (especially in the definitions
14052 of access macros in @samp{.h} files) so they can be tailored
14053 to catch code writing into a @samp{RETURNS()} or reading from a @samp{SETS()}.
14056 Decorate throughout with @code{const} and other such stuff.
14059 All F90 notational derivations in the source code are still based
14060 on the S8.112 version of the draft standard.
14061 Probably should update
14062 to the official standard, or put documentation of the rules as used
14063 in the code@dots{}uh@dots{}in the code.
14066 Some @samp{ffebld_new} calls (those outside of @file{ffeexpr.c} or
14067 inside but invoked via paths not involving @samp{ffeexpr_lhs} or
14068 @samp{ffeexpr_rhs}) might be creating things
14069 in improper pools, leading to such things staying around too long or
14070 (doubtful, but possible and dangerous) not long enough.
14073 Some @samp{ffebld_list_new} (or whatever) calls might not be matched by
14074 @samp{ffebld_list_bottom} (or whatever) calls, which might someday matter.
14075 (It definitely is not a problem just yet.)
14078 Probably not doing clean things when we fail to @code{EQUIVALENCE} something
14079 due to alignment/mismatch or other problems---they end up without
14080 @samp{ffestorag} objects, so maybe the backend (and other parts of the front
14081 end) can notice that and handle like an @samp{opANY} (do what it wants, just
14082 don't complain or crash).
14083 Most of this seems to have been addressed
14084 by now, but a code review wouldn't hurt.
14087 @node Better Diagnostics
14088 @section Better Diagnostics
14090 These are things users might not ask about, or that need to
14091 be looked into, before worrying about.
14092 Also here are items that involve reducing unnecessary diagnostic
14097 When @code{FUNCTION} and @code{ENTRY} point types disagree (@code{CHARACTER}
14098 lengths, type classes, and so on),
14099 @samp{ANY}-ize the offending @code{ENTRY} point and any @emph{new} dummies
14103 Speed up and improve error handling for data when repeat-count is
14105 For example, don't output 20 unnecessary messages after the
14106 first necessary one for:
14111 DATA (X(I), J= 1, 20) /20*5/
14116 (The @code{CONTINUE} statement ensures the @code{DATA} statement
14117 is processed in the context of executable, not specification,
14124 @chapter Diagnostics
14125 @cindex diagnostics
14127 Some diagnostics produced by @code{g77} require sufficient explanation
14128 that the explanations are given below, and the diagnostics themselves
14129 identify the appropriate explanation.
14131 Identification uses the GNU Info format---specifically, the @code{info}
14132 command that displays the explanation is given within square
14133 brackets in the diagnostic.
14137 foo.f:5: Invalid statement [info -f g77 M FOOEY]
14140 More details about the above diagnostic is found in the @code{g77} Info
14141 documentation, menu item @samp{M}, submenu item @samp{FOOEY},
14142 which is displayed by typing the UNIX command
14143 @samp{info -f g77 M FOOEY}.
14145 Other Info readers, such as EMACS, may be just as easily used to display
14146 the pertinent node.
14147 In the above example, @samp{g77} is the Info document name,
14148 @samp{M} is the top-level menu item to select,
14149 and, in that node (named @samp{Diagnostics}, the name of
14150 this chapter, which is the very text you're reading now),
14151 @samp{FOOEY} is the menu item to select.
14154 In this printed version of the @code{g77} manual, the above example
14155 points to a section, below, entitled @samp{FOOEY}---though, of course,
14156 as the above is just a sample, no such section exists.
14160 * CMPAMBIG:: Ambiguous use of intrinsic.
14161 * EXPIMP:: Intrinsic used explicitly and implicitly.
14162 * INTGLOB:: Intrinsic also used as name of global.
14163 * LEX:: Various lexer messages
14164 * GLOBALS:: Disagreements about globals.
14165 * LINKFAIL:: When linking @samp{f771} fails.
14166 * Y2KBAD:: Use of non-Y2K-compliant intrinsic.
14170 @section @code{CMPAMBIG}
14174 Ambiguous use of intrinsic @var{intrinsic} @dots{}
14177 The type of the argument to the invocation of the @var{intrinsic}
14178 intrinsic is a @code{COMPLEX} type other than @code{COMPLEX(KIND=1)}.
14179 Typically, it is @code{COMPLEX(KIND=2)}, also known as
14180 @code{DOUBLE COMPLEX}.
14182 The interpretation of this invocation depends on the particular
14183 dialect of Fortran for which the code was written.
14184 Some dialects convert the real part of the argument to
14185 @code{REAL(KIND=1)}, thus losing precision; other dialects,
14186 and Fortran 90, do no such conversion.
14188 So, GNU Fortran rejects such invocations except under certain
14189 circumstances, to avoid making an incorrect assumption that results
14190 in generating the wrong code.
14192 To determine the dialect of the program unit, perhaps even whether
14193 that particular invocation is properly coded, determine how the
14194 result of the intrinsic is used.
14196 The result of @var{intrinsic} is expected (by the original programmer)
14197 to be @code{REAL(KIND=1)} (the non-Fortran-90 interpretation) if:
14201 It is passed as an argument to a procedure that explicitly or
14202 implicitly declares that argument @code{REAL(KIND=1)}.
14205 a procedure with no @code{DOUBLE PRECISION} or @code{IMPLICIT DOUBLE PRECISION}
14206 statement specifying the dummy argument corresponding to an
14207 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14208 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14209 expected @samp{REAL(Z)} to return @code{REAL(KIND=1)} instead
14210 of @code{REAL(KIND=2)}.
14213 It is used in a context that would otherwise not include
14214 any @code{REAL(KIND=2)} but where treating the @var{intrinsic}
14215 invocation as @code{REAL(KIND=2)} would result in unnecessary
14216 promotions and (typically) more expensive operations on the
14227 The above example suggests the programmer expected the real part
14228 of @samp{Z} to be converted to @code{REAL(KIND=1)} before being
14229 multiplied by @samp{T} (presumed, along with @samp{R} above, to
14230 be type @code{REAL(KIND=1)}).
14232 Otherwise, the conversion would have to be delayed until after
14233 the multiplication, requiring not only an extra conversion
14234 (of @samp{T} to @code{REAL(KIND=2)}), but a (typically) more
14235 expensive multiplication (a double-precision multiplication instead
14236 of a single-precision one).
14239 The result of @var{intrinsic} is expected (by the original programmer)
14240 to be @code{REAL(KIND=2)} (the Fortran 90 interpretation) if:
14244 It is passed as an argument to a procedure that explicitly or
14245 implicitly declares that argument @code{REAL(KIND=2)}.
14247 For example, a procedure specifying a @code{DOUBLE PRECISION}
14248 dummy argument corresponding to an
14249 actual argument of @samp{REAL(Z)}, where @samp{Z} is declared
14250 @code{DOUBLE COMPLEX}, strongly suggests that the programmer
14251 expected @samp{REAL(Z)} to return @code{REAL(KIND=2)} instead
14252 of @code{REAL(KIND=1)}.
14255 It is used in an expression context that includes
14256 other @code{REAL(KIND=2)} operands,
14257 or is assigned to a @code{REAL(KIND=2)} variable or array element.
14263 DOUBLE PRECISION R, T
14268 The above example suggests the programmer expected the real part
14269 of @samp{Z} to @emph{not} be converted to @code{REAL(KIND=1)}
14270 by the @code{REAL()} intrinsic.
14272 Otherwise, the conversion would have to be immediately followed
14273 by a conversion back to @code{REAL(KIND=2)}, losing
14274 the original, full precision of the real part of @code{Z},
14275 before being multiplied by @samp{T}.
14278 Once you have determined whether a particular invocation of @var{intrinsic}
14279 expects the Fortran 90 interpretation, you can:
14283 Change it to @samp{DBLE(@var{expr})} (if @var{intrinsic} is
14284 @samp{REAL}) or @samp{DIMAG(@var{expr})} (if @var{intrinsic}
14286 if it expected the Fortran 90 interpretation.
14288 This assumes @var{expr} is @code{COMPLEX(KIND=2)}---if it is
14289 some other type, such as @code{COMPLEX*32}, you should use the
14290 appropriate intrinsic, such as the one to convert to @code{REAL*16}
14291 (perhaps @code{DBLEQ()} in place of @code{DBLE()}, and
14292 @code{QIMAG()} in place of @code{DIMAG()}).
14295 Change it to @samp{REAL(@var{intrinsic}(@var{expr}))},
14297 This converts to @code{REAL(KIND=1)} in all working
14301 If you don't want to change the code, and you are certain that all
14302 ambiguous invocations of @var{intrinsic} in the source file have
14303 the same expectation regarding interpretation, you can:
14307 Compile with the @code{g77} option @samp{-ff90}, to enable the
14308 Fortran 90 interpretation.
14311 Compile with the @code{g77} options @samp{-fno-f90 -fugly-complex},
14312 to enable the non-Fortran-90 interpretations.
14315 @xref{REAL() and AIMAG() of Complex}, for more information on this
14318 Note: If the above suggestions don't produce enough evidence
14319 as to whether a particular program expects the Fortran 90
14320 interpretation of this ambiguous invocation of @var{intrinsic},
14321 there is one more thing you can try.
14323 If you have access to most or all the compilers used on the
14324 program to create successfully tested and deployed executables,
14325 read the documentation for, and @emph{also} test out, each compiler
14326 to determine how it treats the @var{intrinsic} intrinsic in
14328 (If all the compilers don't agree on an interpretation, there
14329 might be lurking bugs in the deployed versions of the program.)
14331 The following sample program might help:
14333 @cindex JCB003 program
14337 C Written by James Craig Burley 1997-02-23.
14339 C Determine how compilers handle non-standard REAL
14340 C and AIMAG on DOUBLE COMPLEX operands.
14348 IF (R .NE. 0.) PRINT *, 'REAL() is Fortran 90'
14349 IF (R .EQ. 0.) PRINT *, 'REAL() is not Fortran 90'
14353 IF (R .NE. 0.) PRINT *, 'AIMAG() is Fortran 90'
14354 IF (R .EQ. 0.) PRINT *, 'AIMAG() is not Fortran 90'
14357 C Just to make sure compiler doesn't use naive flow
14358 C analysis to optimize away careful work above,
14359 C which might invalidate results....
14361 SUBROUTINE DUMDUM(Z, R)
14367 If the above program prints contradictory results on a
14368 particular compiler, run away!
14371 @section @code{EXPIMP}
14375 Intrinsic @var{intrinsic} referenced @dots{}
14378 The @var{intrinsic} is explicitly declared in one program
14379 unit in the source file and implicitly used as an intrinsic
14380 in another program unit in the same source file.
14382 This diagnostic is designed to catch cases where a program
14383 might depend on using the name @var{intrinsic} as an intrinsic
14384 in one program unit and as a global name (such as the name
14385 of a subroutine or function) in another, but @code{g77} recognizes
14386 the name as an intrinsic in both cases.
14388 After verifying that the program unit making implicit use
14389 of the intrinsic is indeed written expecting the intrinsic,
14390 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14391 program unit to prevent this warning.
14393 This and related warnings are disabled by using
14394 the @samp{-Wno-globals} option when compiling.
14396 Note that this warning is not issued for standard intrinsics.
14397 Standard intrinsics include those described in the FORTRAN 77
14398 standard and, if @samp{-ff90} is specified, those described
14399 in the Fortran 90 standard.
14400 Such intrinsics are not as likely to be confused with user
14401 procedures as intrinsics provided as extensions to the
14402 standard by @code{g77}.
14405 @section @code{INTGLOB}
14409 Same name `@var{intrinsic}' given @dots{}
14412 The name @var{intrinsic} is used for a global entity (a common
14413 block or a program unit) in one program unit and implicitly
14414 used as an intrinsic in another program unit.
14416 This diagnostic is designed to catch cases where a program
14417 intends to use a name entirely as a global name, but @code{g77}
14418 recognizes the name as an intrinsic in the program unit that
14419 references the name, a situation that would likely produce
14425 INTEGER FUNCTION TIME()
14431 PRINT *, 'Time is ', TIME()
14435 The above example defines a program unit named @samp{TIME}, but
14436 the reference to @samp{TIME} in the main program unit @samp{SAMP}
14437 is normally treated by @code{g77} as a reference to the intrinsic
14438 @code{TIME()} (unless a command-line option that prevents such
14439 treatment has been specified).
14441 As a result, the program @samp{SAMP} will @emph{not}
14442 invoke the @samp{TIME} function in the same source file.
14444 Since @code{g77} recognizes @code{libU77} procedures as
14445 intrinsics, and since some existing code uses the same names
14446 for its own procedures as used by some @code{libU77}
14447 procedures, this situation is expected to arise often enough
14448 to make this sort of warning worth issuing.
14450 After verifying that the program unit making implicit use
14451 of the intrinsic is indeed written expecting the intrinsic,
14452 add an @samp{INTRINSIC @var{intrinsic}} statement to that
14453 program unit to prevent this warning.
14455 Or, if you believe the program unit is designed to invoke the
14456 program-defined procedure instead of the intrinsic (as
14457 recognized by @code{g77}), add an @samp{EXTERNAL @var{intrinsic}}
14458 statement to the program unit that references the name to
14459 prevent this warning.
14461 This and related warnings are disabled by using
14462 the @samp{-Wno-globals} option when compiling.
14464 Note that this warning is not issued for standard intrinsics.
14465 Standard intrinsics include those described in the FORTRAN 77
14466 standard and, if @samp{-ff90} is specified, those described
14467 in the Fortran 90 standard.
14468 Such intrinsics are not as likely to be confused with user
14469 procedures as intrinsics provided as extensions to the
14470 standard by @code{g77}.
14473 @section @code{LEX}
14477 Unrecognized character @dots{}
14478 Invalid first character @dots{}
14479 Line too long @dots{}
14480 Non-numeric character @dots{}
14481 Continuation indicator @dots{}
14482 Label at @dots{} invalid with continuation line indicator @dots{}
14483 Character constant @dots{}
14484 Continuation line @dots{}
14485 Statement at @dots{} begins with invalid token
14488 Although the diagnostics identify specific problems, they can
14489 be produced when general problems such as the following occur:
14493 The source file contains something other than Fortran code.
14495 If the code in the file does not look like many of the examples
14496 elsewhere in this document, it might not be Fortran code.
14497 (Note that Fortran code often is written in lower case letters,
14498 while the examples in this document use upper case letters,
14499 for stylistic reasons.)
14501 For example, if the file contains lots of strange-looking
14502 characters, it might be APL source code; if it contains lots
14503 of parentheses, it might be Lisp source code; if it
14504 contains lots of bugs, it might be C++ source code.
14507 The source file contains free-form Fortran code, but @samp{-ffree-form}
14508 was not specified on the command line to compile it.
14510 Free form is a newer form for Fortran code.
14511 The older, classic form is called fixed form.
14513 @cindex continuation character
14514 @cindex characters, continuation
14515 Fixed-form code is visually fairly distinctive, because
14516 numerical labels and comments are all that appear in
14517 the first five columns of a line, the sixth column is
14518 reserved to denote continuation lines,
14519 and actual statements start at or beyond column 7.
14520 Spaces generally are not significant, so if you
14521 see statements such as @samp{REALX,Y} and @samp{DO10I=1,100},
14522 you are looking at fixed-form code.
14525 Comment lines are indicated by the letter @samp{C} or the symbol
14526 @samp{*} in column 1.
14527 @cindex trailing comment
14529 @cindex characters, comment
14531 @cindex exclamation point
14532 (Some code uses @samp{!} or @samp{/*} to begin in-line comments,
14533 which many compilers support.)
14535 Free-form code is distinguished from fixed-form source
14536 primarily by the fact that statements may start anywhere.
14537 (If lots of statements start in columns 1 through 6,
14538 that's a strong indicator of free-form source.)
14539 Consecutive keywords must be separated by spaces, so
14540 @samp{REALX,Y} is not valid, while @samp{REAL X,Y} is.
14541 There are no comment lines per se, but @samp{!} starts a
14542 comment anywhere in a line (other than within a character or
14543 Hollerith constant).
14545 @xref{Source Form}, for more information.
14548 The source file is in fixed form and has been edited without
14549 sensitivity to the column requirements.
14551 Statements in fixed-form code must be entirely contained within
14552 columns 7 through 72 on a given line.
14553 Starting them ``early'' is more likely to result in diagnostics
14554 than finishing them ``late'', though both kinds of errors are
14555 often caught at compile time.
14557 For example, if the following code fragment is edited by following
14558 the commented instructions literally, the result, shown afterward,
14559 would produce a diagnostic when compiled:
14562 C On XYZZY systems, remove "C" on next line:
14566 The result of editing the above line might be:
14569 C On XYZZY systems, remove "C" on next line:
14573 However, that leaves the first @samp{C} in the @samp{CALL}
14574 statement in column 6, making it a comment line, which is
14575 not really what the author intended, and which is likely
14576 to result in one of the above-listed diagnostics.
14578 @emph{Replacing} the @samp{C} in column 1 with a space
14579 is the proper change to make, to ensure the @samp{CALL}
14580 keyword starts in or after column 7.
14582 Another common mistake like this is to forget that fixed-form
14583 source lines are significant through only column 72, and that,
14584 normally, any text beyond column 72 is ignored or is diagnosed
14587 @xref{Source Form}, for more information.
14590 The source file requires preprocessing, and the preprocessing
14591 is not being specified at compile time.
14593 A source file containing lines beginning with @code{#define},
14594 @code{#include}, @code{#if}, and so on is likely one that
14595 requires preprocessing.
14597 If the file's suffix is @samp{.f}, @samp{.for}, or @samp{.FOR},
14598 the file normally will be compiled @emph{without} preprocessing
14601 Change the file's suffix from @samp{.f} to @samp{.F}
14602 (or, on systems with case-insensitive file names,
14603 to @samp{.fpp} or @samp{.FPP}),
14604 from @samp{.for} to @samp{.fpp},
14605 or from @samp{.FOR} to @samp{.FPP}.
14606 @code{g77} compiles files with such names @emph{with}
14610 @cindex preprocessor
14611 @cindex cpp program
14612 @cindex programs, cpp
14613 @cindex @samp{-x f77-cpp-input} option
14614 @cindex options, @samp{-x f77-cpp-input}
14615 Or, learn how to use @code{gcc}'s @samp{-x} option to specify
14616 the language @samp{f77-cpp-input} for Fortran files that
14617 require preprocessing.
14618 @xref{Overall Options,,gcc,Using and Porting GNU CC}.
14621 The source file is preprocessed, and the results of preprocessing
14622 result in syntactic errors that are not necessarily obvious to
14623 someone examining the source file itself.
14625 Examples of errors resulting from preprocessor macro expansion
14626 include exceeding the line-length limit, improperly starting,
14627 terminating, or incorporating the apostrophe or double-quote in
14628 a character constant, improperly forming a Hollerith constant,
14631 @xref{Overall Options,,Options Controlling the Kind of Output},
14632 for suggestions about how to use, and not use, preprocessing
14637 @section @code{GLOBALS}
14641 Global name @var{name} defined at @dots{} already defined@dots{}
14642 Global name @var{name} at @dots{} has different type@dots{}
14643 Too many arguments passed to @var{name} at @dots{}
14644 Too few arguments passed to @var{name} at @dots{}
14645 Argument #@var{n} of @var{name} is @dots{}
14648 These messages all identify disagreements about the
14649 global procedure named @var{name} among different program units
14650 (usually including @var{name} itself).
14652 Whether a particular disagreement is reported
14653 as a warning or an error
14654 can depend on the relative order
14655 of the disagreeing portions of the source file.
14657 Disagreements between a procedure invocation
14658 and the @emph{subsequent} procedure itself
14659 are, usually, diagnosed as errors
14660 when the procedure itself @emph{precedes} the invocation.
14661 Other disagreements are diagnosed via warnings.
14663 @cindex forward references
14664 @cindex in-line code
14665 @cindex compilation, in-line
14666 This distinction, between warnings and errors,
14667 is due primarily to the present tendency of the @code{gcc} back end
14668 to inline only those procedure invocations that are
14669 @emph{preceded} by the corresponding procedure definitions.
14670 If the @code{gcc} back end is changed
14671 to inline ``forward references'',
14672 in which invocations precede definitions,
14673 the @code{g77} front end will be changed
14674 to treat both orderings as errors, accordingly.
14676 The sorts of disagreements that are diagnosed by @code{g77} include
14677 whether a procedure is a subroutine or function;
14678 if it is a function, the type of the return value of the procedure;
14679 the number of arguments the procedure accepts;
14680 and the type of each argument.
14682 Disagreements regarding global names among program units
14683 in a Fortran program @emph{should} be fixed in the code itself.
14684 However, if that is not immediately practical,
14685 and the code has been working for some time,
14686 it is possible it will work
14687 when compiled with the @samp{-fno-globals} option.
14689 The @samp{-fno-globals} option
14690 causes these diagnostics to all be warnings
14691 and disables all inlining of references to global procedures
14692 (to avoid subsequent compiler crashes and bad-code generation).
14693 Use of the @samp{-Wno-globals} option as well as @samp{-fno-globals}
14694 suppresses all of these diagnostics.
14695 (@samp{-Wno-globals} by itself disables only the warnings,
14698 After using @samp{-fno-globals} to work around these problems,
14699 it is wise to stop using that option and address them by fixing
14700 the Fortran code, because such problems, while they might not
14701 actually result in bugs on some systems, indicate that the code
14702 is not as portable as it could be.
14703 In particular, the code might appear to work on a particular
14704 system, but have bugs that affect the reliability of the data
14705 without exhibiting any other outward manifestations of the bugs.
14708 @section @code{LINKFAIL}
14712 If the above command failed due to an unresolved reference
14713 to strtoul, _strtoul, bsearch, _bsearch, or similar, see
14714 [info -f g77 M LINKFAIL] (a node in the g77 documentation)
14715 for information on what causes this, how to work around
14716 the problem by editing $@{srcdir@}/proj.c, and what else to do.
14719 @xref{Missing strtoul or bsearch}, for more information on
14721 which occurs only in releases of @code{g77}
14722 based on @code{gcc}.
14723 (It does not occur in @code{egcs}.)
14725 On AIX 4.1, @code{g77} might not build with the native (non-GNU) tools
14726 due to a linker bug in coping with the @samp{-bbigtoc} option which
14727 leads to a @samp{Relocation overflow} error. The GNU linker is not
14728 recommended on current AIX versions, though; it was developed under a
14729 now-unsupported version. This bug is said to be fixed by `update PTF
14730 U455193 for APAR IX75823'.
14732 Compiling with @samp{-mminimal-toc}
14733 might solve this problem, e.g.@: by adding
14735 BOOT_CFLAGS='-mminimal-toc -O2 -g'
14737 to the @code{make bootstrap} command line.
14740 @section @code{Y2KBAD}
14741 @cindex Y2K compliance
14742 @cindex Year 2000 compliance
14746 Intrinsic `@var{name}', invoked at (^), known to be non-Y2K-compliant@dots{}
14749 This diagnostic indicates that
14750 the specific intrinsic invoked by the name @var{name}
14751 is known to have an interface
14752 that is not Year-2000 (Y2K) compliant.
14754 @xref{Year 2000 (Y2K) Problems}.